The very first paragraph reads:

Dependency Injection (DI) is one of the most misunderstood concepts of object-oriented programming. The confusion is abundant and spans terminology, purpose, and mechanics. Should it be called Dependency Injection, Dependency Inversion, Inversion of Control, or even Third-Party Connection? Is the purpose of DI only to support unit testing, or is there a broader purpose? Is DI the same as SERVICE LOCATION? Do we need DI CONTAINERS to apply DI?

They must have read my mind.

This is a pretty large book (over 500 pages). Most likely programmers will not need to read the entire book (as the authors themselves indicate). The bulk of the last half contains Patterns and Anti-Patterns, which can be browsed and read individually. The first chapter obviously introduces DI to those unfamiliar with it. I almost skipped it, but found it was worth the read, as they highlighted some common misconceptions that, in their terms: "you need to unlearn". These were helpful.

I appreciated this statement on p. 29:

OBJECT COMPOSITION is often the primary motivation for introducing DI into an application. In fact, initially, DI was synonymous with OBJECT COMPOSITION...

Object-oriented development obviously orients around objects, many of them. A major focus is therefore centered on they are composed together. A great number of design patterns target object composition. DI assists in the indevour, in a manner that focusing on loose-coupling.

Code smells and Anti-patterns

I appreciate that the authors spent time putting together code smells and anti-patterns, and provided in-depth detail. One in particular is Service Locator. The authors used this at one time, then later concluded it should be avoided. However after reading specific reasons why to avoid it, I've personally concluded that there are a few cases where I would prefer it. I'm personally not big on blanket "don't use method X" without an explanation. It may be less than ideal for 90% of uses, but there may be good reason for those 10% uses.

Good OO book

Overall, this is not only a great DI book, it's a good book for learning good object-oriented coding practices. Well worth the purchase.