ContentsApplication DesignWho does what - logical delegation

Previous: Usage scenarios | Next: What goes where - operational delegation

A lot of attention is given to class hierarchies these days. I couldn't begin to improve on that topic. The only point that I want to make here is that the real justification behind object-oriented programming is to make complex projects easier to deal with from a number of different perspectives. Unfortunately, the academic types seem to have forgotten that by recommending class hierarchies with dozens or even hundreds of classes. Dealing with that many classes sometimes defeats the benefits of OO and results in a net-zero improvement over projects done with procedural code.

The number of classes your project should use is subject to the interpretation of the functional requirements and the technique of the object designer (i.e. the "language architect"). These factors produce an class-to-usefulness ratio that I like to call "object granularity". There are certainly good reasons for using lots of classes in a well-defined hierarchy, but the object designer must be sensitive to the realities of the people who are going to work on implementing and maintaining all of these classes. Many OO development tools exacerbate the problem by producing classes like confetti - which may be great as long as you have access to that particular version of that particular development tool on that particular platform, but pity the poor guy who has to sort this all out ten years from now when a compatible version / tool / platform may be hard to find.

My recommendation it to take a somewhat more conservative approach to the invention of new classes... create a new one only if it makes the hierarchy more easily understood and maintained. I typically like to design my classes to a bit smaller and simpler than the granularity that I've used in the examples - but not much more. If you read the source code for the servlet utilities, you'll find that I only invent additional classes if they are likely to be needed independently.

In the example we've been following, it could well be argued that each web page should be a separate class. It could also be argued that the whole salary data mechanism could be encapsulated and reused. Likewise, the CPI data code could be combined into another class. These potential improvements should be weighed against the pragmas - will reorganizing the code really make it easier to maintain? If so, then the improvements should be applied to the finished version, remember: we were just building a prototype! Now we understand the problem well enough to design the real application.

ContentsApplication DesignWho does what - logical delegation

Previous: Usage scenarios | Next: What goes where - operational delegation