re: An introduction to the concept of design patterns VIEW POST


I'm not sure I can follow you here, could you please explain this (or redirect me to some resources I can read about it)? I'm not familiar with the connection of these specific programming languages and design patterns.

All these languages basically introduced new paradigms.

  • Smalltalk-80 introduced an object-oriented paradigm (not the very same to what we call OOP now.)
  • COBOL introduced a human-readable programming language.
  • Erlang introduced lightweight processes, hot code upload and message passing for everything.

None of the above was found and/or identified. All were invented from the scratch by smart minds.

But these were no design patterns at the time of the development of these languages, were they? I'm only aware of message-passing design patterns, but they claimed to be design patterns only since the book "Enterprise Integration Patterns" and there the concepts of the languages you mentioned have already been applied in different other contexts.
The time is important, of course somebody has to "invent" the solution. But it can only become a design pattern if it has proven to be a solution to a problem in different systems.
So, the "design pattern" is not the original solution one came up with. The design pattern is the description of the solution, not the solution itself. And for a solution description to qualify as a design pattern, it must already exist.
It is the same with the original design patterns from Christopher Alexander. He did not invent the building constructs, it was just a collection of solution descriptions other architects have used in multiple times.
So to sum, of course, behind every design pattern stands a smart mind that initially came up with the solution. But then it was a great idea, not a design pattern yet :-).

It heavily depends on what do we call “design pattern.” If something that is considered to be cool by a majority, then I have no opinion on the subject since I am not interested in what the majority thinks at all.

If, OTOH, we are talking about something, that is invented and used inside a team of any size (it might be used by one single developer,) then I am interested in and I am positive these design patterns are indeed a result of re-thinking the experience, but they are always brand new concepts.

That is what I tried to summarize in my article :-) (It is not an invention by me, it is a summarization of all the information I got from international design pattern conferences and books on this topic).

code of conduct - report abuse