Collective Wisdom from the Experts 65
the state, the open and close operations will behave differently. This inherent
property of an object makes the design process conceptually simple. It boils
down to two simple tasks: allocation and delegation of responsibility to the
different objects including the interobject interaction protocols.
How this works in practice is best illustrated with an example. Let’s say we have
three classes: Customer, Order, and Item. A Customer object is the natural place-
holder for the credit limit and credit validation rules. An Order object knows
about its associated Customer, and its addItem operation delegates the actual credit
check by calling customer.validateCredit(item.price()). If the postcondition
for the method fails, an exception can be thrown and the purchase aborted.
Less experienced object-oriented developers might decide to wrap all the busi-
ness rules into an object very often referred to as OrderManager or OrderService.
In these designs, Order, Customer, and Item are treated as little more than record
types. All logic is factored out of the classes and tied together in one large,
procedural method with a lot of internal if-then-else constructs. These meth-
ods are easily broken and are almost impossible to maintain. The reason? The
encapsulation is broken.
So, in the end, don’t break the encapsulation, and use the power of your pro-
gramming language to maintain it.