garry@ithaca.uucp (Garry Wiegand) (02/21/91)
pkr@media01.UUCP (Peter Kriens) writes: > 6. Too many classes. > ... For example I saw > a class button with a Help, Shuffle and Play subclass. The > only thing these classes did was print their name and > call a procedure. This was much better if the button class > had an instance variable for the name and action. I was arguing exactly this point a few days ago with a MacApp fan. He claimed that overriding a method - by deriving a new class from "Button" - was *exactly* the most elegant way to program menus in MacApp C++. I argued that creating classes for which there would probably only ever be one instance seemed syntactically clumsy (in C++). I argued further that if you instead got involved with pointers-to-functions as part of the Button instance data (as Peter suggests) then you've fallen back into the plain-C style of being object-oriented and thus C++ hasn't done you much good. What's the net.religion on the subject of "too many classes" and, for example, used-only-once menu buttons? Garry Wiegand --- Ithaca Software, Alameda, California ...!uunet!ithaca!garry, garry%ithaca.uucp@uunet.uu.net
cote@subsys.enet.dec.com (Michael P.A. Cote) (02/22/91)
> From: drich@klaatu.lanl.gov (David O. Rich) > When it comes time to review a particular OO-Design, or even an > OO-Implementation, what kinds of qualitative/quantitative measures are > used? Do people talk in terms of object coupling, cohesion, etc? > (seems like personal preferences tend to dominate here) The fact that personal preferences tend to dominate is merely an indication of the current maturity level of OO technique. :-) There are most definitely coupling and cohesion metrics that can be applied to objects. (See below) Appropriate coupling and cohesion metrics should apply to each and every level of abstraction of the problem space. Therefore, object coupling and cohesion metrics should be taken in addition to metrics based on the individual methods. After all a strongly cohesive object with terrible coupling between methods will not help out the maintainability of the system as a whole. > From: pkr@media01.UUCP (Peter Kriens) > You are very right. Last year I tried to start a discussion abour "object- > normalisation". I always liked the fact that the database people had a > rather nice mathematical technique to to see how good the data model was. I also like the idea of "object normalisation". In fact, I have done some designs that start with a logical data model of the "virtual database" basis of the application and then normalize that logical data model. From that point, I was able to simply assign objects to represent each of the entities in the logical data model. This technique is nice for defining the core objects of an application that is based on some type of Object Oriented Database. However, as you extend the application analysis to cover the fringes, you need some better metrics to guide you. I found a good reference on Object Oriented Coupling and Cohesion. This article was recommended to me by Larry Constantine. Embley, D., and Woodfield, S., "Cohesion and Coupling for Abstract Data Types", Sixth Annual Phoenix Conference on Computers and Communication. Phoenix, Feb 1987; 229-234 They provide 5 levels of cohesion for objects: (from best to worst cohesion) Model - Only one Domain; only operations defined on one domain; No other data abstractions are enclosed. Concealed - More than one useful data abstraction completely encapsulated within an object. Undelegated - A method is defined that operates on only a subset of the entire data domain. Multifaceted - Multiple data domains are joined by common operations. Separable - Unrelated data domains encapsulated within single object. In addition, there are 5 levels of coupling: (from best to worst coupling) * Items are not talked about in the article. Export - Uses only exported methods/domains independent of representation or implementation. * Overt - Uses implicitly exported method * Covert - Uses private domain or operation of another object. Surreptitious - No direct reference but implicit use of privileged knowledge of implementation of another object. Visible - Violate encapsulation with direct reference to internal implementation of another object. MPAC