> The problem with design patterns is that it's far too easy to "apply existing solutions" to problems that don't exist.
That's not a design patterns problem. At most, that's an abstraction layer problem/YAGNI.
> Design patterns can definitely be useful, but only when used sparingly and if they really are the simplest solution to the problem.
This statement reflects that the whole point of design patterns was completely missed. Design patterns are not pre-baked solutions. They are higher-level coding constructs that reflect specific concepts, and thus provide an ubiquitous language for developers to describe and discuss what they are doing without resorting to ad-hoc terms and definitions. Programming constructs, like callbacks, promises, futures, dependency injection, singletons, etc, don't lose their importance, usefulness or value if they are covered in a GoF-type book or if they are implemented by a library.
> It's how some people tend to use them when they are not necessary or a simpler solution would have sufficed. This I believe was OP's point.
Yeah you are right, YAGNI is indeed not taken into account enough. However, blaming design patterns not only misses the whole point and shows a lack of understanding regarding what design patterns are and how/why they are used. In fact, I would go as far as claiming that complaining about design patterns is a symptom of limited technical knowledge and experience, and the bulk of the typical anti-design pattern cliches are just the defense mechanism kicking in within the spirit of the "fox and the grapes" fable.
That's not a design patterns problem. At most, that's an abstraction layer problem/YAGNI.
> Design patterns can definitely be useful, but only when used sparingly and if they really are the simplest solution to the problem.
This statement reflects that the whole point of design patterns was completely missed. Design patterns are not pre-baked solutions. They are higher-level coding constructs that reflect specific concepts, and thus provide an ubiquitous language for developers to describe and discuss what they are doing without resorting to ad-hoc terms and definitions. Programming constructs, like callbacks, promises, futures, dependency injection, singletons, etc, don't lose their importance, usefulness or value if they are covered in a GoF-type book or if they are implemented by a library.