7 ms·
Design Patterns are a massive code smell. I always prefer simple code over extensible over-engineered frameworks.
by AlexanderDhoore 6y ago
Design Patterns are a massive code smell. I always prefer simple code over extensible over-engineered frameworks.
- happytoexplain 6y agoYes, but this approach doesn't scale.
- dvfjsdhgfv 6y agoTorvalds and a few other people would disagree with you.
- BeetleB 6y agoThe reason it's just a few other people is an indicator that it doesn't scale.
- ptr 6y agoSo you would rather have a “sortListByName(list)” where the sort algorithm is hard-coded to what field we should compare on rather than a factored approach using the Strategy pattern? “sortList(list, [](const item& i) {return i.name();})”? I would say the factored solution using “Design Patterns” is the simple one here.
- akavi 6y agoI'm not sure I agree with the author of this book that that counts as an example of "The Strategy Pattern" (vs. simply "passing a function as a parameter"). Is having parameters at all "The Parameter Pattern"? Should we call passing a boolean flag "The Flag Pattern"? To me, "Design Pattern" implies at least some higher order structure than that (and which is not natively abstractable over in the language in question).
- nesarkvechnep 6y agoI have a colleague which calls a higher-order function Reader pattern which is obviously absurd.
- aparsons 6y agoThe Flag Antipattern
- ptr 6y agoThis is the crux of the matter. Design patterns are just common structures that have been found useful at some point in some context. Some programming languages have adopted these patterns, adding "native" support for them. If your programming language didn't have parameters, then yes, I guess someone would add the "Parameter Pattern". It's all rather arbitrary what ends up in a book on "design patterns". Regarding the strategy pattern, when does it start becoming the pattern and when is it just "passing a function as a parameter"? sortList(list, [](const item& i) {return i.name();}); struct MySorter { bool operator ()(const item&) {...} }; sortList(list, MySorter{}); class MySorter : public ISorter { public: virtual bool execute(const item&) override {...} }; sortList(list, MySorter{});
- thom 6y agoDesign patterns aren't common _structures_. I suppose this is why everyone gets so caught up in the language specifics and think they're trivial. Design patterns are common _design decisions_. The strategy pattern isn't saying "you can have callbacks", it's saying "sometimes you should allow a policy to be supplied by the user". Every day, in every language, even the ones with first class functions and people posting on the internet that design patterns aren't needed, people still use libraries with massive 'options' arguments to functions, instead of internalising the actual lesson of the strategy pattern which is to allow executable specifications of behaviour. So yes, there are trivial things which you can argue the toss on, but in the last month I've used HTTP libraries that don't allow you to supply a strategy for retry logic and machine learning libraries that don't allow a strategy for early stopping.
- jcelerier 6y ago
- TillE 6y agoFor the nth time, design patterns are descriptive, not prescriptive. They're a guide for when you're facing a type of problem which has been encountered thousands of time before, not a blunt tool to be jammed mindlessly into every possible scenario.
- ahartmetz 6y ago...and the elaborate ones aren't needed very often, in my experience. So if you have many of them, it's probably overuse.
- cle 6y agoThe problem is that you can preach this over and over but some people will still use them mindlessly in every possible scenario, because it's easy and feels good. I think we've done a poor job as an industry of beating new developers over the head with "know the tradeoffs!" Design patterns are taught without teaching their tradeoffs, and so new developers think that it's best practice to apply every possible design pattern as eagerly as possible. I agree that naming patterns is useful, but IME they've been a net negative on the code bases I've worked on, since the way they're taught encourages using them mindlessly without considering their costs.
- smitty1e 6y agoI think the languages with multi-page exception dumps are a great example of design patterns applied to the point of absurdity.
- kenniskrag 6y agopatterns are not frameworks. Patterns are not libraries, too.
- amelius 6y agoBut they could be ...
- kenniskrag 6y agoa library maybe but not a framework. The framework controls the program flow.
- skor 6y agounless you're writing a framework
- AnimalMuppet 6y ago"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." - Greenspun's Tenth Rule In the same way, any sufficiently complicated C++ program contains an ad hoc, informally specified, bug ridden implementation of half of the Gang of Four design patterns. They would be better off just using the patterns, instead of trying to roll their own half-baked solutions to the same problems. If you've got one of those problems, use the standard, tested solution. If you don't have one of those problems, don't shoehorn in a solution that doesn't fit. It's not that hard to grasp (except for junior devs who have recently read a pattern book...)
- mdiesel 6y ago"Oh, it's just a singleton" - me after half an hour of reading yet another implementation calling it something else.
- AnimalMuppet 6y agoOK, let me extend my statement. If you've got one of those problems, use the standard solution, and call it by the standard name so that everybody understands what you're doing and how you're doing it.
- comeonseriously 6y agoFunny, I prefer Design Patters over extensible over-engineered frameworks. Design patterns can reduce a lot of unnecessary cognitive overhead. For example, a builder pattern that takes a config a returns an evaluation pipeline is really simple and eliminates a lot of runtime if..else conditions.
- s1k3s 6y agoThere's a balance to it, and finding that is what (I think) you should strive for in software development.
- rualca 6y ago> Design Patterns are a massive code smell. Are you really trying to argue that a collection of terminology aimed at describing high level concepts, or standard solutions to commonly repeating problems and requirements, is a code smell? What other good engineering practices are also code smells?
- msla 6y agoYes, things like thread-local storage and singletons are so over-complicated. /s https://en.wikipedia.org/wiki/Software_design_pattern https://en.wikipedia.org/wiki/Software_design_pattern
- rimher 6y agoIt's very close-minded to believe that having a common phrasebook to solve common problems can be described as a "code smell". Design Patterns are tools in a box, aiming to create scalable solutions, but the way a solution is implemented is up to the implementer. Design patterns just try to establish the language.