Re:The Gang of Four book is wrong about delegation (2012)
by mannykannot on Thursday June 29, 2017 @05:00PM
(#14666836)
I had to take a couple of passes at that to figure out what the various referents were. This is just a summary of Lieberman's position, so I guess we will have to go to his paper to see the reasoning behind this position.
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.
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.