Development Central

Thanks for your interest in the book, Bill, and for the thoughtful critique.

I guess the main issue here is the one we agree on... to reduce concrete coupling in systems by separating the use of an object from its creation. My main goal was to encourage teams to adopt some minimal practice to make this happen generally across the architecture, without over-designing. Seems we agree there too.

I also agree with the notion of simplicity; I just don't think that adding a one-line static method to service classes and changing "new Thing()" to "Thing.getInstance()" in client classes is non-simple. Ironically, I find the universal application of dependency injection (your preference) to be the more complex approach. Reasonable people can disgree on these details, and you certainly know your own team and your own projects better than anyone, so I'll assume the forces you routinely deal with are somewhat different from mine, and this consequently leads us in slightly different directions.

Interestingly, the use of static getInstance() methods can actually enable the addition of dependency injection at a later time, because we control what methods produce, while we do not control what constructors produce. getInstance() is not, however, a Factory Method. Factory Method is a pattern, wherein a virtual method is called in a base class to produce a dependency, with the intention that derived classes will override it to produce whatever is appropriate. The introduction of mocks for testing is a great application of this pattern, and the getInstance() I use can delegate to just such a method, if DI is determined to be desireable at any future point.

That said, I think it's more important to select a practice that will succeed across the team. Your mileage may vary.

On the coupling of factories to the GUI, you're right. I think I got a little sloppy in my language... by "the GUI" I should have said "the GUI layer". I use a version of the Mediator Pattern to shield mid-tier logic from the actual GUI, for the very reason you say, to maintain testability (Mediators are easily mocked).

The last thing I comment on is your notion that "we favor composition over inheritance"; I certainly agree, and this is a cornerstone of Pattern (GoF) thinking. However, you'll notice that in the patterns what is delegated *to* in a compositional relationship is often polymorphic, often through the use of inheritance. I think the real question is "what do we use inheritance for", not whether to use it or not. I've gone on long enough here, so I'll just refer to a recorded presentation I did on this:

http://www.netobjectives.com/resources/articles/when-how-use-inheritance

-Scott Bain-