Chapter 3: Equality For All

Summary

Beck starts the chapter by introducing the concept of a value object. A value object cannot be mutated and so any message that changes the "value" in a value object should produce a new object. Dollar is on its way to becoming a value object. The refactoring in the previous chapter made the times method return a new Dollar object instead of mutating the amount.

Another property of a value object is responding to equals. This makes it comparable to other value objects of the same class.

public void testEquality() {
    assertTrue(new Dollar(5).equals(new Dollar(5)));
}

He first implements equals by hardcoding the return value of equals.

public boolean equals(Object object) {
   return true;
}

He uses this as an opportunity to introduce triangulation.
Triangulation is adding a test to drive you towards a refactoring. A refactoring to a more generalized implementation. It's another tactic you can use when following the strategy of first making things work and then making things right. Beck says triangulation is useful when the refactoring is not obvious.

The second test is

public void testEquality() {
    assertTrue(new Dollar(5).equals(new Dollar(5)));
    assertFalse(new Dollar(5).equals(new Dollar(6)));
}

He finishes by implementing a more generalized equals. He postpones implementing other properties of value objects because they are not immediately necessary, but he adds those things to his test list.

Commentary

This chapter seems to be a way for Beck to introduce triangulation. However, he makes a few casual remarks that stood out to me.

In trying to explain the value of using triangulation he asks:

What axes of variability are you trying to support in your design?

I think this is a question that has many levels. There is the level of comparing instances of Dollar. There is the level of trying to add support for multiple currencies. There is another level of the whole WyCash bond portfolio management system. But I can only say "I think" because Beck does not offer any more explanation. Maybe it's just about comparing instances of Dollar.

Another remark is:

That will let us make “amount” private, as all good instance variables should be

Why should instance variables be private? What makes that a better design? He continually drops lines like this as if the reader shares his context. It's one of the most frustrating parts of the book.

Beck 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. This makes the book difficult for people without some background in the design ideas that he uses to navigate towards an implementation.