Dispatch On Features Not Classifications

I find that designs are more flexible if the application code dispatches on features and not classifications or taxonomies. There are at least two advantages of this. First, it decouples the larger-scale code design from domain noun taxonomies/classifications; and second, it allows one to more easily change the dispatching criteria.

For example, a dedicated parking spot may initialally be tied to an employee being a manager where non-managers are not given dedicated parking. However, the rule may change where dedicated parking is predicated on things like years of service, bonuses, and awards. Decoupling dedicated parking from employee categories allows one to change the dispatching rules without shuffling a lot of code around. When building the code, one does not have to be overly concerned about why a feature is triggered and can focus on mere implimentation knowing that if the reason changes it will not be a major shift in design.

It is essentially a layer of indirection between dispatching calculations and other concerns, such as classification systems. We are "lubricating" areas that change often: dispatching calculations.

(In reality, getting the necessary info to make branching decisions may involve adding extra code, but this will usually be the case no matter which technique is used.)

--top

See also PredicateDispatching, VariationsTendTowardCartesianProduct, FeatureBuffetModel

CategoryConditionalsAndDispatching, CategoryPolymorphism, CategoryChange,