Rating : 3 out of 5 stars.
Things I liked:
1. The discussion of how messages form the basis for a good design and she classified what type of tests should be written in each case.2. How TDD does not magically create design and how to apply good design principles as you code.
3. Writing contract tests to avoid problems due to mock abuse.
4. Guidelines for public interface.
Things I did not like:
1. Lot of fluff during the discussions. It is better to move them to her blog and make the book concise.2. The cure is worse than the disease. Using template methods to avoid calling super.
3. Using toy examples in Bicyle domain is annoying.
4. She talks about coupling without covering the basics of coupling.
Content Review
Her Suggestion:Hide the variables, even from the class that defines them, by wrapping them in methods.
My Thoughts:
#1 : If the class is small and has single purpose, this is not required. You can avoid the downside of exposing data and avoid the risk of name changes.
#2 : Her example of RevealingReferences class is an example for Data Coupling. The example of isolating knowledge of the data structure is an example of Localized Change.
Understanding Dependencies
#3. Coupling to a concrete class name. Coupling to a message name. Knowing the parameters and it's order is an example of Parameter Coupling.
#4. She probably forgot to mention in the section on Writing Loosely Coupled Code, 'If a class has too many arguments then it is likely that it violates Single Purpose Principle.
#5. Minimizing context is about providing a service.
#6. The diagram 4.7 is about raising the level of abstraction. There can be many ways to prepare for a trip. This flexibility allows reuse in different contexts.
#7. Things that change at different rates change for different reasons.
Some nuggets I liked in the book:
Nugget #1 : If you think of a class as having a single purpose, then the things it does are what it allows it to fulfill that purpose.
Nugget #2 : Public methods should read like a description of responsibilities. The public interface is a contract that articulates the responsibilities of your class.
Nugget #3 : Seeking Context Independence. The best possible situation is for an object to be completely independent of its context. An object that could collaborate with others without knowing who they are or what they do.
