I've been coming to the opinion for some time now that static methods aren't the problem.  Global variables are the problem.  You may think that your code doesn't have many globals in it, but effectively, it's littered with immutable global variables: Static Methods are immutable globals Classes are immutable globals Namespaces are immutable globals If this all sounds a bit like I'm saying "Look at all these trees!  There must be a wood nearby!" you're right.  The point I'm making is that techniques such as dependency inversion are...

...but I sure don't.  After promising that I had posted my very last article on the subject of load balancing, I spent another three months tweaking the code I'd put up in production.  The gist is now pretty close to the production code (there's a couple more Console.Writes so you can see what's going on).  So, here's what I learned: The reason QueueChannel and the nServiceBus distributor are dumb is for a very good reason: even small, rare failures in the distribution code can be horribly fatal.  This I knew intellectually, but not in my gut.  The code now...

One of the joys of blogging is that you occasionally discover people thoughtfully and politely reducing your arguments to shreds.  I recently came across an article by William Caputo on the subject of my discussion with Ryan back in November.*  I'll try to summarize the original discussion: Ryan contended that using Python fundamentally changed the principles of OOP. I argued that the SOLID principles still held. Now, in my original article, I accepted that dynamic languages helped ameliorate the sharp edges of statically typed languages.  Importantly, ...

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

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

David Wheeler (1927-2004) was something of a computer science folk hero around Cambridge.  You think object-orientation was a neat idea?  He invented the subroutine.  Academics would tell stories of having conversations in which they'd describe some particularly thorny problem they were trying to solve, only to be met with, "Oh yes, I remember that:  I never got around to writing a paper, but I’ll give you my notes on how I dealt with it.” But he's most famous for saying "Any problem in computer science can be solved with another layer of indirection.".  You'd have thought inventing functions would be...

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

Okay, this one is a bit easier to express: If you declare something as taking a type, any instance of that type should be usable there. Or, to put it another way, a Stock object is always a Stock object, it's never a cow.  The calculateValue() method should always calculate the value,  never fire a nuclear missile.  This is the Liskov Substitution principle, and is basically an injunction against creating objects that pretend to be one thing for convenience, when they're actually something else. There's a very easy way to violate Liskov without noticing: check the type of an instance.  Nearly always, if...

Probably the most C# common interview question in London is "What's the difference between an abstract class and an interface?".  Let's be clear: if you use the word contract in your answer, you're not getting a job if I'm asking the question.  Contracts are a concept that doesn't directly correspond to any code construct in C#, abstract classes and interfaces are your fundamental building blocks of well written code. Here's the one word answer:  Code.  Abstract classes can have code, interfaces can't.  C#, like Java, doesn't allow you to pull code from two sources, so you can only inherit from...

When I first try to demonstrate the power of abstraction to developers, often they get confused.  Partly this is because they're unused to thinking in these terms, but partly it's because there's so many different types.  Ultimately, it's a case of tools for the job: you pull out a hammer when you've got a nail, a screwdriver when you've got a screw.  The problem is:  they can all be combined together in useful ways.  There's no such thing as a hammer than you twist, but abstract classes and interfaces can be used together in the one solution. Parameterization Everyone...

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