Design Patterns vs Principles – Understanding the Differences

One of the most popular design pattern among the community here is the strategy pattern. And yes, if you build some example code around this pattern, you can demonstrate all the SOLID principles:

• S = is fulfilled when each strategy subclass is only responsible for exactly one task, and the "context" class does not take responsibilities which belong into the strategy classes
• O = you can add new strategies afterwards ("open for extentions") without the need to change the internals of the context ("closed for modifications")
• L = this means to implement the strategy subclasses correctly with the semantics defined by the strategy interface, not changing the semantics in any of the subclasses. LSP would not be fulfilled when a subclass implements the strategy interface in a manner which breaks the parts of the context using the strategy.
• I = is fulfilled when the strategy base class offers only a small, single-purpose interface (like the one "execute" method)
• D = the context relies completely on the abstract strategy interface, it gets the concrete strategy "injected" from outside (for example, at construction time) and does not make any assumptions about, for example, a fixed set of subclasses, or the availability of specific subclasses.

Note that the pattern itself does not guarantee your code to be SOLID, it is more that the SOLID principles help you to implement the pattern correctly. You may consider to show your students not only correct examples for applying the SOLID principles, but also counter-examples in context of a strategy pattern, showing code which breaks each of the five principles. Or even better: make this an exercise for them.

When the Book came out, a lot of people thought that way, and there were many efforts to create "pattern libraries" or even "pattern communities." You can still find some of them:

• "Pattern Community", WikiWikiWeb
• "The Design Patterns Study Group of New York City", Industrial Logic
• "Patterns Catalog", The Hillside Group

But then...

Did the interest in finding new patterns drop, maybe because they are not really that useful in software design?

This, very much. The point of design patterns is improve communication between developers, but if you try to add more patterns you quickly get to the point where people can't remember them, or misremember them, or disagree on what exactly they should look like, and communication is not, in fact, improved. That already happens a lot with the GoF patterns.

Personally, I'd go even further: Software design, especially good software design, is far too varied to be meaningfully captured in patterns, especially in the small number of patterns people can actually remember – and they’re far too abstract for people to really remember more than a handful. So they’re not helping much.

And far too many people become enamoured with the concept and try to apply patterns everywhere – usually, in the resulting code you can’t find the actual design between all the (completely meaningless) Singletons and Abstract Factories.