Beck starts by explaining that what he did in the last chapter, making the multiplication operation on a
Dollar object return a new instance of a
Dollar object is to turn
Dollar into what's known as a "Value Object". A Value Object cannot be mutated and so any message that changes the "value" in a Value Object should be made to produce a new object.
Another property of a Value Object is that it should implement
equals. While implementing
equals he introduces the "Triangulation", which is the tactic of adding a test to help you refactor the implementation of a feature. He explains that it is a helpful tool when the refactoring is not obvious.
He finishes by implementing a more generalized
equals and adds, "Equal Null", Equal object" as things he may want to implement but don't have to implement now.
This short chapter, that is mainly about Triangulation as a tactic in TDD, has an example of the things I like and don't like about the book so far. I like how the insights seem to casually emerge in the flow of trying to implement multi-currency money with TDD. I don't like how often he expresses feelings or points of view without explaining what's behind them.
In trying to explain the value of using Triangulation he asks:
What axes of variability are you trying to support in your design?
I immediately felt that this was an important question in developing software in general, not just a question to ask when using Triangulation. To answer the question means to have to lay out what you expect to stay the same and what you expect to change. Another way of putting the question would be to ask: "What are the seams you are putting in your objects that will allow that object to do different things?". I think understanding that question for every piece of software I write could make it much easier to write that software.
You aren't thinking about the implementation of
equals(), are you? Good. Me neither.
Triangulation feels funny to me.
That will let us make “amount” private, as all good instance variables should be
The above quotes are the things I don't like about the way Beck writes. He mentions these things as if they should be obvious to the reader. They are not to me. I think they may not be to anyone who doesn't share his background in programming. It's as if the book were written for his programming friends and colleagues who mostly agree with him but wanted to learn about TDD. I think that makes the book easier to write, since he had a specific audience in mind but it makes some of parts of the book harder to understand who isn't in that audience.
For instance, why shouldn't we be thinking about the implementation of
equals()? What's wrong with that?
Why should Triangulation feel "funny"? What's behind that feeling?
Why should instance variables be private? What makes that a better design or better code?
I think Beck did the best he could. He could not have known that the book would be read by people who don't share his background or sensibilities. Programming wasn't as a big an industry as it was when he wrote the book and there weren't so many different people trying to become better programmers.