When I first started learning about code, I always wondered how design patterns came about. Simply speaking, certain solutions would be repeated many times over until it was recognized as a common pattern that can be referenced.
Design patterns are templates that software engineers can use to provide themselves with insight on how to approach a problem or how to create a new solution.
The author of design patterns usually provide documentation. The structure usually consists of:
- Term: this is the description
- Intent: Describes what the pattern is used for
- Motivation: provides insight on how the pattern solves the problem at hand
- Structure: examples of diagrams and classes that shows how parts of the pattern correlate with one another
- Code: An example of how the pattern would look like, most likely in a popular programming language
Why Use Design Patterns?
- Patterns are proven solutions that help programmers speed the process of development
- Patterns help implement the DRY (Do not Repeat Yourself) principle
- Improves code readability, especially if another developer is looking at your code
- Learning patterns may provide insights on how to solve issues using Object Oriented Principles.
However, there are a few drawbacks to design patterns.
When new developers are trying to get used to common patterns in their respected language, it poses the risk of adding complexity. This usually happens when new developers try to implement the pattern whenever they can, even when a simpler coded solution would’ve been just fine.
There are some programmers who proposed that patterns were just workarounds. For example, Peter Norvig, author of “Design Patterns in Dynamic Languages” stated that patterns were useful only because the languages didn’t have the features to reduce complexity.
The book was published in 1994, and since then, many popular languages have come out with many useful features that allow developers to become more productive.