At some point in a software developer’s career they will be introduced to “patterns”. These are recipes of design that serve as methods to solve commonly seen problems in software design. They can range from something as simple as “Factory Method” to something more difficult to understand such as “Bridge”. The first time a software developer runs into this concept their initial reaction may very well be, “Oh my, this is the best thing that ever happened to me!” They’re right.
The problem at this point, and why I think many people look at patterns with disgust, is that a new developer then starts trying to solve every problem they see with one pattern or another. This blind application of patterns is a stage that perhaps must be gone through in order to learn more about them, but it’s also probably the most frustrating thing for a moderately successful software designer to deal with. Software developers who are algorithmically minded rather than design minded (and there’s nothing wrong with that) find this even more frustrating and see no purpose in the design aspect to begin with. Furthermore, a good software designer doesn’t go about prosthelytizing the great value of patterns because they understand both the benefits and costs of applying them. It’s the new guy, who thinks this is the most wonderful thing in the world, that speaks unceasingly about patterns, applies them all over the place, and frustrates the better developers around them. So this gives patterns a bad name to many people.
Past this point in a software developer’s learning though is a more balanced, correct application of patterns should they get to that point without abandoning the concept or being convinced out of it. Patterns appear everywhere in life and are inherent to the problem being addressed. Patterns don’t need to be pushed into a design, they need to be found in it…pulled out of the problem. Having a wide variety of patterns in your repository of tools makes it easier to recognize them in a problem. A good designer is able to see these patterns in the problem itself without imposing them as a solution where they may not apply (not all problems are generic).
That’s not the only useful aspect to knowing patterns though. One thing that knowing patterns provides is to be able to talk with other developers at higher abstractions than is otherwise necessary. Instead of having to explain in detail how function X creates a pointer to type T that is of the classification in abstraction A, a designer can say, “This here is a Factory Function,” and those who’ve studied patterns know what the person means and will immediately be thinking of 3-4 ways to implement it. Reading a function knowing that the purpose of it is to be a Factory Function also gives a context to understanding it when it comes to code reviews and in understanding and modifying existing code.
This gives us the most useful view of patterns. Patterns are a set of common problems, a way to classify them, and a language to communicate them. Developers and designers need to learn them so that they know that language and can communicate with each other at the design level rather than quibbling over algorithms and basic, every day techniques. These things are important in many conditions more more importantly is the maintainability and legibility of a software product’s design. It’s the design, not the algorithms, that give a product a long or short life. A design that makes good use of patterns is easier to communicate and thus easier to work on. This means that it can survive personnel changes and long lists of new feature additions–much more than a product that makes use of none that is.
Another thing to consider is that try as you might, you’re not coming up with a brand new approach to solving that problem you’re meeting. The chances are high that someone’s faced it before and has devised an elegant solution. The amount of problems solved by the Chain of Responsibility pattern is endless, the likelihood that you’ve solved one of those in a unique and particularly brilliant way is next to zero no matter how smart you are. You probably used a Chain of Responsibility but simply don’t know it. When you’re trying to train your replacement and they say, “Ah, that looks like a Chain of Responsibility…that means…,” you can say, “Why yes!” rather than, “Uh, what?” Not knowing the language because you’re too smart to apply it is not a sign of intelligence, it’s a sign of arrogance.
At the very least a software engineer or developer absolutely needs to know the language of patterns even if they don’t familiarize themselves with the kinds of implementations that exist. Even if you have no intention to apply patterns the language has inherent utility; you need to know it.