Scrutinizing the role and use of design patterns

Just watched the videos - interesting stuff and I do think there’s a higher level language lurking in Elixir. These experiments hopefully help guide extracting the right one.

I am surprised though that @pragdave states “design patterns are crap”. As a card-carrying Hillside Group member such a blanket statement probably has to offend me ;-).

(If he meant - the original GoF design patterns are crap because written for a crap language - for a fun read, pick up the Design Patterns Smalltalk Companion - I’m ok with that, of course)

1 Like

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” (
3 key differences between Elixir and Ruby? Complexity breeds complexity.


I did, but he was called Chris Alexander so it doesn’t count ;-). One thing that is interesting, though, is that Chris has long since moved beyond patterns to something he calls, I think, “unfoldings” - more dynamic than patterns, as patterns didn’t bring him what he thought they’d bring. I find it strange that “the patterns community” seems to have ignored that bit; patterns are seen as something Moses brought down from the mountain just as, say, Smalltalk-80 was. They got handed to the community and froze in place while people looked at it in awe while the original creators moved on. One of the things on my todo list is re-read Chris’ Nature of Order and see how we can bring the patterns community forward. It’s a somewhat more manageable task than trying to figure out what Kay and friends would’ve done to Smalltalk if they’d stayed another four decades at PARC :wink:

I do disagree with the characterisation of patterns as merely descriptive, post-hoc tools to name things. I do think they are a really good way to write down known solutions and share them forward especially because of, as @peerreynders correctly remarks, their rich contextual content. At least, that’s the way it should be. Too often, people boil down their patterns to “problem A -> solution X” but that’s called a subroutine library, not a design pattern :wink:

Also, my apologies for the way I apparently managed to sidetrack this thread. Maybe someone with forum-fu should split it off so we can get back on track.