Design patterns break rules
JaninaVoigt (Talk | contribs) (New page: 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 solut...) |
JaninaVoigt (Talk | contribs) m |
||
| Line 2: | Line 2: | ||
==Visitor== | ==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. | + | 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. |
More examples to come... | More examples to come... | ||
Revision as of 09:26, 30 July 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.
More examples to come...
| Design patterns | |
|---|---|
|
Creational: Abstract Factory | Builder | Factory Method | Prototype | Singleton | |
