Misunderstanding the SOLID principles
In a recent podcast, with parts transcribed here, Joel Spolsky attacks the SOLID principles. The SOLID principles give advice on how to handle dependency management in software projects. They explain how to prevent dependencies getting out of control, and how to structure code in the various layers of a project.
Joel's claim is that following the SOLID principles cause to much code, and that developers that follow the principles spend “(…) enormous amount of time writing a lot of extra code.”
I think it is generally accepted that dividing a project into modules helps the whole development process. The SOLID principles simply explain how to do this in practice. Joel should either state that he does not care about dependency management, or describe alternatives to the SOLID principles if he thinks they are not usable to keep dependencies under control. Keeping dependencies under control is hard, and you need to apply non-trivial techniques to accomplish it. If you think it is OK to let each software project be defined as a single module, it is true that the SOLID principles are a waste of time.
Joel does not fully understand the SOLID principles. He believes that following them will lead to an explosion in the number of classes required:
One of the SOLID principles, and I'm totally butchering this, but, one of the principles was that you shouldn't have two things in the same class that would be changed for a different reason [PDF]. Like, you don't want to have an Employee class, because it's got his name which might get changed if he gets married, and it has his salary, which might get changed if he gets a raise. Those have to be two separate classes, because they get changed under different circumstances. And you wind up with millions of tiny little classes, like the EmployeeSalary class, and it's just... (laughs) idiotic!
It seems clear that name and salary both are part of the same module. They are probably both part of the module that is commonly termed the “business layer”. Then, there is no need to create separate classes for these two properties. You should divide functionality after the layers/components in the problem domain, not per property, as Joel believes.
The linked article from Object Mentor specifically mentions an example where modules for geometry and graphics are mixed in the same class. The advice is to separate the graphic system into a separate module. The new graphic module will depend on the geometry module. Then, any changes in the graphic module will not affect the geometry layer. There is no claim to make the structure Joel describes.
Joel reads the article in the context of C++, without reflecting over the progress that has been made in the tools he uses himself. C# and Visual Basic both support layering code into modules without making "millions of tiny little classes". The new construct (in C#) is named "extension methods", but has been used to make modules in Smalltalk projects since the mid 1990s. Modules simply add methods to existing classes in other modules.
When the layering is not done per property and tools support layering without making new classes, following the SOLID principles is not … “idiotic”. You do not end up with a lot more code. But you get more control over how the various parts of your system interact.
