3 ms·
Having done "microservices" for more than a decade, I think most of these patterns are horribly overengineered or incomplete. As with the GoF design patterns, i
by stingraycharles 9y ago
Having done "microservices" for more than a decade, I think most of these patterns are horribly overengineered or incomplete. As with the GoF design patterns, it's almost always a bad idea to implement these patterns as-is.
Rather, look at these patterns as solutions for problems that worked for other people, and try to adapt that to your own situation. You're almost certainly going to come up with something more simple and reliable in the process.
- hliyan 9y agoI was just about to make the exact same comment. As principles, even the GoF patterns are fine -- a lot of good engineers independently derive and use those patterns without ever knowing their names. Problems arise when engineers who don't understand the principle somehow match a pattern to a problem they have an implement it literally, right down to naming classes after patterns. That's not what patterns are for.
- codeflo 9y agoHow do you name your classes instead? I ask because I'm now mostly in favor of naming classes after the patterns, at least when there's no relevant term from the domain to use. That is, when the alternative is to invent a new abstract name, I think it's better to use the one that comes with the design pattern. The resulting names are often ugly, but at least they clearly communicate the intent to people also familiar with the pattern.
- BatFastard 9y agoWhat are some examples of names you find yourself using a frequently. Do you use PatternIdentifier or IdentifierPattern pattern? ie. UserInfoProxy or ProxyUserInfo?
- hliyan 9y agoIf there's no relevant term from the domain, that's an indication (at least for me) that the class hierarchy is wrong. I've been programming for 15 years and I've never found myself without a proper domain-oriented name for a class...