Patterns Manifesto:

We are uncovering better ways of developing software by seeing how others have already done it.
Kevlin Henney

Patterns are an aggressive disregard of originality.
Brian Foote

IMO too many “pattern consumers” have very selective memories. Each pattern catalog entry has multiple sections:

• Intent
• Also Known As
• Motivation
• Applicabitity
• Structure
• Participants
• Colloaboration
• Consequences
• Implementation
• Known Uses
• Related Patterns

Before applying a pattern it is crucial to understand the full implications of the “Applicability” and “Consequences” sections as use case constraints could easily turn a pattern into an anti-pattern.

Patterns aren’t gold standards. They merely record “this approach has worked for us when we faced this particular problem within our specific context”.

Design Patterns are not crap. They just shouldn’t be used by people in the way they are.

They are treated by most developers as recipes: “I need a to implement a xxx pattern”.

But they aren’t. Instead, they are a naming system. Once you’ve written code, you can say “oh, look, that’s like a strategy pattern.” You could then refer to it as such as a short cut when talking with other developers.

Next time you meet an architect, ask them about Christopher Alexander or A Pattern Language. I’ve never met one you knows what I’m talking about…

If you get rid of implementation inheritance and subtype polymorphism when you work with an oo language you will need less pattern implementations. For example “The factory method pattern relies on inheritance” (Factory method pattern - Wikipedia).
3 key differences between Elixir and Ruby? - #5 by StefanHoutzager Complexity breeds complexity.