I think in that example State design pattern can’t be used anymore,
then you will be forced to replace it by “ifology”.
I’m looking for answer too;]

I see the point, at this moment all State and CalculatorNumber objects are newable. But lets go further with this example. Let’s say the state objects have dependency to object A, so I will have to ask for it in a constructor. In that case all state objects become incjectables while Operator objects and CalculatorNumber remain newable. In current implementation state objects ask for newables (Operator, CalculatorNumber), but after adding the dependency A, I would break rule: “Injectable can never ask for a non-Injectable (Newable) in its constructor”. What do you suggest, how to deal with new requirement??

cheers

1) yes the new operators, may be a problem, but in this case they are not since what they are instantiating are essentially new operations, which are leafs. see: http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/ This is a thin line to walk, since as soon as your operations become more of services the whole thing will need to become refactored for proper DI. So my comment is that new operators here are OK for now, since they don’t prevent testability and there is no need to control the wiring in a different state

2) This is another tricky one. I don’t like it out of principle, but again it is not a problem since there is no global state hidden in the operators. But, I don’t like it since it is too easy for someone to add state and bring the whole thing down, so I am with you that it should be avoided. A better way to do that which is structurally equivalent is through Enumerations in java, as that is a bigger hint that you should not put state in there as they are global.

looking at Marcin’s solution it seems it is well OO designed and implemented. Anyway I think there are places for fixes.

1) I am not sure, but I think he mixes business concert with graph instantiation. If you take a look at this class http://bitbucket.org/niedvied/calculator/src/0e9853c1f48f/blog/tdd/01_Calculator/src/calculatorstate/AddingSecondNumber.java and all other state classes, there is plenty of new operator. He creates other State and CalculatorNumber objects. According to yours advises all new operators should go to factories.

2) http://bitbucket.org/niedvied/calculator/src/tip/blog/tdd/01_Calculator/src/operator/OperatorProvider.java. What about this static initialization and field ??

Can you conform my issues? If I am right can you explain how to fix it.

I’d be grateful, thx

It was my first application with tests and I think it was a very
positive experience.

* I almost didn’t run application during development, very cool;]
* I can refactor without stress and I my application still work at the end.
* Writting test wasn’t to much overhead

I know It’s like from books feedback but It’s really true.

It would be great if you find some time to review my code

PS. Sorry for my english

http://bitbucket.org/niedvied/calculator/changeset/0e9853c1f48f/

Comments are welcome too.

I started a fork at bitbucket
https://bitbucket.org/michaelkebe/misko-hevery-blog/overview/

Any comments are as always welcome.

I’ve been working on your TDD exercise, and i’ve pretty much got all functionality of the calculator. TDD really makes me being more focused and confident that my code is working as expected. It has been a great practice, especially because it made me understand my bad decisions!

After implementing sum and decimals, i’ve noticed that the CalculatorController was getting too big, so I’ve created an interface (Calculation) and a single implementation (StandardCalculation) and passed it to the Controller. The goal of this class was to take care of the calculation itself, while the CalculatorController would do the conversion between character->number and back to string for the view. However, i now can tell that it was a bit too premature. I’ve ended up getting a big StandardCalculation class (carried away with adding more functionality and not stopping to think about refactoring it), and also realized that the interface definition that i’ve forced at that point was not the best choice. It now seems not flexible at all because this Calculation interface only accepts the numbers digit by digit (funny, i’ve realized this when refactoring test code of CalculatorController).
Another thing that I’ve noticed is that i’ve ended up almost replicating my tests between the CalculatorController and StandardCalculation. Not sure how to improve that though..
Other than that, i’m having plenty of conditionals in the StandardCalculation class, because I’ve ended up not dividing concerns in this class, so I should now try to refactor it to look more OO.

Here’s a gist with the most important classes. Anyone feel free to comment on it: http://gist.github.com/244657

Cheers,
Raul