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

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.

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.

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.