Dealing With Large Numbers of Highly Encapsulated Loosely Coupled Classes
A class with a lot of public methods could likely be refactored into multiple classes just as we have seen a method with a lot of parameters or different activities can be refactored into multiple other smaller more encapsulated methods. Though this creates a lot more "stuff" (i.e. classes and methods in classes), the result is a much simpler system to understand and maintain.
The key to understanding such a system is to identify the business service objects from the clutter of entity beans, DTOs, agent classes, etc. Careful naming of these objects and their placement in the application's package structure can facilitate this quite a bit.
There is a principal in psychology called the Seven Plus Or Minus Two theory. It basically states that the most the human mind can keep track of at any one time is about 7 things, give or take a couple depending on circumstances.
Thus, it would seem contradictory to say that creating large numbers of highly cohesive and loosely coupled objects simplifies our lives. But if you think about this for a second, it makes a lot of sense. Look at it first of all from the standpoint of just having one huge mother of all classes that does everything - say a huge controller servlet in an M-V-C Model 2 web based application which handles action parameters from every screen in the system.
We've all seen classes like this where the business logic is jammed into hundreds of lines of 5 (and more!) level deep nested conditional and control statements requiring pages and pages or screens and screens of code to consider before a conditional is terminated. How easy is all that to hold in your head? Not very.
Now look at a controller servlet which immediately routes control to another class that deals with that branch of logic identified by the action parameter - say an HttpServletRequest coming from an employee project time allocation screen. The new class evaluates that request object for what the specific request may be, such as create a new project to allocate time against. It then routes control to another class that knows all about such things. That class will control the activities of an entire graph of other objects with all sorts of relationships among them.
The point to all of this is that if the application one day throws a strange exception from someone who was trying to create a new time allocation project, the maintenance programmer - who may have never looked at this application before - will know not only exactly what class to go to, but the exact method that contains the error. How many times have we spent literally hours tracking around through an object graph trying to find what happened with little more to guide us than the log file's exception stack trace dump (why do you think they call it a "dump"…) because of all the cross calling and interdependancies created by large coupled classes?
A well designed system can easily be navigated through by following the path of the Agent classes. Ultimately, this leads to the business service object that we want. And if the work of that business service class is efficiently outlined in the main controlling method, fixing problems or creating new enhancement designs in the class itself or within its related object graph of equally highly cohesive and loosely coupled objects will be relatively straight forward. Balance this with interjecting new code into the middle of 300 lines of 5 level deep nested conditionals.
If you design effective business service objects that are highly cohesive and loosely coupled, then it won't even be Seven Plus Or Minus Two. It will be One Plus Or Minus One. Keep it simple. If not for yourself, then for me because I may be the one that has to enhance your code and you don't want me cursing you 3 years from now.
Back to Thoughts On Technology Page | Back to Peter's Home Page | Back to Family Home Page