If-less code: is it just an intellectual challenge or is it concretely useful?

Question

A friend of mine is talking about these design techniques regarding state transitions of an object (he's a Java guru, btw), performed without having a boolean myState member, but rather declaring the myState member as an object that implements the same interface of the "owner" one.

Ok, I've been too much cryptic, so you can find the discussion here, with code samples.

Personally, I'm excited with the approach, as my friend explained me the philosophy behind it; I also think it is pretty coherent, from a design perspective. My concerns, by the way, are mainly about performance and memory usage, as maybe compile-time and run-time optimizations enter the game. Since I don't know JIT compiler and JVM internals, I'm curious to have a wider opinion.

What do you think about?

Answer 1

The state/strategy patterns are tried and true. They aren't just an intellectual exercise. If you're thinking about performance and memory usage now...you are probably shooting yourself in the foot. Get code...then profile.

Answer 2

Its a very useful technique.

You don't propagate if(myState) statements around your class.
You can extend the technique to many states and only have to change what you assign to the myState member.

As for performance and memory usage, wait until you've got something to measure - maybe you need to try both ways and measure them both when they're working.

Answer 3

It sounds like you're asking whether there's a "concretely useful" benefit to using the state design pattern, to which I'd say definitely yes, particularly if your app actually relies heavily on the "state" of its objects. A popular canonical example is that of the video player, which is always in one state, and can only transition into different states depending on the state it's currently in (e.g., it can't stop if it's already stopped, but it can play, and it can rewind, and so on).

While that particular example can be managed relatively easily with a handful of if/else/switch-type conditions (if (isStopped()), play(), etc.) because there aren't that many states to deal with, when states or their transition rules start to become more numerous or complicated, the state pattern absolutely becomes quite valuable, as without it, your code tends to accumulate elseifs like crazy, and things become less and less readable and manageable over time.

So yes, in general, if you find your objects' behaviors varying according to their states (if isStopped() play() / elseif isPlaying() stop() / elseif (isBroken() fix()), etc.), then yes, do consider using the State pattern. It's a bit more work up front, but generally well worth the effort, and done right I doubt you'd notice any significant overhead simply for the using of it.

Head First Design Patterns offers a great description of its hows and whys, too -- I highly recommend picking up that book to pretty much anyone writing object-oriented code.

Answer 4

Yes, this works, and is cool ... up to a point (the point where it becomes silly). You can even use anonymous inner classes, if you must, even enums.

Answer 5

I have to disagree - useful design patterns aside, this particular example is ridiculous overkill:

• a 15-line class with an easily-understandable process
• became a 50-line class with an obfuscated purpose

I fail to see how this is an improvement - it violates YAGNI¹ and ASAP², bloats the code, and reduces efficiency (multiple objects instantiated to do the job when not required).

As an intellectual exercise, mildly interesting. As a programming habit, terrifying! ;-)

---

¹ YANGI = You Ain't Gonna Need It

² ASAP = As Simple As Possible