Meaningless Drivel is fun!*
The moose likes OO, Patterns, UML and Refactoring and the fly likes OOCalculator >> Sidebar >> Mike Matola Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "OOCalculator >> Sidebar >> Mike Matola" Watch "OOCalculator >> Sidebar >> Mike Matola" New topic
Author

OOCalculator >> Sidebar >> Mike Matola

Michael Matola
whippersnapper
Ranch Hand

Joined: Mar 25, 2001
Posts: 1751
    
    2
[ MM sidebar step 1 ]
OK, I'll take the next shot, picking up where Terry left off. I'm guessing that any comments should go in the main thread.
First, I don't like the testAddition() method proposed by Junilu that has calculate() returning the result.

The initial direction of OOCalc was to maintain a result as a state of the calculator, so I'm going to continue with that notion and have calculate() deal with the inputting and calculating and use our already established getResult() for returning any result.

I added the new version of testAddition() to the test suite then immediately commented it out, knowing that it's more than I can tackle in this simple-steps approach.
Terry's right that we need some way to parse the input string. But when I think about breaking up our simplest case of "10 + 5" I return to the idea of state. If we're storing the result of the calculation in our OOCalc object, shouldn't we also store our current operands and operator as state? So here's my first shot at a test of the parsing.

But then I realize again that this is more than what I want to tackle because with these getXXX() methods I end up testing a calculated state when I never even tested the initial state. So I comment it out the testParsingInput() method too.
The starting place then will be a new version of testInitialResult() called testInitialValues().

Add this to OOCalcTest and it fails to compile. (Yellow light?) I add the following code to OOCalc to get things running.

Everything compiles and passes!
Michael Matola
whippersnapper
Ranch Hand

Joined: Mar 25, 2001
Posts: 1751
    
    2
[ MM sidebar step 2 ]
Next I uncomment testParsingInput() in OOCalcTest and it fails to compile.
I add the simplest possible code to OOCalc to get the test to pass:

Everything compiles and passes!
But at this point I look at my calculate method. Before I add any code to do the calculation I think I'd like to break out all that parsing stuff into another method. So I refactor calculate().

Everything compiles and still passes!
Michael Matola
whippersnapper
Ranch Hand

Joined: Mar 25, 2001
Posts: 1751
    
    2
[ MM sidebar step 3 ]
Now I'm ready to tackle testAddition(). When I uncomment testAddition(), OOCalcTest (somewhat surprisingly) compiles. This makes sense: at this point testAddition() hasn't added any new methods, but calculate() isn't doing any calculation yet. But things fail when I run the test through JUnit. The test expects "15.0" as the result, but it's getting the initial value of "0.0".
So on to calculate(). At this point what I really want to do is write all sorts of stuff to handle the various operators (probably using a factory method to generate an instance of an Addition class that is a subclass of an abstract Operation class, etc.). But in keeping with the spirit of the simplest possible implementation, here's what I write. And yes I know it does nothing if the operator isn't "+", but since I haven't written those test cases, I'll hold off on coding the other operations.

Everything compiles and passes! Back to the regularly scheduled thread...
Michael Matola
whippersnapper
Ranch Hand

Joined: Mar 25, 2001
Posts: 1751
    
    2
So here's a listing of the sidebar calculator and test code.

 
Don't get me started about those stupid light bulbs.
 
subject: OOCalculator >> Sidebar >> Mike Matola