Too often developers put logic in so-called Helper classes.
This practice of SPOD (Single Point of Definition) results in a higher level of reusability, so it seems. But in fact introducing these procedural structured behavioral methods impose a rigid structure. First of all, (other) developers need to be aware that such Helpers exist to work on their objects. Secondly, because behavior that should have been defined in the class of the object, is now defined elsewhere. The possibility of re-using such behavoir by inheritance is now unavailable. You cannot just extend an Helper class too!
Helper classes are intended to provide context independent behavior that cannot be assigned to a particular class of objects. Good examples are conversion methods e.g. formatting a Date or accessing external resources to prevent code duplication.
But what about the behavior required to associate one object to another if none of them is a container? Who is responsible for creating the link and proper setup of both references? Sometimes you cannot add behavior to either one of both sides (depends on whether you specified navigatability on the association ends). In this case, the Mediator pattern can be applied.comments powered by Disqus