[kazinator]

In a language with a sufficiently expressive object system or other features such as macros we could turn the Observer pattern into a library. To get objects to participate in the pattern we then just somehow declare that they are observers or subjects. Then they are endowed with all the right methods. Simple inheritance might be used, but if your Observer or Subject are already derived then you need multiple inheritance to inject the pattern to them. Or some other way of injecting that isn't inheritance. In C++, the CRTP might be used.

Language features don't necessarily make the design pattern's concept go away, just the laborious coding pattern that must be executed to instantiate the pattern.

Writing a design pattern by hand is like writing a control flow pattern by hand in a machine language. When you work in assembly language on some routine, you may have the concept of a while loop in your head. That's your design pattern for the loop. The way you work the while loop pattern into code is that you write testing and branching instructions to explicit labels, in a particular, recognizable arrangement. A macro assembler could give you something more like an actual while loop and of course higher level languages give it to you. The concept doesn't go away just the coding pattern.

The meaning of "pattern" in the GoF book refers not only to concepts like having objects observe each other, but also refers to the programmer having to act as a human compiler for translating the concept into code by following a detailed recipe.

Because GoF design patterns are all object-based, they're able to use naming for all the key parts coming from the recipe. When you read code based on one of these patterns, the main reason why you can see the pattern is that it uses the naming from the book. If you change your naming, it's a lot harder to recognize the code as being an instance of a pattern.