Many seasoned software developers complete a career without studying software development patterns. They write fully functional code, and often use patters without being aware. As I have shown people different patterns it is not unusual for someone to say something like, “Oh. I do that all the time. I just didn’t know it was called that.”
What, then, is the value of patterns? Why should a software developer want to spend time learning them? How will it improve their skills? Here are some thoughts:
- Patterns are common and reproducible. As such, it can provide a starting point to solving a problem.
- Patterns enhance communication with other developers. Two developers who know patterns can complete an design session in a few words that may take hours without that common understanding. They can say something like “client-server-resolver” and understand the plan.
- Patterns can document your code. When you use patterns, the names you use for classes, variables, and methods often expose the pattern being used. Another developer can derive how you are solving a problem through the organization and naming of your code base.
Can you write good software without using patterns? I would say, “DEFINITELY.”. Some tools don’t even support patterns. In fact, it is just as bad to let patterns rule your world as it is to ignore them. Use patterns where they make sense. You may find that you don’t know what pattern to use until you have started writing code, or are enhancing code you have written. Let the pattern work for you; don’t be a slave to it.
Can you write bad software using patterns? I would say, “DEFINITELY”. Have you ever worked with a product that had layers upon layers of abstraction, with the intention to future proof every decision? After it is completed, it becomes a behemoth to support. All the value the abstraction brought is lost in the complexity and time require to keep it going.
Many of us write code using tools that don’t lend themselves to the use of patterns anyway. It becomes a part of a much larger pattern, such as Client/Server, etc. Something like a stored procedure does not lend itself to pattern forms of implementation. The language is not designed that way.
Are you a pattern person? IMHO, it’s worth your time to learn.
Cheers,
Ben