Design patterns break rules
JaninaVoigt (Talk | contribs) m (→Strategy) |
m (→Observer) |
||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 10: | Line 10: | ||
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. | 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. | ||
| − | + | ==Composite== | |
| + | The standard [[Composite]] design pattern breaks Riel's heuristic [[Avoid no-op overrides]]. It does this to allow the client to deal with both compositions of objects and single objects in the same way. There is an alternative solution which corrects this, and avoids the need for explicit down-casting as described in the [[Parse tree design]]. Unfortunately this does force the client to be aware of whether they are dealing with compositions of objects or single objects. Some people would argue that this is the right thing to do because these are semantically different things; so it is something that the client should have to be aware of. | ||
| + | |||
| + | ==Observer== | ||
| + | The [[Observer]] pattern breaks the maxim [[Tell, don't ask]]. This is because the observer must "ask" the subject many things when the subject informs the observer that they have changed. This is unavoidable because to require that the subjects instead "tell" the observer everything they know would undermine the intent of the [[Observer]] pattern. The intent is to allow the subject to be unaware of who is observing it. In order for the subject to know what information to "tell" its observers it would need to be aware of them. Unless of course if it the subject passes all information to all observers, but that would not be ideal either. | ||
Latest revision as of 21:55, 14 October 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.
Contents |
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.
Composite
The standard Composite design pattern breaks Riel's heuristic Avoid no-op overrides. It does this to allow the client to deal with both compositions of objects and single objects in the same way. There is an alternative solution which corrects this, and avoids the need for explicit down-casting as described in the Parse tree design. Unfortunately this does force the client to be aware of whether they are dealing with compositions of objects or single objects. Some people would argue that this is the right thing to do because these are semantically different things; so it is something that the client should have to be aware of.
Observer
The Observer pattern breaks the maxim Tell, don't ask. This is because the observer must "ask" the subject many things when the subject informs the observer that they have changed. This is unavoidable because to require that the subjects instead "tell" the observer everything they know would undermine the intent of the Observer pattern. The intent is to allow the subject to be unaware of who is observing it. In order for the subject to know what information to "tell" its observers it would need to be aware of them. Unless of course if it the subject passes all information to all observers, but that would not be ideal either.
