4 ms·
In my experience, design patterns encourage two big problems: - Deciding on a solution before having explored the problem. "I have a pattern for that." - They
by Jare 12y ago
In my experience, design patterns encourage two big problems:
- Deciding on a solution before having explored the problem. "I have a pattern for that."
- They act as shared context only on the surface; all the details and subtleties of the pattern as an implemented artifact are rarely shared, and communication suffers.
In practice, they tend to make the easy stuff easier, but the hard stuff harder.
- jacquesm 12y agoThat goes for any mis-applied tool. If you approach the world with your toolbox ready in hand and you refuse to adapt your tools to the problem then you get this mismatch. Tools were created to solve repetitive problems, if your problem is not one of those then you should improve your toolset, maybe come up with an entirely new tool or maybe you should adapt an existing one until it works better for your application.
- Jare 12y agoI agree, my point is that in practice, patterns encourage that kind of mis-application in many many programmers, and not just the bad ones. The reasons why they do are part of years-old and still unsolved debates. But I know what I saw: fresh off my love affair with the Lakos C++ book, I though GOF was the next cornerstone of OOP and a must read for everyone. Over the next few years, design debates and proposals where design patterns featured more and more prominently, started turning into bizarre minutiae and half-explored problem discussions. Again, simple and noncritical pieces of software seemed easier to describe and even develop, but the hard stuff became harder to manipulate, overabstracted, took longer to be truly finished (although it got to MVP state faster), and usually much less performant.