Designing Business Rules Checking
Our rule checking design begins in the object definition, usually called a class implementation. It is common practice and good class design to isolate in separate methods, called accessors, code that changes the state of the object. We take this a step further, and isolate business rule checking and assignment into separate methods, too. These additional methods partition an object's state change into three levels of processing: a public access layer, a business rules layer, and an assignment layer. Having this layered approach satisfies our need for the flexibility to bypass, extend, or override business rule checking.
The public access layer contains the accessor methods for changing an object's state. Because these methods always invoke business rule checking they are the methods available to object editors, methods of other objects, and internal methods needing business rule checking. When the business rules succeed, these accessors delegate the actual state change to the methods in the assignment layer. Public accessors should not be overridden by specialization classes, also known as subclasses; however, with this layered approach, specialization classes have the flexibility of overriding or extending the business rules and assignment procedures. Also, because null pointers and illogical values are bad at all levels of the hierarchy chain, logic checking also happens here, just prior to checking the business rules.
The business rules layer contains the methods that perform the rule checking. These methods can contain the actual rule-checking logic, delegate it to helper objects, or invoke logic in external rule databases or method dictionaries. Regardless of the approach, when business rules fail, an exception should be raised to signal failure. The days of boolean flags are over. Specialization classes can implement their own business rules by overriding or extending the methods in the business rules layer.
The assignment layer contains the methods that actually change the object's state. These methods don't do any rule checking, so they are ideal for reconstructing objects from persistent storage or internal services that need to bypass rule checking. Specialization classes can implement different representations or assignment procedures for an inherited property by overriding or extending these methods.
The following shows the three-layered design approach for state changing methods. Accessors that change an object's state are typically called set accessors or write accessors.
Public set accessor method Logic test // often internal to the public accessor fi Business rule test method fi Assignment method
With slight differences in their implementations, the three-layered design works for both property accessors and collaboration accessors.