Design Patterns and Code Qualities

A friend of mine recently intimated that we don't need design patterns because all the principles and patterns can be derived from code qualities.

It's true. Patterns can be derived from the principles of code qualities...the same way aerodynamics can be derived from quantum mechanics.

Just because things explained by a model can be explained using a lower-level model doesn't mean there's no value in the higher level concepts. Design patterns help you focus on the most important effects of code quality.

For instance, the code quality encapsulation describes a mechanism for hiding things. If you assume that the decision of whether or not to hide things is the hardest part of the problem, this quality is all you need. Yet that perspective belies one of the true difficulties of software development: the unseen.

It's always easy to encapsulate something. It's always good to encapsulate something. However, it is not always easy to notice something is there to be encapsulated in the first place.

One of the underlying principles of design patterns thinking is encapsulating variation. This is a different vantage point from just "how encapsulated is your code?" It puts specific emphasis on a particular kind of thing. It shines a light on the most important (by far) think to encapsulate and says "Here. If you're going to miss something, please make sure it's not this."

In a perfect world, we would never miss anything. Everything that could and should be encapsulated would be.

In the real world, a tool that draws emphasis away from the less important applications of code qualities and prioritizes the more important applications is incredibly valuable.

Design patterns thinking works in concert with code qualities thinking, not as an alternative to it.