Growing Object-Oriented Software, Guided By Tests (chapter 13)

Remember to follow the single responsibility principle (SRP). Use this to guide refactorings on complex code.

Before introducing a new class, be sure to mock it out from the point of view of the calling object.

Is there an interface that we can extract?

Use our best judgement went describing expected values:

• Do we hardcode the expected result?
• Do we show the calculation?

For trivial examples, we can probably show the calculations, but just be wary of re-implementing the behaviour in the test code!

---

In the previous chapter, we implemented a messaging peer object, that listens out for changes within an object, and then broadcasts this to the wider system (auction status listener).

Now we have sent in a hard dependency, that the object requires to do its job (bid in auctions)

First, we mock out the implementation, then we send in a null version to get the code to compile. Finally, we implement the new dependency.

---

At this stage the author’s note that to move forward they need to refactor to avoid a circular dependency.

They note that the end to end tests are passing, however, they are not entirely happy with the way they are handling exceptions. They make a note on their to-do list to return to this later.

While refactoring, the authors seem to take the approach of creating an internal class first and then extracting this once the structure reveals itself. We are reminded again to not shy away from null implementations of objects when we have a mocked out version in the test suite. Let’s get the code compiling, and then worry about the implementation. This will allow us to keep checking in code to version control etc.

This will also allow us to defer decisions for as long as possible.

We use this theory of ‘emergent design’ to let the domain needs guide us incrementally to a clean solution. Refactor aggressively!