When does it make sense to return this-reference?

Question

Currently I can think of only three good reasons to return this in a (public) method, namely:

1. (mmyers) when implementing fluent interfaces, e.g.

   public class X
   {
     ...
     public X enableValidation()
     {
       setValidation(true);
       return this;
     }
     ...
   }
   

2. (Jon Skeet) for identity conversions, e.g.

   public class X
   {
     ...
     public X toX()
     {
       return this;
     }
     ...
   }
   

3. (Dave Ray) implementing a clone() or copy() method on an immutable object, e.g.

   @Immutable
   public class X
   {
     ...
     public X copy()
     {
       return this;
     }
     ...
   }
   

Are there any other useful scenarios in an object-oriented language in which you would return this or self from a method?

Answer 1

String.toString() :)

On a more serious note, there are similar "convert to [x]" scenarios where it's okay to just return "this"... but I can't think of very many other situations.

Answer 2

Any implementation of a clone() or copy() method on an immutable object.

Answer 3

If you are creating chaining operations (however this might not be very OOP'ish - Law of Demeter, etc).

Example (not that it makes a lot of sense):

public class X 
{
   public X Add(int i) 
   { 
      this.Value += i; 
      return this;
   }

   public X Subtract(int i) 
   {
      this.Value -= i;
      return this;
   }

   public int Value 
   {
      get;
      set;
   }
}

new X().Add(4).Subtract(5).Value;

Answer 4

C++ does this all the time to allow cascading operators.

for example the << operator always returns itself (ostream) so that you can cascade the calls in such a way:

std::cout << "call 1" << "call2" << std::endl;

The only language which I believe this cascading effect is popular is C++.

Answer 5

Take the following implementation.

public interface Monitorable {
   public Statistics getStatistics();
}

public interface MonitorManager {
   public Monitorable getMonitorable();
}

class MonitorableService implements Monitorable, MonitorManager {
   public Monitorable getMonitorable() {
      return this;
   }
}

// Meanwhile somwhere else...
MonitorManager manager = getMonitorManagerFromSomewhere();
Monitorable monitorable = manager.getMonitorable();

I admit this is rather contrived, but the overal pattern/message should be clear.

Here I do not need to know the MonitorManager is implemented by the Application class. Nor do I need to know that Monitorable is implemented by Application.

Here polymorphism is used to encapsulate the implementation details of Application. Which is not a public class. This is a very common pattern, and can be seen in a wide variety of projects.