In OOP, what is forwarding and how is it different from delegation?

Question

Would someone please explain the difference between forwarding and delegation? They seem similar, but I haven't been able to find a good definition of forwarding, so I'm not sure I really understand.

Toe

Not sure why this got voted down... It seems like a useful question, although it could use a bit more elaboration. Unfortunately, we could be in a Catch-22 here. I'll try to provide an answer, and the questioner can tell me if I understand correctly. – Courteous

Answer 1

Let's first define two terms:

• sender : the object that sends a message/task to another object(the receiver)
• receiver: the object that receives a message/task from the sender

The difference between forwarding and delegation is that in forwarding the receiver acts in its own context whereas in delegation the receiver acts on the behalf of the sender.

Here is a great metaphor from this blog post:

Delegation and forwarding are both very similar. One metaphor that might help distinguish them is to think of receiving an email asking you to donate some money to a worthy charity.

• If you forward the email to a friend, and the friend donates money, the friend is donating their own money and getting their own tax receipt.
• If you delegate responding to your accountant, the accountant donates your money to the charity and you receive the tax receipt.

Scroop

I think this answer is a little confusing because the definitions of "sender" and "receiver" can be ambiguous in this context. Suppose class Foo contains a member of type Bar and forwards messages to it. Foo is both a receiver (it received the message from some external object) and a sender (it sends the message to Bar). I assume the statement 'the receiver acts on behalf of the sender" in this case is intended to mean "on behalf of Foo" and not "on behalf of the object that originally sent the message". – Exceeding

I think it's more regard with this/self context – Lambrequin

Answer 2

Forwarding is sort of like "inheritance via containment", or "implementation inheritance the hard way".

Typical implementation inheritance:

class Base
{
 public:
    void baseFn() { }
};

class Derived : public Base
{
 public:
    void derivedFn() { }
};

Now, an instance of Derived has a baseFn() method. This is a way of sharing implementation between different classes.

Forwarding looks like this:

class Contained
{
 public:
    void containedFn() { }
};

class Thing
{
 public:
    void thingFn() { }
    void containedFn() { mContained.containedFn(); }
 private:
    Contained mContained;
};

You could have also implemented that with private inheritance.

Delegation is a special case of forwarding, where at the "thing to forward" to is an interface itself.

class Delegate
{
 public:
    virtual void doDelegateAction() = 0;
};

class DelegateA : public Delegate
{
    virtual void doDelegateAction() { }
};

class DelegateB : public Delegate
{
    virtual void doDelegateAction() { }
};

class Thing
{
 public:
    void Thing (Delegate * delegate) { mDelegate = delegate; }
    void thingFn() { }
    void containedFn() { if (mDelegate) mDelegate->doDelegateAction(); }
 private:
    Delegate * mDelegate; // Note, we don't own this memory, buyer beware.
};

Now, you can swap out the implementation of delegate at runtime, whereas in forwarding you cannot (and you may not want to, which is why you would do it).

If that answers the wrong question, let me know in a comment and I'll remove the answer.

Courteous

So are you saying forwarding requires the class to have the delegated object contained within the class, but delegation can optionally use objects instantiated outside of the class? The distinction between the two is still not completely clear. – Toe

@Toe Sorry, I left out a key peice in my last example... Edit coming shortly. – Courteous

@KerrekSB Ah, you are correct. I'm changing the example to & since that is simpler. – Courteous

@KerrekSB Decided to go with * instead in order to maintain the runtime replacement of the delegate. – Courteous

@MichaelPrice: Oh, I was thinking that you should just have said mDelegate = std::move(delegate);, but OK :-) – Lachman

Answer 3

They're similar ideas in that one object relies on another for help. Here's how I think of the two ideas given my strong Objective-C bias:

delegation: A decision needs to be made, but I don't want to make it. I'll let my delegate handle that.

In Cocoa, for example, NSTableView uses a delegate to customize the behavior of the table. Delegation provides a way to customize one object by letting another object, the delegate, provide the customization. Continuing with the example, a table view's delegate implements an NSTableViewDelegate interface that the table uses to talk to its delegate.

forwarding: Someone just sent me a message that I don't understand, but I know of another object that might implement it. I'll pass the invocation of that message on to that object.

In Cocoa, again, any class can implement the -forwardInvocation: method. If a message is sent to an object that doesn't implement it, that object's -forwardInvocation: method is called, and the object can decide to pass the invocation on to another object. That object could be its delegate, or it could be some system-wide error handler, or whatever. NSProxy uses this to appear to implement all methods -- it just passes the invocation on to its master object.

Note that with forwarding, there's not a defined delegate interface; the message is just passed on to another object. Another place you see what I'd call forwarding is when one object contains another object that it uses to implement some interface. Any messages to that interface are just forwarded to the contained object, which does all the work.

Timecard