Loading ...
Sorry, an error occurred while loading the content.

42983Re: [XP] Simplicity pressures

Expand Messages
  • alex@jguru.com
    Feb 6, 2002
      On Wed, Feb 06, 2002 at 10:13:48AM -0500, Ron Jeffries wrote:
      > In an XP team, this situation is normally resolved by... looking at
      > the specific case and seeing which way is simpler. The point of
      > removing duplication is simplicity.
      > Got an example?

      I think Danil's example was C++ templates. I had a similar example in
      Java Inner Classes in my recursive descent solution to Bill Wake's
      TFC. (Still on line at
      http://www.purpletech.com/xp/wake/src/FormulaEvaluator.java ).
      My evaluator functions for evaluateExpression and evaluateOperation
      were identical except for a function that was called on the inside of
      a loop.

      Since Java doesn't have function pointers, I was forced to decide

      (a) leaving the two nearly-identical methods (big smell, begging to be

      (b) using a switch (if (mode == EXPRESSION) evaluateTerm(); else
      evaluateOperation();) in two different places in the function

      (c) using an inner class (evaluator.eval() made the function itself
      look OK, but made the *calling* code more indirect, making the whole
      sequence of recursion, which is hard to grasp anyway, even harder to

      I chose C at the time, but I'm thinking of rolling back to A.

      - A

      P.S. I just thought of another solution -- make it a separate class,
      call an evaluateNext() method from inside the loop, and then make a
      subclass that overrides evaluateNext() for each type of next token --
      that's way overkill though.

      Alex Chaffee mailto:alex@...
      jGuru - Java News and FAQs http://www.jguru.com/alex/
      Creator of Gamelan http://www.gamelan.com/
      Founder of Purple Technology http://www.purpletech.com/
      Curator of Stinky Art Collective http://www.stinky.com/
    • Show all 9 messages in this topic