Design Patterns Live in Solutions

This week, I've been talking about where Design Patterns live and where they don't.

I have a suggested model and I didn't come up with it alone. It was an accumulation of knowledge from old work and a collaboration with Eran Pe'er of DevCraft.

First, I'm going to lay out some information.

Think about all the ways a Design Pattern can impact your life as a developer...

A Design Pattern can be a starting point for existing code, the goal design for new code, the destination for a sequence of refactoring moves, or any combination thereof. It can be an area of study for someone attempting to advance their skills, a collection point for knowledge about how to address certain kinds of problems, and a phrase in a high-bandwidth conversation between developers.

There are more advantages but these six are really, really important.

All of those things are either directly or indirectly about solving problems. It stands to reason that design Patterns are tools we use in solving problems. They are far from the only part of solving a problem, they represent a critical aspect nevertheless.

To me, that's where Design Patterns live: in the act of solving a problem or helping someone else do the same.

I like positioning Patterns as solution elements. It connects them to problems the way they should be connected to problems. It connects them to implementations the way they should be connected to implementations. It gives us a language to describe, refine and expand them appropriately.

Is it perfect for everyone, always? Probably not.

Is it good enough for me, now? You bet it is.