When is a Delegate not a Delegate......
Ok, I just want to get this cleared up in my very confused mind....
I have always used the term 'delegate' when I have a class which implements an interface, but passes thru all requests to another object implementing the interface (e.g, simulating multiple inheritence, changing implementation at runtime etc etc).
I dont confuse it with Proxy or Decorator.
This pattern is described both in 'Design Patterns' (Gamma Et al) and 'Effective Java' (Joshua Bloch).
However, in 'Effective Java', Bloch says this is called 'forwarding' and says it is 'delegate'only if the wrapper object passes a reference to itself to the wrapped object.
I.e, if the wrapper doesn't pass itself to the wrapped object, it isn't delegate.
He goes as far as to say it is erroneous to call the pattern delgate if this doesn't hold (p75)
The justification for this is that in 'Design Patterns' (p20), an analogy is given to inheritence - where subclasses can defer requests to parent classes. It is stated that "to achieve the same effect with delegation, the receiver passes itself to the delegate to let the delegated operation refer to the receiver".
That to me comes across as "if you want to have this effect with delegation, this is how you do it", not as "to be delegation, this must happen".
I wonder if the statement in Bloch (p75) is thus incorrect?
The more I think about this, the more Im convinced.... 'Design Patterns' goes on to state "Several design patterns use delegation. The State, Strategy and Visitor patterns depend on it".
Now, most of those certainly donot mandate that the wrapper reference is passed to the wrapped object - its usually anoption if its required (eg, State, Strategy).
I know this may seem like a pointless argument - but names really are very important when expressing patterns.
Its very important to me when describing patterns to others that I use the correct names so that everyone is clear on what we are talking about.....
Can anyone clear this distinction up?
