How to signal that a method chain should not continue?

When doing method chaining, you have methods that return the object allowing you to continue the chain. However, you need to get values out of the object somehow.

Usually I’ve added a method that returns a value at the end, but this complicates matters if you add to the chain and that return method may not be valid anymore.

The way I view it each time you add a method onto a chain you are refining your result until you get your desired answer in the last method call. Having a final output method creates a restriction in that it needs to know about the last operation to know how to display the result.

Maybe you have a method that results in a string and one that results in an array your output method has to deal with both those cases. What if you add a method that stores your string result somewhere new? Now you have to update the output method to handle that case too.

Is there a way of letting a method know it’s the last in the chain so should output its result?

You get the values out of the returned object in the usual way.

var result = myObject.SomeProperty;

For extended chaining techniques, chained methods will often return a result that conforms to a particular interface. For example, most Linq methods in the .NET Framework return a result that conforms to IEnumerable<T> or IQueryable<T> (i.e. a generic collection).

Method chaining is not so much a technique as a useful bit of syntactic sugar, and the details will generally depend on the semantics that you want to provide.

One common approach is for each method to mutate the object and return this; for example, new Person().setName(name).setRank(rank).setSerialNumber(serialNumber). With this approach, there’s no need to know what the “last” method is, because you can terminate the chain at any point and still have the same Person object.

Another common approach is to have a dedicated mutable “builder” object that lets you apply method chaining to modify the builder, before ultimately calling a build method to create an immutable object; for example, new StringBuilder().append(s1).append(s2).append(s3).toString(). The build method is then automatically the “last” method. (In fact, this is a special case of the previous approach; the real “last” method was append(s3), and then I called toString() on the result object after I finished modifying it.)

A less-common approach is to split the difference between the above two approaches: if the target class is not completely immutable, but has some requirements for its initial setup, you can still use a builder class just for that initial setup. The build method can then perform the necessary validation (or delegate to a constructor that does so). For example, if Person requires name and age, then we might allow both new PersonBuilder().setName(name).setAge(age).build().setHeight(height) and new PersonBuilder().setName(name).setAge(age).setHeight(height).build().

You can “signal” that a method chain should not continue by making the return type of the method void. This wont “output” much but it will stop the method chain. Also, depending on your language, you can stop it by returning a primitive like int. But any time a method returns an object, that has a method on it, the chain can keep going.

In any OO language what normally comes out at the end (and at every step along the way) of a method chain is something called a “nameless temporary object”. It’s nameless only because we didn’t assign it to something to give it a name. Instead we just stuck a dot next to it and called one of it’s methods. Once we do we get another “nameless temporary object” (which might be exactly the same object as before just now in a different state). You can chain over and over until you get

(1) the behavior you want
(2) the type of object you want
(3) the object in the state you want

If the behavior is all that was wanted then you’re finished. If you wanted the last two then just stop chaining and you can give this a name by assigning it to something (or just pass the whole mess into something).

Greet.hello("world").hi("Mom");                                 // (1)
String max = Math.max(1,3).toString();                          // (2)
System.out.println( new Person().setName(name).setRank(rank) ); // (3)

Typically every method in a chain is an “output” method. You just stop when you have what you need.

Also, note that this:

Person person = new Person();
person = person.setName(name);
person = person.setRank(rank);
System.out.println(person);

does exactly the same thing as (3). A big advantage of a method chain is you don’t have to stop and give things names that don’t need names.

Filed under: softwareengineering - @ 23:16

Thẻ: method-chaining, patterns-and-practices

Thiết kế website giá rẻ

Danh mục

How to signal that a method chain should not continue?