While experimenting with adding context menus and alert dialogs to the app, I discovered a cool Java feature that I didn’t know existed: method chaining. By taking normally void methods and instead having them return a reference to their object, you can turn this:
Person p = new Person();
p.setName(“Bill”);
p.setAge(40);
p.setZip(01701);
into this:
Person p = new Person();
p.setName(“Bill”).setAge(40).setZip(01749);
As far as I can tell, efficiency doesn’t change when using method chaining vs. the traditional way. But it looks a lot cleaner and I may start using it.
The only problem with method chaining in this way is that it is a bit harder to determine the semantics of the method. If you have a method that returns void it is clear that it *must* be a side-effecting method. Something in the universe has changed in a way we can never get back after that method is called. If you return something, though, what does that mean? Has the object instance been modified in some way? Has a new instance been created that is a copy of the original one but with the Name (for example) changed? Your Person example above has the same interface to it that an immutable Person would too, because that is the only way to do it, but it has completely different semantics than an immutable Person object.
So, while it’s easier on our fingers to do the method chaining version, I would suggest against it unless the semantics of the object matches the interface. Otherwise it becomes very easy to be confused by the API and misuse it, and a good API should make it very hard to misuse.
One attempt at this is Command Query Response Segregation (CQRS) from Eiffel. It separates doing things from querying them. Microsoft has a series of posts called CQRS Journey. CQRS does have some problems, for example some atomic operations cannot be expressed well in it.
Good point on mutable/immutable object APIs. Thanks for the info.