If Gulliver Were a Designer

The term 'Design' gets thrown around a lot in software developer circles. There are constant flamewars over favorite techniques and battles over what good design really entails. When those arguments start getting too ad hominem figure out whether the speaker is a Code Monkey before giving them much credence. Since I've already braved the waters, see "Have Design Will Travel" or "The Age of the Design Review", instead of safely avoiding the issue, I'm going to bravely (or foolishly) join the fray.

Realize that there is more than one type of 'Design'. Design in the large turns into architecture and is something that really only comes with experience. Designing at the lower levels, say at the individual class/object level is easier to cover. Today I'm writing about design in the small vs the large; Lilliput vs. Brobdingnag.

The issues with designing a class is the same regardless of platform or language. The key is whether an object should be autonomous or whether it is better for any given behavior to be spread out among objects with limited scope and distributed responsibility.

For each class the answer might be different. We end up with a spectrum along which we can place classes based upon the Density of Responsibility.

             (Level of responsibility for behavior)
        Autonomy - - - - - - - - - - -  - - Dependence
     High
 C      -   [god object]                [spaghetti]
 l      -
 a      -
 s      -                                
 s      -           
        -                  
 s      -
 i      -
 z      -
 e      -  [template]                   [framework]
      low

Let's say you favor letting the class perform all the behaviors itself, or as many as you can. Starting on the left side of this graph, when you make your class more autonomous, the size of the class will grow unless you continuously refactor it to make it more generic. This leads to a template. If no refactoring is done, the tendency is for the class to become more "god-like" because if there is some behavior it needs, it has a method for that - it can do anything and everything. The number of fields and methods grow and soon become both unmanageable and unavoidable. Since the class already does so much, coders would rather add to the monstrosity than try to piece it apart and cut the Gordian knot.

The right side of the graph has classes that depend on other classes to a large degree. If the dependency level is high but the individual class is small, that is a sign of a framework; each class doesn't do much and requires lots of dependent classes to accomplish some function. On the other hand, a highly-dependent class that also has a large amount of code is a sign that the class is full of spaghetti.

The key to this question is to determine where you feel more comfortable on the graph. In any event, individual classes will end up spread out on the graph unless some organizational principle is applied, which is how you can achieve the results of Template or Framework.

Having just written that, I would say that there is a correlation between class size and degree of organization. Robert C. Martin (or "Uncle Bob") covers similar ground with package dependencies in his very thorough paper on Design Principles and Design Patterns[pdf]. JDepend is an implementation of the ideas behind the graph on page 26 and complements static analysis tools such as Checkstyle and PMD.