Member-only story
Recently I’ve caught myself wondering “if I could tell college me to focus more on one thing what would it be?”, my answer is design patterns. This was glossed over in my college programming courses with teachers saying things like “you’ll come to this design pattern as you refactor”. While this is sometimes true it takes away the emphasis on how important design patterns are.
Cowboy coding was standard in college, there were no design sessions before coding. No design sessions meant my code always did lead me to the design pattern I needed. Once I entered enterprise IT I realized knowledge of design patterns, and when to use them, separates the top tier developers from the entry and intermediate developers. Design sessions occur almost daily, and there is no code to lead you to a design pattern in these sessions. The laissez-faire college approach to design patterns doesn’t work when all you have is an empty whiteboard or an architecture diagram.
Another big reason to use design patterns is testing. My experience has been that design patterns always make testing easier. Every developer has written code only to realize testing it requires an act of god. This is almost always a tell to apply a design pattern.
The following article’s intent is to serve as an introduction to design patterns. Over the coming months, I plan to take a deep dive on each pattern starting in the creational category.
