Code Level Encapsulation Guidelines for Business Service Objects
Posted by Marcus Wyatt on 25 May 2005
1I’ve found this extremely informative article on Designing Efficient Business Service Objects and in the article the author noted the following Guidelines for Code Encapsulation that he follows when developing his Service Objects.
Code Level Encapsulation Guidelines
- Object encapsulation is at the forefront of consideration.
- Use Interfaces to create object contracts
- Follow descriptive naming conventions for all classes and methods.
- If an object contains more than 3 public methods (other than accessor methods) then it is a sign that the object is not sufficiently encapsulated, particularly controller classes which I many times limit to just 1 public method.
- Refrain from passing raw data into methods. Rather favor objects as parameters.
- Limit method parameters to 3 or less unless there is compelling reason for more. Most times a method that needs more parameters is not encapsulated and needs to be broken up into other methods.
- Limit method body text to what is easily seen in one screen.
- Limit each method to one specific discrete operation regardless of how small, even if the operation is not called from multiple other places in the class.
- Provide verbose and detailed JavaDoc comments no matter how trivial the method.
- JavaDoc all method parameters, returns, and exceptions.
- Do not nest conditional logic more than 2 levels; more indicates the need to break out into another method call.
- Consolidate all class functionality (i.e. business purpose and process) in one main public method which calls out to other methods in the class to do the work.
- Do not nest method calls more than 2 layers deeper then from the main public method (i.e. main public calls method1 which in turn calls method2 – but method2 is not allowed to cascade further).
- Try not to go more than 3 levels of inheritance before getting to your concrete class.
- Rather than using inheritance hierarchies to facilitate business solution responsibility, modern Object Oriented Design technology suggests combining aggregation (has a) with composition (is a type of) within inheritance hierarchies. For example, pure inheritance might have an ancestor class Person with an Employee descendant which might in turn subclass an HourlyWorker. But HourlyWorker “is a type of” Employee, not an “is a” Employee. Thus, Person will extend Employee but Employee will have an aggregate abstract EmployeeType which will then extend HourlyWorker, SeasonalWorker, etc. as descendants. Deep inheritance hierarchies tend to be quite bloated and clog up the pipe with excess object overhead and referencing through the stack. They can also be quite difficult to understand from a maintenance perspective with later developers coming into the system.
After reading the whole article I think these rules does apply in a big way. What do you think?
tags: architecture, code-construction, oop
Currently listening to: ** 79. Arksun – Astrodancer – Winamp ***