The book Design Patterns: Elements of Reusable Object-Oriented Software is one of the best available regarding software patterns. The four authors introduce the “Gang Of Four” (GoF) patterns.
What is a Design Pattern in software?
This definition from the Design Patterns book is a reference from an architect named Christopher Alexander (a building and town architect and not a software architect):
Christopher Alexander says, “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” [AIS+77]. Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context.
When I first read the book, it sounded like great idea to re-use these patterns in my code and apply well-known solutions. While coding though, I hardly remembered any patterns to use. I was quite unhappy with myself. Perhaps you can understand how I felt. Here I had these great solutions available to me that will improve my software but I was unable to use them. So, I decided to go deep and learn as much I could about these patterns.
My goal was to develop a sort of ‘muscle memory.’ When I see a problem I should know what pattern to use. So, I decided I would target one pattern over a couple of weeks and only think, sleep, and breathe that one pattern. In those couple of weeks, I gathered as much information as I could about that pattern and its multiple implementations, usages, pros and cons.
After about 9 months, I was well versed in most of the patterns. I reached a point where I could quickly recognize which pattern to apply when looking at a problem. Finally I could use the patterns in code and was quite happy about that.
Unfortunately, that success didn’t last long. I started feeling that my code was becoming more complex than it needed to be after applying these patterns. After looking for answers on the Internet, I found there were other people in same boat.
So, I continued searching for answers. I started going to technical meetups and user groups. I asked people about design patterns and how they use them. I read articles on design patterns from well-known industry experts. The common theme I found from these interactions was:
“Do not force the pattern from outside. The pattern should emerge organically within your code.”
That sounds great, but it’s easier said than done. How one would go about implementing such vague advice? There should be some way to think systematically while coding so that a pattern emerges organically. I now believe the answer is SOLID principles.
SOLID is an acronym for these five principles:
S – Single Responsibility Principle(SRP)
O – Open/Closed principle
L – Liskov substitution principle
I – Interface segregation principle
D – Dependency Injection
I am not going to go in details about these principles. There is a lot of material available on Internet about these principles.
What I want to stress and strongly believe is that SOLID is the systematic way of thinking that I was looking for. All the five principles are equally important. But I think first two principles “S” & “O” are harder to implement and are the keys to writing better and cleaner code so that patterns will emerge. The remaining three principles, “LID”, are well understood and have better support in terms of libraries, framework, tools and enforcement at the language level.
I do not seek to undermine the work done by the great authors of Design Patterns. I strongly feel that each developer should read that book and understand the GoF patterns. But what I would like for you to think about differently is the application of these patterns. I urge you to follow SOLID while writing code. I am sure a pattern will emerge organically within your code and I have seen it. The pattern emerging from your code may not be a standard pattern as documented by GoF or another author. But it will be a pattern for your unique domain problems that you can apply over and over again.
If your team needs help with software architecture, contact Saxony Partners at 214-389-7903 or email firstname.lastname@example.org.
About the author
Vinod is an experienced, hands-on software architect and tech lead involved in the architecture, design, and implementation of service-oriented architectures, and highly available/scalable distributed systems.