I have to admit, when I read Uncle Bob’s post about dependency injection, I really didn’t expect the response it would get since it struck me as being relatively uncontroversial.  So Davy’s reaction rather surprised me.  Davy had two major objections to the original article: The contention that IoC containers aren’t always appropriate. The advocating of the use of abstract factories. Now, when I teach constructor injection to developers around my company, I always teach it in the manner Uncle Bob describes: just pass things into the constructor.  Sooner...

If you're writing SOLID code, you're going to be doing a lot of wiring.  Typically, this wiring only changes in response to business change.  Some wiring is going to be static for years.  If you're building a car, you won't suddenly wire the clutch to the CD player, as entertaining as it would be when your brother-in-law tried to drive it. On the other end of this spectrum, there's stuff that changes all the time.  Every machine you use, it needs to change.  This is actual configuration information.  The rest of it can, frankly, be hard wired.  True configuration...

When we looked at the Open / Closed principle, we saw that certain practices produced fragile code. Static Methods Non-virtual methods Creating objects Too-specific variable declarations Hard-coded values Using the wrong object (the Law of Demeter) Of these, the first three are all things you can't override.  If you can't override things, they're inflexible and, inevitably, will cause problems.  In the cases we've seen, the Law of Demeter problem could be solved just by using the right object in the first place.  Equally, a non-virtual method is easy to fix, you just make it...

Another thing that we covered at my recent presentation was common use cases of Singletons.  The problem with artificial examples is that you're often presented with objections that the point you're making is restricted to the particular example you've given.  So, instead, let's take a look at some of the most common usages of singleton patterns and explain why you're breaking your code to use them: The Current User I've lost count of the number of times I've seen the current logged-in user accessed through a static method.  It's extremely tempting: there's a phenomenal number of parts of your system...

I recently had a rather incoherent rant about why Singleton is an anti-pattern.  Let's say that you decided that static methods needed to be eliminated from your code base.  So you embark on the refactoring to end all refactorings.  That's exactly the situation I'm in at the moment.  The irony is that the static methods I'm trying to eliminate are calls to StructureMap's ObjectFactory.GetInstance.  Yes, riddled through the code are calls to services.  Nothing is denied to any object.  If you start trying to replace static methods with proper instances, you're going to be asking yourself a lot: Why...

These is basically patterns where you're better off avoiding them.  Seriously, just skip those parts of the book: Singleton All patterns are a trade-off.  The trade-off with singleton is reducing the number of parameters certain functions take and trading them for more static methods.  From the perspective of code agility, a every method on singleton might as well be a static method.  Not only that, but everything the singleton touches might as well be a static method.  The testing implications of the Singleton pattern are horrendous.  Steve Yegge has written far more than I intend to on the subject, so I'm...

I was recently reading a fairly detailed comparison by Andrey Shchekin of the various injection containers out there in the .NET space.  I found it interesting that the last feature he regarded as important was the ability to tell the container to mock a particular object.  Now, when I wrote an article about evaluating IoC containers, it didn't even occur to me to include this.  Now, Andrey includes many points that I haven't covered, like the fact that Castle hasn't had a stable release in well over a year, but on this point I think it's best left out....

Mauricio Scheffer asked how AutoGen differs from the TypedFactory Facility already in Castle.  (An equally valid question is why the code is five times the size.)  The answer is that it doesn't in essence, but it does in detail.  However, the details matter, in that AutoGen addresses common use cases, whereas the TypedFactoryFacility is only going to save you 6 lines of code.  The principal differences are: Configuration Constructor Arguments Handling Keys Disposal Handling Multiple Methods How TypedFactoryFacility is used Let's take...

I recently published a tool called AutoGen for Castle.  You can check it out at Google Code.  In essence, it auto-generates factory objects for you and adds them to your container.  This is an extremely useful thing to be able to do.  I do, however, find it a bit hard to explain, so bear with me. A relatively good rule of thumb these days is that a class should instantiate objects or do something with objects but never both.  Miško Hevery has written a lot of good stuff on this subject, and I don't propose to mangle his thinking here. ...

I thought I'd write a bit about how I understand the philosophy of IoC containers.  I realize I'm actually building up to something that I started talking about a while ago.  I'm probably not saying anything that Martin Fowler didn't say before, but I have my own slant on it.  To start off with, I'd like to just review what we actually mean by various terms: Inversion of Control (IoC) is a general name for the pattern where an object isn't responsible for managing the lifecycle of the services it uses.  The simplest way to implement this (in .NET)...

If, like me, you're using Binsor for configuration, and using the include file mechanism to implement environmental deltas, you're going to need to refer to the initial file using an absolute path.  The reason for this is, if you don't, a relative path name within the Binsor script uses the current working directory.  Just to be annoying, this means that all of your code works until the moment you deploy it, and then your service fails to start (this bears no resemblance to a real issue, I can assure you...) Anyway, here's the code you need: private static...

I can't be the only one glad that the Google Testing Blog has become active again (and I don't mean "we're having a conference on another continent" style posts, much as I eagerly await those missives.  But this post has actually crystallized my understanding of one aspect of designing for testability.  There are probably some who will regard this one as old news.  It is, however, pretty fundamental.  To summarize, it says that any given class should either create objects or use them.  So, let's assume most of your objects are constructed using auto-wiring of dependencies.  We can ignore cases...