Design patterns have been around for a long time in software development. Design patterns are basically a standard approach to solving a problem that can be found constantly in software development. Patterns are typically used for creating reusable designs, and defining the interactions between different objects or subsystems. I like to think of design patterns as a structured approach to software development and a very good way of improving communication between software developers.
Benefits of Design Patterns
Design patterns have two major benefits. The first benefit is that they can help solve problems with a time tested and proven solution. There’s no need to reinvent the wheel because somebody else already has and documented how they have done it. Code using design patterns is usually far more cohesive and has a lot less coupling. Less coupled code is usually much easier to write automated tests for.
I find that design patterns help improve the communication between developers and makes thinking about higher level design much simpler. For example, I can say I would think about using the Facade or the Factory pattern when suggesting a fix to an issue a developer has.
Finally, design patterns have the potential to significantly speed up the development process as there’s already a standardized way of solving the problem which should help reduce the number of bugs that are caused as developers write code.
Should we always use Design Patterns?
NO! As with everything in software development, there are trade offs that are made with everything. Using too many design patterns can cause far too much flexibility in the design of the system which results in very difficult to debug situations, code being used for unintended things, etc.
How to Learn Design Patterns
The most valuable way of learning design patterns is studying what others are doing. This studying can be done through a few different ways – reading books, reading through other’s code, or maybe even watching some youtube videos.
Design pattern Books
Reading through the book is incredibly valuable though – you will definitely get a return on investment though. I find every time I flip through the chapters, I still find a useful gem and I won’t be surprised if I use it most of the my career. Most languages and environments have their own specific sets of problems that need to be worked around. For example, in Salesforce the various governor limits have caused different patterns to emerge.
Reading through Other’s Code