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...

You might be wondering why I tackled single responsibility last rather than, as is more conventional, first.  Partly it's because I simply found it very hard to write about, but I think it goes deeper than that: it's actually very hard to understand, partly because of the perspective issues it raises.  There's no one right answer to how to observe SRP. The official statement of the principle is “A class should have one, and only one, reason to change.”  It’s not clear to me that “one reason to change” is any better defined than “single responsibility”.  As I’ve said before, it’s...

Imagine you were writing the code modelling a car.  One you can drive, from the 1960s before they got too complex.  What does it look like? class Car { public void Accelerate(); public void Brake(); } Now, ignoring the fact that I should have started with an interface (and you can't steer), there's something very dangerous in this code.  It's the assumption that a car is an object.  It's not, it's a phenomenally complex interlinking of components.  The driver may see it as one object, but you can be assured the manufacturer does not. So what's actually...

OK, this isn't actually part of my SOLID Principles series (always a pity when your best content is a youtube link) but a response to Ryan's article on Los Techies.  I've not really got my head around the way that unit testing works in python, but the I get that absolutely everything is being overrideable on an instance or class basis affects the approach. Let's talk about Ryan's list.  Now, he argues that Python offers alternatives for the interface segregation principle, open/closed principle, and the dependency inversion principle.  I'm going to argue that the principles are actually the same,...

The interface segregation principle is regarded as the least important of the SOLID principles.  I think this is a matter of context.  If you're implementing IGame and don't need PreviousMoves functionality, you could always just throw a NotImplementedException and not worry about it.  Sure, you've violated Liskov quite badly by doing so, but not in the contexts that you actually care about.  The problems will start to develop as the code morphs and your broken abstractions start to matter.  It won't break you half as fast as not using an abstraction in the first place, but it will matter eventually....

The interesting thing about the problems we encountered with Liskov is that they lead directly to the next principle.  The basic problem we found was that there are a lot of implicit assumptions that can and often are made by the usage of an interface.  We also discussed the use of contracts to make some of those assumption explicit, and the use of unit tests to help verify those assumptions.  However,  we ignored the simplest solution of the lot: make fewer assumptions.  That's what the Interface Segregation Principle is about. Let's go back to my naive understanding of object-orientation. ...