Smalltalk Best Practice Patterns Volume 1: Coding - Free

Pluggable BehaviorHow can you parameterize the behavior of an object?The conventional model of objects is that they have different state and the same behavior. EveryPoint can have different values for x and y, but they all use the same logic to compute“translatedBy:”. When you want different logic, you use a different class.Using classes to specify behavior is simple. The programming tools are set up to help readersunderstand the behavior of your system statically, without necessarily having to run the code.This model works for 90% of the objects you will create. Creating classes comes at a cost, though,and sometimes different classes don’t effectively communicate how you think about a problem.Classes are an opportunity. Each one will be useful to instantiate and/or specialize. However, eachclass you create places a burden on you as the writer to communicate its purpose andimplementation to future readers. A system with hundreds or thousands of classes will intimidate areader. Managing a namespace across many classes is expensive. You would like to invoke thecosts of a new class only when there is a reasonable payoff. A large family of classes with only asingle method each is unlikely to be valuable.The other problem with specializing behavior only through classes is that classes are not flexible.Once you have created an object of a certain class, you cannot change that object’s class withoutcomplete ruining the ability to understand the code statically. Only watching carefully while singlestepping will give you insight into how such code runs. Smalltalk’s single inheritance also does notallow specialization along several different axes at the same time.If you are going to use Pluggable Behavior, here are the issues you need to consider:How much flexibility do you need?How many methods will need to vary dynamically?How hard is it to follow the code?Will clients need to specify the behavior to be plugged, or can it be hidden within the pluggedobject?How can you specify different logic in different instances, without creating lots of little classeswon’t work or changing classes at runtime?Add a variable that will be used to trigger different behavior.For simple behavior changes, use a Pluggable Selector. A Pluggable Block gives you moreflexibility. Hide the implementation of pluggability behind an Intention Revealing Message.Coding Patterns page 54 of 147 9/30/2006