There are certainly times when closures are useful, but @Loup’s suggestion is certainly not one of them; there’s another important oo-concept, viz encapsulation, after all

@argh: greybeard addressed most of my points, but for an example other where it should have been used : http://code.google.com/p/js-test-driver/source/browse/trunk/JsTestDriver/src/com/google/jstestdriver/ui/CapturedBrowsersPanel.java. The contains method on line 80 here totally argues that it needs a FirefoxSlaveBrowser, IESlaveBrowser and it should ahve a getIcon rather than all this. The if conditional would totally go away, and I think it is more readable.

@anonymous: When I ask such a question, I lay down a few requirements first, which I should have mentioned in the blog post. One is, I do tell them that initially we have a few operators, but there might be a need to add more later. And I do ask how it would be extensible in the sense that even if the source code is not directly available, you should be able to add an operation (this might be a later follow up after an initial iteration, of course).

@Eric: For conditional statements, I have more interesting questions, which check his control structure flow. Something which involves both ifs and fors. for 3.) is an interesting idea, any suggestions or examples for that? I am not sure exactly what you are expecting there. Something else I love to ask is what makes classes and methods untestable, or give an example of a horridly untestable class including static initialization blocks and ask how they would test it.

@Loup, I love it, except in Java, functions are not a first class citizen. I love closures, and I wish Java had them. But until then, we are stuck with this approach.

To comment on the post itself:

I’m definitely adding this to my interviews, using Eric’s three methods!
I actually wrote a much more complicated version of this when I implemented Leibnitz, my clone of Apple’s Graphing Calculator. Every item in the parse tree can not only evaluate itself, but also render itself. Addition and multiplication are actually N-ary, so a single node can sum or multiply an arbitrary number of values. This helps with rendering parentheses cleanly.

With this scheme, a `Node` is nothing more than a pair of functions : `eval()` and `to_string()`. You don’t even have to use inheritance. Sure, you still have to define `eval()` and `to_string()` for each case, so my solution looks hardly better than yours.

Except when talking about the “step further” you mentioned. I can take this step easily, after the fact, without modifying anything: I just have to write functions which generate `eval()` or `to_string()` for subsets of all possible cases. Such a subset could be the binary operations. I just need to write a `Node gen_eval(Binary_op)` function or somthing.

Parameter passing (here in a constructor) is a simple concept. Even when the “thing” being passed is a function, this is simpler than class polymorphism. The only reason the more complicated, less flexible approach was the right one here is because my approach is more verbose in mainstream OO languages.

The simpler concept is more verbose. Kind of silly, don’t you think?

1. Polymorphism
2. Conditional statement
3. Data-driven

That would test his versatility, because there are times for each of them.

The main reason for using polymorphism instead of conditionals/switch-cases is to be able to vary the logic based on discreet selectors. In this case, it’s operands in an expression tree, but in others it may be how to notify entities when an exception is encountered. Or what the proper way is to compute a cash disbursement based on potential receivers’ account status. These are just a couple of areas where this style can be applied.

Of course, taken to the extreme, trivial logic ends up segregated from the main flow and readability can be negatively impacted. Like most things in the programming craft, there are tradeoffs to consider and all that lot.

This example is very well covered in the book “Refactoring” by Fowler and Beck (IIRC). There are numerous techniques covered that can really help a developer decide when to use these kinds of approaches.

HTH.