The Gang of Four book is wrong about delegation (2012)

As far as I follow it, the argument is that delegation means, in prototype-based OO (apparently the only context in which either author recognizes its use), that if an object has no method for handling a message that it has received, then it transitively searches through its prototypes for one that can handle it, and if found, the receiving object delegates the message to that prototype's method for handling. When that method handles it, however, it should do so in a way that is aware of the context of the object originally receiving the message, so that, for example, if both the receiving and handling object have a name, the handler should use the receiver's name if it needs a name in handling the message.

If we assume that the methods reference the context they are working with through a variable called 'self', then passing the handling method a 'self' bound to the original message receiver (not necessarily the most recent delegator) will achieve this: any method calls or references the handler needs to make will go through the same delegation process, starting from the original receiver, and in so doing possibly, but not necessarily, ending up at a method from the same object as was picked to handle the original message.

There may be the additional implication that this greatly facilitates composition, which is (it is claimed) preferable to inheritance, but I would think name collisions are a problem.

But then I switched from Java to Ruby, and half of the design patterns were completely irrelevant. And I had other problems for which I didn't have appropriate design patterns.

I think the Gang of Four book's target audience is far narrower than it's often been interpreted. It's meant for intermediate C++ programmers. People who have already run into a number of these problems that C++ doesn't really handle well, and now here's a book that helps you around those limitations.

I guess it also works well for older Java versions, but it's not universal. Many patterns are completely irrelevant for some languages, because those languages have easier ways to do that. Many languages have other shortcomings that are not handled in that book.

Maybe there's another target audience for that book: language designers. Design your language so nobody needs these patterns. Have built-in constructs that handle this stuff in an easy way for the programmer.