In the section on TDD Feathers mentions the copy/paste/refactor pattern which I wrote about a few days ago. Cam pointed out that this technique allows us to get to the green bar more quickly after which we can decide how to clean up the code. It seems like perhaps this could be added to Kent Beck’s 'Green Bar Patterns' that he describes in 'Test Driven Development by Example'. I’ve noticed a few times recently that delaying our desire to remove duplication until we can properly see where the duplication lies might be a better strategy than prematurely removing duplication and creating a meaningless abstraction which can be difficult to remove.

From the examples in the book, programming by difference is used to describe an approach where we create a sub class and override some aspect of the super class. It allows us to quickly add new features although it does increase the complexity of the system since we have to add a new class to achieve this. The next step after this is to refactor the code into a state where the new class' behaviour is moved elsewhere or the new class is shaped into something that makes more sense. Feathers also points out that while programming by difference may initially lead to our code being in worse shape it can also allow us to see new abstractions which we can then work towards.

I like the term 'normalised hierarchy' with respect to the way that we create inheritance hierarchies. Feathers suggests that we should look to create a hierarchy where no class has more than one implementation of a method. i.e. if a class has a concrete implementation of a method then that shouldn’t be overriden.

Towards the end of the chapter Feathers asks whether it is overkill to create a particular class which is just acting like a properties collection at the time. We discussed this and Cam pointed out that we seem to either end up with 'complex interactions and simple objects' or 'more complicated objects and simple interactions'. From my observations it seems that we err on the side of not creating enough objects but as Naresh Jain points out it is possible to go too far the other way and end up creating objects just for the sake of it.