Design patterns are only useful if the team has a shared vocabulary. In other words, when you say the name of the design pattern, the others on the team must know what that means. Otherwise, it’s like a foreign language.
I was having lunch today with a co-worker, and we discussed the meaning of design patterns. A singleton is only a singleton if we all agree that we are going to call it “singleton”. An “observer” pattern is only that if I can say “observer” and the other members of the team know what I’m talking about. Design patterns are a shared vocabulary. It’s a way to speak in shortened jargon and convey meaning.
Every field has their own jargon, and in software, we one of our categories of jargon is design patterns. In football, you can tell a receiver to run a bootleg pattern. Some teams have unique names for pass routes as well. The words only have value because everyone on the team shares the vocabulary.
Consider this scenario: A developer goes out and reads several design pattern books and then comes back and starts using the new terms in design conversations. This has no value since the new terms have no meaning to the rest of the team.
Design patterns are useful when they can be used to convey specific meaning in design conversations. On my team, if I say “I’m going to stub the web service call”, everyone knows that I am going to make a class that will fake the behavior of the web service so that the client code can function without the SOAP call actually occurring. A stub obviously isn’t the most glamorous design pattern, but all these small pieces of jargon help when communicating on a software team.
It is very helpful for design patterns to be a shared understaning throughout the industry since we communicate about software beyond team boundaries. I love that there are plenty of books on the topic these days, but it’s a shame that more developers don’t share the terminology.