For the longest time, I resented Design Patterns.
It’s the name, really. Design Patterns.
How could I ever be an awesome programmer if I couldn’t design with Design Patterns? And yet, try as I might to learn them, I could never manage it.
Off the top of my head, I’d say you’re looking at an Abstract Method, a Visitor, an Adapter, two Commands, and a Bridge. Not to mention the biggest Chain of Responsibility ever.
Shouldn’t this spill out of me naturally? Shouldn’t it work like that?
It turns out the answer is “uh… no.”
We use Design Patterns all the time (even if we don’t know a single one)
Design patterns aren’t raw material for making software. Design patterns describe common approaches to solving common problems. Experienced and inexperienced programmers alike face the same problems. Interestingly, inexperienced programmers tend to solve problems the same way as do our more experienced brethren—we’re just not always as successful.
When we solve problems, our first instinct is to use what we know. For novices, what we know is what we see in tutorials. As we gain experience, our instinct is informed from the code that we work on and the code that we read.
We strive to be above base superstition
What differentiates good from great is how we build that experience. It is tempting to discard an approach the first time that it fails us. That is base superstition, and we strive to be above that.
To truly grow, we need to recognize that an approach—that a Design Pattern—works really well in some situations and not so well in others. The best way to build that recognition is to effectively catalog patterns—by naming them. With that, the next time we recognize that we’re using, for example, the Adapter Pattern, we can lean on what we learned previously. We can acknowledge that it failed miserably three projects ago, but the reasons for the failure aren’t applicable to this project for these reasons.
We do ourselves a disservice if we don’t learn from the giants that proceeded us
Personal experience is always the best teacher. Keep reading code, keep learning new approaches. Build up your personal catalog of patterns. But we do ourselves a disservice if we refuse to learn from the giants that proceeded us. So learn the Gang of Four as best you can. Learn the patterns that have been identified since then.
One way or another, a strong understanding of design patterns is critical to becoming a great programmer.
Which is where (I hope) Compendious Thunks fits in.