Design patterns break rules

Revision as of 00:53, 7 August 2009

Design patterns often solve quite complicated problems where there are a number of design forces pulling developers in different directions. In some cases, there is no "ideal" design solution that doesn't break any design rules. Therefore, some design patterns deliberately break some design rules. If that is the case, there is a definite trade-off between several design forces and the design pattern makes a call as to which design force should be followed.

Visitor

Visitor deliberately separates behavior from the data it acts on rather than polluting the classes the data is contained in with the behavior acting on it. In this way, it is following Separation of concerns over Keep related data and behavior in one place. Because the behavior is separated from the data, accessor methods are likely to be needed to access the data in the object structure that is being visited. That means that other heuristics like Tell, don't ask and the Law of Demeter are also likely to be broken.

Strategy

Like Visitor, Strategy separates related data and behavior to separate a family of algorithms from the data they work on. As above, this is in line with Separation of concerns and Single responsibility principle but conflicts with Keep related data and behavior in one place, Tell, don't ask and the Law of Demeter.

Memento

I'm not sure if this is really breaking a rule, but Memento (among others) breaks Tell, don't ask by calling GetState() when taking a snapshot.