Comments for Fluffyelephant

Comment on Robot-arm på sonen by toy helicopter

toy helicopter — Wed, 21 Dec 2011 08:18:38 +0000

Glad to visit this blog, keep it going.

Comment on Return this by Ruudjah

Ruudjah — Sun, 26 Jun 2011 20:02:50 +0000

This solution I think is mainly going beyond the goal of fluent interfaces. You can find more solutions for this problem on the web, but the ‘fluent’ part then becomes not so fluent anymore. The syntactical additions you’d need for this to work properly are not worth the effort to maintain fluency in the code.

Comment on Return this by Matt

Matt — Sun, 26 Jun 2011 16:51:13 +0000

Formatting ate my generics:

interface FooFluent> {
class FooConcrete implements FooFluent {

Comment on Return this by Hristo Deshev

Hristo Deshev — Sun, 26 Jun 2011 16:33:05 +0000

Smalltalkers have been doing this for years (and actually that’s where the technique came from). I’d advise readers to play for a bit with that language. You’ll gain tons of insight about object-oriented programming and your Java will get better. A lot better.

I hear Pharo is a cool and friendly Smalltalk implementation you can start with: http://www.pharo-project.org/home

Comment on Return this by Matt

Matt — Sun, 26 Jun 2011 16:15:54 +0000

You can still do this with concrete classes by adding a generic argument to your interface's type that takes a subtype of itself:

	interface FooFluent {
		T setFoo(int foo);
		T setBar(int bar);
	}

	class FooConcrete implements FooFluent {
		public FooConcrete setFoo(int foo) {
			return this;
		}

		public FooConcrete setBar(int bar) {
			return this;
		}
	}

Comment on Return this by Paul Keeble

Paul Keeble — Sun, 26 Jun 2011 15:36:45 +0000

Cloning rarely costs enough to matter. But by cloning the object we ensure that multiple users of the object aren’t impacted by the changes. Strings being very much treated as values are an example of objects where changing them with clones makes far more sense, not because its the fastest implementation (although it can be) but because its much safer.

Concurrency is here and being used. Immutability is a sure fire way to make your objects work properly under multiple threads.

In a nuttshell the cost of cloning is normally so small you should ignore the performance impact and instead treat values as immutable. Life will be easier in the long run, they are certainly easier to debug than chains of modifiers.

Comment on Return this by hmottestad

hmottestad — Sun, 26 Jun 2011 15:23:38 +0000

True. In some cases you would have to make a choice between polymorphism and fluent interfaces (btw, thanks for letting me know what it’s called).

Comment on Return this by Ross Bonner

Ross Bonner — Sun, 26 Jun 2011 15:22:37 +0000

The pattern you refer to is commonly known as a fluent interface, see ... http://en.wikipedia.org/wiki/Fluent_interface.

Comment on Return this by hmottestad

hmottestad — Sun, 26 Jun 2011 15:19:28 +0000

How about now?

Comment on Return this by Ruudjah

Ruudjah — Sun, 26 Jun 2011 14:00:08 +0000

This technique is called fluent interfaces (http://en.wikipedia.org/wiki/Fluent_interface). This technique has a problem in Java: polymorphism. Suppose you have an interface SomeInterface, with a getter/setter Name (getName, setName). In the setter, you’d require implementors to return the interface type. Now, when you write something like

SomeInterface someInstance = new ConcreteClass().setName(“I has a name”);

It works, because setName is part of the interface specification. ConcreteClass now has a getter/setter for amount, getAmount and setAmount. When constructing, you might want to also set the amount, so you’ll endup with

SomeInterface someInstance = new ConcreteClass().setName(“I has a name”).setAmount(42);

This won’t work, because amount is a property of the concrete class, not for the interface. You either have to not use polymorphism or ditch the fluent interface concept.