Book Review: Agile Principles, Patterns, and Practices in C#

This is a sequel to Bob Martin’s popular book Agile Software Development, Principles, Patterns, and Practices, now considerably updated for C#.

The book starts out really great: an overview of agile practices, XP (Extreme programming), refactoring, etc. Next, it goes over some very important concepts, such as

• the Single Responsibility Principle: A class should have only one reason to change.
• the Open/Closed Principle: Software entities (classes, modules, functions, etc) should be open for extension but closed for modification.
• the Liskov Substitution Principle: Subtypes must be substitutable for their base types.
• the Dependency Inversion Principle: High-level modules should not depend on low-level modules. Both should depend on abstractions and Abstractions should not depend upon details. Details should depend upon abstractions.
• the Interface Segregation Principle: Clients should not be forced to depend on methods they do not use.

Next, a helpful overview of UML diagrams presented in very basic terms. I like the Martins’ take on this subject:

UML is not particularly good for communicating algorithmic details. […]

We make use of UML when we have something definitive we need to test and when using UML to test is cheaper than using code to test it. […]

Get into the habit of throwing UML diagrams away. Better yet, get into the habit of not creating them on a persistent medium. […] Save the ones that express a common design solution in your system. Save the diagrams that record complex protocols that are difficult to see in the code.

So far so good. Really good.

But then the engine stalls. The subsequent exploration of patterns is quite odd. If you are new to patterns, I suggest you stay away from these chapters because you will either get confused or will misinterpret them. The samples in those chapters often come with a weird twist. If you want the hands-down best coverage of patterns, get your own personal copy of the seminal Design Patterns or even Head First Design Patterns.

The rest of the book is one giant analysis and implementation of a payroll case study with lots and lots of code listing pages. It’s fun to follow the thought train for a while, but at some point your head starts to hurt from long code listings.

There’s also a chapter on API design, packaging and distribution of assemblies. This is by far the weakest spot of the book, and I suggest you don’t even venture there. Your best bet is Framework Design Guidelines, if you insist.

The last chapter introduces the Martins’ take of the Model View Presenter (MVP) pattern, but the way it’s presented scares me because it resembles the masochistic Supervising Controller variation of MVP. Somehow their Controller ended up with too many presentational responsibilities, so the View pulls its sleeve all the time, saying, I’ve updated something! Sync up with me. By the way, you can download this chapter in PDF for free from BookPool.

Conclusion

Good, interesting book. I think the Martins should’ve stopped about halfway and chose not to reinterpret patterns, give odd advice on component design and packaging, etc. Both are recognized experts—no question there, but certain things (ok, lots of things), just came across in an odd way. Big thanks for coverage of the agile philosophy, though.

Finally, the overall ugly design of the book adds insult to injury. Whoever did the drawings, please don’t do it again. They are atrocious. And whoever decided on Times New Roman (or its twin brother) for the copy, you’re hurting our eyes. One more request: stop using Word as a publishing tool. It’s the same as using FrontPage for web design.