An Engineering Manager’s Guide to Design Patterns
Design Patterns aren’t libraries or frameworks.
We’ve all used off-the-shelf libraries and frameworks. We take them, write some code using their APIs, compile them into our programs, and benefit from a lot of code someone else has written. Think about the Java APIs and all the functionality they give you: network, GUI, IO, etc. Libraries and frameworks go a long way towards a development model where we can just pick and choose components and plug them right in. But they don’t help us structure our own applications in ways that are easier to understand, more maintainable and flexible. That’s where Design Patterns fit in.
You see, design patterns don’t go directly into your code, they first go into your BRAIN. Once you’ve loaded your brain with a good working knowledge of patterns, you can then start to apply them to your new designs, and rework your old code when you fear it’s degrading into an inflexible mess of spaghetti code.
Okay, but what are Design Patterns, really?
Design Patterns are all about reusing experience. Chances are, someone out there has had a problem similar to the one you’re having, solved the problem, and captured the solution in a design pattern. A design pattern you can use.
But a design pattern isn’t an algorithm, ...