Delegation pattern

In software engineering, the delegation pattern is a technique where an object outwardly expresses certain behaviour but in reality delegates responsibility for implementing that behavior to an associated object in an Inversion of Responsibility. This simulates mixins, delegation, and some kinds of aspects in traditional object-oriented languages like C++ and Java. Aggregation must be used with it if inheritance is not applicable.

1 Examples
2 Criticisms
3 See also

Examples

Simple Java example

In this example, the class C has method stubs that forward the methods f() and g() to class A. Class C pretends that it has attributes of class A.

class A {
  void f() { System.out.println("A: doing f()"); }
  void g() { System.out.println("A: doing g()"); }
}

class C {
  // delegation
  A a = new A();

  void f() { a.f(); }
  void g() { a.g(); }

  // normal attributes
  X x = new X();
  void y() { /* do stuff */ }
}

void main() {
  C c = new C();

  c.f();
  c.g();
}

Complex Java example

By using interfaces, delegation can be made more flexible and typesafe. In this example, class C can delegate to either class A or class B. Class C has methods to switch between classes A and B. Including the implements clauses improves type safety, because each class must implement the methods in the interface. The main tradeoff is more code.

interface I {
  void f();
  void g();
}

class A implements I {
  void f() { System.out.println("A: doing f()"); }
  void g() { System.out.println("A: doing g()"); }
}

class B implements I {
  void f() { System.out.println("B: doing f()"); }
  void g() { System.out.println("B: doing g()"); }
}

class C implements I {
  // delegation
  I i = new A();

  void f() { i.f(); }
  void g() { i.g(); }

  // normal attributes
  void toA() { i = new A(); }
  void toB() { i = new B(); }
}

void main() {
  C c = new C();

  c.f();
  c.g();
}

Complex C++ example

This example is a C++ version of the complex Java example above. Since C++ does not have an interface construct, a pure virtual class plays the same role. The advantages and disadvantages are largely the same as in the Java example.

#include <iostream>

using namespace std;

class I {
public:
  virtual void f() = 0;
  virtual void g() = 0;
};

class A : public I {
public:
  void f() { cout << "A: doing f()" << endl; }
  void g() { cout << "A: doing g()" << endl; }
};

class B : public I {
public:
  void f() { cout << "B: doing f()" << endl; }
  void g() { cout << "B: doing g()" << endl; }
};

class C : public I {
public:
  // construction/destruction
  C() : i( new A() ) { }
  virtual ~C() { delete i; }
  
private:
  // delegation
  I* i;

public:
  void f() { i->f(); }
  void g() { i->g(); }

  // normal attributes
  void toA() { delete i; i = new A(); }
  void toB() { delete i; i = new B(); }
};

int main() {
  C* c = new C();

  c->f();
  c->g();
}

Criticisms

Because this is a pattern, developers can make many kinds of mistakes. The developer could forget to delegate a method in the simple version. The developer could mistype the name of one attribute.

This pattern typically sacrifices speed optimization in favor of enhanced clarity of abstraction.