Question

When a class 'delegates' a task to another class:

Does the 'delegator' class have to pass itself to the 'delegated' class for it to count as delegation? Or is simple 'forwarding of responsibility' enough, without a class passing itself as a parameter?

Was it helpful?

Solution

No, it does not have to pass itself to the delegate. In fact, delegation is sometimes used in large classes to abstract away specific functions without passing.

For example, if I have a bakery class, and I want to do bakery.sellALoafOfBread(), from the outside, it may just look like the bakery class took care of it. In reality, the cashier class, delegated to by the bakery, did the task. It returned the amount of money that a loaf of bread costs, and the bakery class added the money to the monthly profit.

However, a large object may want to pass a pointer or a reference to itself if the delegate is really tied up in the large class. This way, the small class can have access to the large class's variables and other members.

Example from Wikipedia:

 class RealPrinter { // the "delegate"
     void print() { 
       System.out.println("something"); 
     }
 }

 class Printer { // the "delegator"
     RealPrinter p = new RealPrinter(); // create the delegate 
     void print() { 
       p.print(); // delegation
     } 
 }

 public class Main {
     // to the outside world it looks like Printer actually prints.
     public static void main(String[] args) {
         Printer printer = new Printer();
         printer.print();
     }
 }

See, no passing!

OTHER TIPS

When we say some X design pattern, we are referencing to patterns described by GoF book. So in short NO, like @blue-ice explained above.

But the original term delegation in OOP refers to passing part of problem which it must do to another object when it can't. So the object which will end up doing the task will need the reference to one which delegated because it will need to access some parts of that object.

This is explained more throughly in MIT OOP delegation paper. But if you only want summary of the paper, you can look at this article The Gang Of Four Is Wrong And You Don't Understand Delegation.

The article says in its main part:

Lieberman discussed this in terms of a GUI drawing tool. Here’s the key idea behind delegation:

When a pen delegates a draw message to a prototypical pen, it is saying “I don’t know how to handle the draw message. I’d like you to answer it for me if you can, but if you have any further questions, like what is the value of my x variable, or need anything done, you should come back to me and ask.” If the message is delegated further, all questions about the values of variables or requests to reply to messages are all inferred to the object that delegated the message in the first place.

In short, when you send a message to an object, it has a notion of “self” where it can find attributes and other methods. When that object delegates to another, then any reference to “self” always refers to the original message recipient. Always.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top