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