Delegate vs Forwarding in Java OOP

Question

I'm reading some article about "prefer composition over inheritance", and heard about Forwarding and Delegation. After search for the different I found some source:

• https://en.wikipedia.org/wiki/Forwarding_(object-oriented_programming)
• https://en.wikipedia.org/wiki/Delegation_(object-oriented_programming)
• https://www.geeksforgeeks.org/delegation-vs-inheritance-java/

But these example is make me more confused. For example, with this snippet of code:

class RealPrinter { // the "receiver" 
 void print() { 
 System.out.println("Hello world!"); 
 }
}
class Printer { // the "sender" 
 RealPrinter p = new RealPrinter(); // create the receiver 
 void print() { 
 p.print(); // calls the receiver 
 } 
}
public class Main {
 public static void main(String[] arguments) { // to the outside world it looks like Printer actually prints. 
 Printer printer = new Printer();
 printer.print(); 
 }
}

Wikipedia said it's Forwarding, but GeeksForGeeks said it's Delegation. So which is right?

Another thing is in Wikipedia's example they declare the delegation using private delegate A a;, which is delegate keyword?

And what is "real life" example of Forwarding vs Delegation, with example code in Java.

Answer 1

I have known about the Delegation normally as you have demonstrated in your answer, but not the Forwarding.

Short answer: what you provided with the Printer code snippet is Delegation. On top of that, the given Wikipedia example 1 is yet another acceptable answer as well.

Long Answer:

I'll break the descriptions down which makes it easier to apprehend the terms and the concepts.

A simple visual to better explain the given terms :

=========================
| WRAPPER(Sending) |
| +---------------+ |
| + WRAPPEE + |
| + (Receiving) + |
| +---------------+ |
| |
=========================

The Delegation

evaluating a member of one object (the receiver) in the context of another, original object (the sender). 2

This indicates to what we know from printer example. The Wrapper

The Forwarding

An often-confused technique where a sending object uses the corresponding member of another object, without the receiving object having any knowledge of the original, sending object.2

In addition, the slight difference between Delegation and Forwarding is that how the "self" keyword is bounded, according to Wikipedia;

They differ in what self refers to on the receiving object (formally, in the evaluation environment of the method on the receiving object): in delegation it refers to the sending object, while in forwarding it refers to the receiving object.3

Furthermore, the definition goes on as;

The difference between forwarding and delegation is the binding of the self parameter in the wrappee when called through the wrapper. With delegation, the self parameter is bound to the wrapper(this is what we have with the 'this' keyword in Java), with forwarding it is bound to the wrappee.3

In essence, for the sake of the Forwarding, the Receiving object should not know the details of the Sending object. This stackoverflow answer 4 explains in details the "this" and the "self" keywords in Java and Python that will give you some understanding of the Forwarding breakdown.

However, I have found out also different answers in the context of Delegation and Forwarding. I sense that there can be mixed opinions 5, 6

https://en.wikipedia.org/wiki/Delegation_(object-oriented_programming)#Language_support_for_delegation

https://en.wikipedia.org/wiki/Delegation_(computing)

https://en.wikipedia.org/wiki/Forwarding_(object-oriented_programming)#Delegation

https://stackoverflow.com/a/37657923/1958683

https://stackoverflow.com/questions/7816011/in-oop-what-is-forwarding-and-how-is-it-different-from-delegation

https://stackoverflow.com/questions/1384426/distinguishing-between-delegation-composition-and-aggregation-java-oo-design

• candied_orange: The OPs example never refers to this one way or another. Leaves me wondering if Java can even truly "forward"
• Filip Milovanović: @candied_orange - Actually, i think it can, but it can't delegate. This whole thing is confusing when thinking in modern terms; I think it originated in the context of classless, prototype-based inheritance (an instance has a parent instance); so the thinking is, if an object b inherits a, there are two instances. If you then call a method on b (pass a message to b), if the dispatch mechanism doesn't find a corresponding concrete function on b, it automatically resolves it to a concrete function on a. The crux of the issue is how the implicit this parameter is bound.
• Filip Milovanović: @candied_orange - If you think about class-based languages in this way, the standard behavior that we are all used to is that in the function that finally gets called, this gets bound to the a instance (even though the original call was on b), so any mention of this.whatever in that function resolves to a.whatever (base class can't explicitly refer to any derived member). If I'm not mistaken, that's forwarding according to this definition.
• Filip Milovanović: @candied_orange - Delegation involves late binding of this, and there, this gets bound to the original source, b, so this.whatever sends the message back to the original object. To do this, the language has to provide the ability to write code where you can refer to this.someMember even if someMember hasn't been defined anywhere within that scope; then when this is bound, it all works out if the bound objects has someMember. You can do this in JavaScript using call; e.g. let f = function () { console.log(this.x); }; let o = { x: 42 }; f.call(o) (doesn't work with lambdas).
• candied_orange: @FilipMilovanović if this is only about how this is bound can't you mess with that using the famous getThis trick?