I am having the impression that these 23 patterns should be only a small sample of something much larger which I like to call the Pattern Space.
This is the dreadful assumption that is being propagated by neophyte programmers everywhere, programmers who think that they can write a program me...
I absolutely agree, but my question is not about the usefulness of patterns which I think is rather limited. It is about the discrepancy between the persistently high popularity of patterns and the lack of progress in that area. By the way, I don't think it's neophyte profgrammers that propagate patterns, it''s managers who think that it's a way to make programming routine work that can be done by less educated and thus cheaper people.
You're blaming managers for this mindset? I hadn't considered that before. The popularity problem isn't hard to understand; popularity and effectiveness don't track together. See whatis.techtarget.com/definition/… The lack of progress is because pattern programming doesn't work.
It's not the managers that are to 'blame', it's more or less technical people who simplify things and give managers the impression that every idiot will write quality code if he can apply a few design patterns. This caused design patterns to become the number one topic in many job interviews.
"Design patterns (in the GoF sense) have but one purpose: to compensate for deficiencies in the programming language you are using." I keep hearing this, but have yet to see it justified. Every supposed justification of it just points to a handful of patterns that are easier to implement in languages with some feature -- usually Visitor and perhaps Singleton -- and leaves the vast majority of patterns untouched, just implying that they too can be made redundant by better languages. But how do we know? What language feature makes Observer irrelevant? Chain of Responsibility? Composite?
@Jules First class functions alone eliminate a sizable chunk of them, including Chain of Responsibility (it's just composition of a list of functions). Functional reactive programming eliminates the Observer pattern. The Composite pattern is just a less-rigorously specified definition of monoids, and languages with typeclasses and a focus on algebraic laws give powerful tools for working with monoids. I could list plenty more but you get the idea.
@Jules: I believe the original GoF book listed iterator as a pattern, but now its transformation into language feature is basically complete in every remotely OOP language.
@FrankPuffer That hasn't been my (admittedly limited) experience. I was introduced to the Gang of Four book by a programmer. Someone who I think is generally rather pragmatic, interestingly enough. I've never heard of managers even being interested in them. I think it much more likely that they are propagated by the same kinds of programmers who believe that OOP or TDD magically make your code better without having to think about what you're doing.
+1 for the "dreadful assumption". Design Patterns are not Pokemon cards. You don't win the game by just having and playing the right cards at the right time.
@Jack First class functions are at an entirely different level of abstraction, though: first class functions are basically equivalent to objects, not design patterns. That's like saying chain of responsibility isn't necessary because you have objects. Functional reactive programming is just an alternative pattern that provides similar functionality to using observers. And monoids, monads, functors, applicative functors, and all the rest are just other design patterns too. Yes, having typeclasses for these is a benefit, but it doesn't eliminate the pattern, it just moves it into a library.
@Kevin - Sure. Iterator is usually included as a standard part of the library of most languages, and many languages have features that interact with it directly. It doesn't stop it being a pattern, though. It just makes it easier to implement and use.
@RubberDuck how is having the pattern already implemented making the pattern obsolete? It's still the design pattern being implemented. Different sets of language features might lead to different implementations of the pattern, but the pattern itself is still there. Patterns are there to ease communication by giving names to reoccurring strategies that's commonly used. Point in case, the .NET classes are called ObservableSomething<T> which makes it easy to understand their purpose, because it uses the commonly known pattern name. A pattern is an idea, not an exact implementation.
@null the point is that we don't have to implement the pattern, as it's baked into the language. I already said that maybe it wasn't precisely what Jules was asking for, but I find it to be an example of how this language is less deficient (in this particular area) than others.
@Jules You're stretching the definition of design pattern though. If you call basically every programming construct a design pattern, then sure, design patterns are still in wide use! But that's not the definition most people think of, nor the one used in GoF.
@Jules: What is a Program? A solution to a re-occuring problem. What is a Design Pattern? A solution to a re-occuring problem. Why is it not a program? Because we can't express it as a program. Ergo, a Design Pattern is a solution to a re-occuring problem that should rather be a Program, not a Design Pattern, but can't be a Program, because the language is not expressive enough to express the Program. Example: not too long ago, "Subroutine Call" was a Design Pattern! Nowadays, it is a language feature.
@DocBrown Are you sure it's not the opposite ? I mean people taking design pattern and make them as a feature instead of having to implement them again and again ?
@JörgWMittag - "What is a Program? A solution to a re-occuring problem. What is a Design Pattern? A solution to a re-occuring problem." I disagree with this; a design pattern is an abstract description of a general approach to solving a large class of re-occuring high-level problems. And the restriction that the problems are high level is a critical one ... it is this that means that we don't generally consider Subroutine Call (or Heap Allocated Object, or Statically Allocated Variable, or ...) to be a pattern, and not the fact that it is implemented in our languages. And the reason ...
... that's important is that design patterns are supposed to be a language we can use to document the decisions made when designing a program, but the above patterns aren't really useful at that level of abstraction.
@Jules "a design pattern is an abstract description of a general approach to solving a large class of re-occuring high-level problems". You could easily replace "design pattern" with "programming language" in that definition. There are many high-level language features, e.g. modules.
@JörgWMittag: you are oversimplifying, and playing with words. Not all design patterns are "not a program because we cannot express them as a program".
@DocBrown How about "not a library because we cannot express them as a library"? If a pattern really is a solution to a recurrent problem then you'd ideally want it implemented as a library, with the "holes" in the pattern where you fill in your customsations being parameters; you just "call" the pattern on the things you want to apply it to. But ideas for programmings solutions are expressed as patterns rather than libraries precisely when the holes are the "wrong shape" for what the host language allows you to abstract over.
@Ben - I think you're missing a subtle point here, which is that even when languages provide first class support for a design pattern, or a pattern is simple enough that it can be encapsulated in a library, we still call it a pattern. Example: Object Relational Mapper is a design pattern (see, e.g. Fowler et al Patterns of Enterprise Application Architecture, where it's called simply "Data Mapper") ...
... that can be implemented entirely in libraries in many languages, and there are many implementations of it. But just because it has been expressed as a library, doesn't mean that it ceases being a pattern too.
@gardenhead - modules solve organisational problems (e.g. "how do I allow two pieces of code that relate to each other to evolve indepently" -> "place the two pieces of code in separate modules with a dependency between them"), which is a lower level problem than ...
... the kind of behavioural/data management problems that are discussed in most design patterns (e.g. "how do I allow an algorithm to access data stored in a collection without needing to know how the collection organises the data" -> "use an Iterator"). It therefore seems sensible to distinguish the latter with a different name.
@Jules You're missing the fundamental point, which has already been stated, that there is no useful distinction between a pattern and just "programming". Any definition you have or will come up with can be torn apart.
By the way, before we had the concept of modules in languages, there was the "design pattern" of splitting your program up over several files and linking them together, which was ad-hoc and error-prone. An iterator is not a design pattern either; it's just an interface / abstract data type.
Discussion on answer by Robert Harvey…
Discussion on answer by Robert Harvey…