3 ms·
I think this perfectly shows that design patterns are just that patterns. They're not goals but they aren't really tools either. They're just what you see when
by DasIch 10y ago
I think this perfectly shows that design patterns are just that patterns. They're not goals but they aren't really tools either. They're just what you see when you compare different code bases because similar problems will provoke similar solutions even from different people.
Design patterns only become problems when people learn about them and try to apply them without learning or understanding how they came to be.
- tracker1 10y agoOr, apply them even though they likely will never need them... One pattern implementation that I always hated, and still do was MS Enterprise Library's Data abstraction. I worked on one project that targeted three different databases for Enterprise customers, which was a great fit. That's the only time I worked with EntLib where using it was better than just using other tooling for the specific database directly. In the end, sometimes people get used to a given framework, and don't stop to think if they really need that framework for what they're working on. It's one of the things I really like about the node ecosystem, though sometimes that goes too far the other way. That said, I tend to rail against certain patterns as they don't have much place in a given language/platform. It tends to be something that comes with age/experience. But not always, I've known plenty of older devs stuck in framework/pattern rutt.