Be forewarned that most if not all of the discussed design patterns will be object oriented in nature. Despite this, the overall spirit of design patterns can prove to be helpful to functional and procedural programmers alike. Before we tackle the how of design patterns, it’s important to determine the why.
If you know the why, you can live any how
Why Design Patterns Matter
As, at the time of writing this, I admittedly have not given much thought to design patterns for a variety of reasons. Including but not limited to: JavaScript doesn’t lend it self very nicely to object oriented design patterns given its prototypical inheritance chain and the fact that during my day-to-day tasks, I’m not often pondering “what pattern would work best in this scenario”. Regardless, as Bruce Lee once said, all knowledge is self knowledge… Thus, learning about design patterns will, at the very least, help me learn more about myself. Hippy dippy things aside, there are actual tangible benefits to learning design patterns.
For example, naming a thing allows us to say more with less. When we use a pattern in a description, it lets other developers know what design we have in mind. Similar to how naming your child whilst still in the womb makes the whole baby thing all the more real, so to is true for design patterns. Why the baby example? My brother just had a kid so I’ve got babies on the brain 😆.
Speaking design also allows us developers to stay in the design phase of our solutions longer. Oftentimes, if you’re anything like me, you’re itching to getting to typing… this however, can be counterproductive as we may end up coding ourselves into a corner (I’ve done this before and it is not fun). Another benefit to speaking design is that it allows the conversation to stay at a higher level of abstraction and this is beneficial because developers who may not be versed in the implementation language of the solution can still contribute to the overall development of a solution. Inclusiveness is gooooood.
Lastly, knowing design patterns can open up career opportunities! If you’re at all interested in being a Solutions Architect, design patterns will become your new best friend.
How Do I Use Design Patterns
I would be remiss if I did not state this disclaimer: design patterns cannot be implemented by a framework and they don’t even exactly go into your code… they go into your 🧠. Once we’ve got a good working knowledge we can then apply these patterns to our old code and prevent our new code from becoming a hodge-podge of spaghetti.
A Reminder
When it comes to designs, there’s a couple of things that we need to keep in mind:
- Program to an interface and not an implementation.
- Favor composition over inheritance
- Encapsulate what varies.
- Too much abstraction isn’t necessarily a good thing!