This week's book giveaway is in the Design forum. We're giving away four copies of Building Microservices and have Sam Newman on-line! See this thread for details.

In the interest of brevity (and keeping my sanity... UBB), I'll just post the snippets of changed code from now on. I'll refresh the complete listing at appropriate intervals which should be fewer and farther apart.
Step 9 - Refactoring
1. Rename field "operator" to "operation" to make the code more gramatically correct in describing what it does.
2. Apply the Extract Method refactoring to the addition operation. We will call the new method performOperation.
<pre>
class OOCalc {
...
private String operatoroperation;
public static final String ADD = "+";
...
public double getResult() {
if ("+".equals(operator)) {
double op1 = ((Double)operandStack.pop()).doubleValue();
double op2 = ((Double)operandStack.pop()).doubleValue();
result = (op1 + op2);
}
return result;

if (operation != null)
return performOperation();
else
return 0.0;
}

public void in(String operatoroperation) {
this.operation = operation;
}

Step 10 - SUB and MUL implemented <pre> public class OOCalc ... public static final String ADD = "+"; public static final String SUB = "-"; public static final String MUL = "*"; ... public double getResult() { if (operation == ADD) { ... return (op1 + op2); } else if (operation == SUB) { double op1 = ((Double)(operandStack.pop())).doubleValue(); double op2 = ((Double)(operandStack.pop())).doubleValue(); return (op2 - op1); } else if (operation == MUL) { double op1 = ((Double)(operandStack.pop())).doubleValue(); double op2 = ((Double)(operandStack.pop())).doubleValue(); return (op1 * op2); } else { return 0.0; } } // deleted performOperation() </pre> Notice I've backpedalled a bit and moved the calculations back to getResult() and deleted the performOperation. I decided to do this because I wasn't getting a whole lot from the previous refactoring. Now I can see the duplication and I have a better view of where I actually want to go. Continue... [ March 29, 2002: Message edited by: Junilu Lacar ]

Step 10 (continued) - extract constants to another class. Let's use Ilja's class name instead: Operation <pre> // Operation.java

package calc; public class Operation { public static final String ADD = "+"; }

// OOCalc.java package calc; public class OOCalc ... public static final String ADD = "+"; public static final String SUB = "-"; public static final String MUL = "*"; ... public double getResult() { if (operation == Operation.ADD) { ... </pre> Then update OOCalcTest.testAddition: <pre> calc.in(OOCalcOperation.ADD); </pre> Compile and test. Still green bar. After following the same steps to move SUB and MUL we have this: <pre> // Operation.java package calc; public class Operation { public static final String ADD = "+";

public static final String SUB = "-"; public static final String MUL = "*"; }

// OOCalc.java package calc; public class OOCalc ... public static final String SUB = "-"; public static final String MUL = "*"; ... public double getResult() { if (operation == Operation.ADD) { ... } else if (operation == Operation.SUB) { ... } else if (operation == Operation.MUL) { ... </pre> [ March 29, 2002: Message edited by: Junilu Lacar ]

Next I see that Operation is more of a Strategy, with ADD, SUB, and MUL being concrete strategies. I'll head the refactoring that way then. I'll make all Operations recognize the perform() message. Looking at the duplication pattern in OOCalc again, it looks like perform() will need to take a Stack as a parameter. So I make Operation an abstract class and add perform as an abstract method: <pre> // Operation.java package calc; import java.util.Stack; public abstract class Operation { ... public abstract double perform(Stack operandStack); } </pre>

Then create the concrete subclass and copy the addition calculation logic from OOCalc.getResults(). <pre> // Addition.java package calc; import java.util.Stack; public class Addition extends Operation { public double perform(Stack operandStack) { double op1 = ((Double)(operandStack.pop())).doubleValue(); double op2 = ((Double)(operandStack.pop())).doubleValue(); return (op1 + op2); } } </pre> So now I can change the declaration for Operation.ADD to be: <pre> public static final OperationString ADD = new Addition()"+"; </pre> [ March 29, 2002: Message edited by: Junilu Lacar ]

Now to make some adjustments to OOCalc. After changing the type of ADD to Operation, I need to overload OOCalc.in() to accept an Operation. I'll keep it in a new private member field called _op (now adopting the convention that Martin Fowler uses in his book on "Refactoring"). <pre> public class OOCalc { ... private Operation _op; private String operation; ... public double getResult() { if (_operation == Operation.ADD) { // delete addition calculation return _op.perform(operandStack)(op1 + op2); } else // separating this old stuff for now if (operation == Operation.SUB) { ... } public void in(Operation op) { _op = op; } </pre> No need to change OOCalcTest since our changes don't affect the line <pre>calc.in(Operation.ADD);</pre> Compile and test. Still Green bar. Whew!

Following the steps for addition, we do the same for subtraction and multiplication. After that we have the following code: <pre> //Operation.java package calc; import java.util.Stack; public abstract class Operation { public static final Operation ADD = new Addition(); public static final Operation SUB = new Subtraction(); public static final Operation MUL = new Multiplication();

public abstract double perform(Stack operandStack); }

//Addition.java package calc; import java.util.Stack; public class Addition extends Operation { public double perform(Stack operandStack) { double op1 = ((Double)(operandStack.pop())).doubleValue(); double op2 = ((Double)(operandStack.pop())).doubleValue(); return (op1 + op2); } }

//Subtraction.java package calc; import java.util.Stack; public class Subtraction extends Operation { public double perform(Stack operandStack) { double op1 = ((Double)(operandStack.pop())).doubleValue(); double op2 = ((Double)(operandStack.pop())).doubleValue(); return (op2 - op1); } }

//Multiplication.java package calc; import java.util.Stack; public class Multiplication extends Operation { public double perform(Stack operandStack) { double op1 = ((Double)(operandStack.pop())).doubleValue(); double op2 = ((Double)(operandStack.pop())).doubleValue(); return (op1 * op2); } }

//OOCalc.java package calc; import java.util.Stack; public class OOCalc { private Stack operandStack = new Stack(); private Operand _op; private String operation;

public double getResult() { if (_op == Operation.ADD) { return _op.perform(operandStack); } else if (_op == Operation.SUB) { return _op.perform(operandStack); } else if (_op == Operation.MUL) { return _op.perform(operandStack); } else return 0.0; }

public void in(String operation) { this.operation = operation; }

public void in(double operand) { operandStack.push(new Double(operand)); }

Almost done... We can now eliminate the remnants of the old String operation and arrive at the polymorphic behavior that we so wanted to have in the beginning. In addition, we get to add the old "guard condition" that we also wanted. <pre>//OOCalc.java package calc; import java.util.Stack; public class OOCalc { private Stack operandStack = new Stack(); private Operand _op; private String operation;

public double getResult() { // guard condition if (_op == null) return 0.0;

return _op.perform(operandStack);

// no need for this anymore: if (_op == Operation.ADD) { return _op.perform(operandStack); } else if (_op == Operation.SUB) { return _op.perform(operandStack); } else if (_op == Operation.MUL) { return _op.perform(operandStack); } else return 0.0; }

public void in(String operation) { this.operation = operation; }

public void in(double operand) { operandStack.push(new Double(operand)); }

One more thing to take care of. OK, so we've got OOCalc calling Operations polymorphically now. We're still violating the OCP in Operation because if we need to add an operation, we need to create a subclass and modify Operation. It would be nice if we could eliminate that duplicate work. Well, we can and here's how: Notice that we don't really need multiple instances of concrete Operations. One instance of each will do. So, I'll turn all the concrete Operations into Singletons. I'll add a private constructor and a static getInstance() method to each concrete subclass. After doing this, I can eliminate the constants defined in Operation. How does this affect my other code? Well, only the client code, as represented by OOCalcTest, will be affected. So instead of invoking the in(Operation) method with Operation.ADD we'll just invoke it with Addition.getInstance(), Subtraction.getInstance(), and Multiplication.getInstance(). A little more typing here maybe but look what happens: all we have to do now if we add a new operation is to create a new subclass of Operation! Here are the changes and the implementation of the Division operation: <pre> //Operation.java package calc; import java.util.Stack; public abstract class Operation { public static final Operation ADD = new Addition(); public static final Operation SUB = new Subtraction(); public static final Operation MUL = new Multiplication();

public abstract double perform(Stack operandStack); }

//Addition.java package calc; import java.util.Stack; public class Addition extends Operation { private static Addition _instance;

public static Operation getInstance() { if (_instance == null) _instance = new Addition(); return _instance; }

//OOCalc.java package calc; import java.util.Stack; public class OOCalc { private Stack operandStack = new Stack(); private Operation _op;

public double getResult() { if (_op == null) return 0.0;

return _op.perform(operandStack): }

public void in(double operand) { operandStack.push(new Double(operand)); }

public void in(Operation op) { _op = op; } } </pre> Then make the appropriate changes to OOCalcTest Compile and test. Green bar [ March 29, 2002: Message edited by: Junilu Lacar ]