Design patterns break rules

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.

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 completely 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" it's observers it would need to be aware of them. Unless of course if it the subject passes all information to all observers, but this would not be ideal either.