Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!hp4nl!media01!pkr From: pkr@media01.UUCP (Peter Kriens) Newsgroups: comp.object Subject: Re: Object-Oriented Metrics Message-ID: <2040@media01.UUCP> Date: 19 Feb 91 11:59:58 GMT References: Reply-To: pkr@media01.UUCP (Peter Kriens) Distribution: comp Organization: aQute, Netherlands Lines: 87 > 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) -------- 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 have a hunch that a likewise technique should be possible in the oo world as well. Though I do not have any formal techniques I often "feel" that a design is good. I think the following elements could be start of formalizing these metrics: 1. a method should only do 1 thing. If you do not do this and have methods that combine the implementation of different functionality, you end up rewriting the same functionality in more places and subclassing becomes a lot more difficult. This means that one metric could be the size of the methods. 2. Physical or functional coupling Often you see methods directly referring classes. Though this is sometimes usefull, it often makes code harder to reuse. For example, in ST/V you can refer to the Mouse or the Cursor. One is a global variable that refers to an instance of an object that is responsible for the the mouse cursor or the key-cursor. If you directly refer to the mouse, your code does not work without a mouse. These kind of references are very often. In something like a := Dictionary new, there is not much choice but in many cases it is wise to parametrize the class which is used to create new objects. 3. References to other objects If you get the feeling that ~ryou have to write too many get/set messages to get access to other objects instance variables, you usually try to put the methods in the wrong place or your class layout is wrong. Minimizing access to instance variables of other objects could be another metrics. 4. Global variables Globally variables usually point to a wrong class layout. So keeping them down is another vital metric. 5. Reuse of components. If there are no standard components used, you usually doing too much work 6. Too many classes. A good object oriented design tends to have a few basic application classes and many standard classes.I often see designs where things ai]re made classes which could be better parametrized (is this english?). 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. 7. Subclasses with too many methods A subclass should reuse the code of its parent If you end up rewriting, not adding, a lot of methods you might go in the wrong direction. 8. Conditionals on the class If you end up havinf*g a design where decisions are made which depend on the class, you probably are doing something wrong. (Like (a isKindOf String) ifTrue: [ ] ifFalse: [ ]). 9. Minimisation on conditional statements I am a strong believer that the complexity of code is proportional, maybe even quadratic, to the number of "if" statements. In oops it is often possible to let the class decide what should be done instead of testing it. This often results in oops programs having fewer conditional statements than traditional designs. I think that further reducing this number increases the quality of the code. Ofcourse all of the above is IMHU. I would really like it if many people would react on this so that these loose remarks could become into something more formal. Peter Kriens aQute software architects pkr@media01.uucp