Chubby Nickel Audio Vlog

Being a developer that almost worships object oriented design, I am often very critical of several concepts that are released into the development world under the guise that it is the absolute solution to development problems.

The Single Responsibility Principle (SRP), happens to be one of these. It makes sense on a small scale or for certain areas of a big project, but then creates more work if it is held for large scale programs. SRP can help to organize and protect objects from falling into a huge mess of garbled code, but on the other hand, strict obedience to the rule can create millions of objects that need to be maintained.

Now I will use a straw-man to argue this first point because that it is the only available example (there are hundreds examples but in principle, there is just one), used to support the idea. Say you have a class that totals out an order, but it only has one function. So all the item discounting, client discounting, taxing, shipping and printing exist in this one function. Clearly this will create a big mess of a function. So to clean it up a developer will obviously separate the logic into functions. For SRP, this is not good enough. SRP requires that each separation becomes its own class. This is an example for how SRP can help to clean things up and fix issues with updating or adding functionality.

While separating every single bit of functionality into classes is not a problem for such a simple example, when the application starts to become very complex, an issue of finding the object with the right responsibility to modify becomes a problem. In the real world, programs get very complex and if developers blindly followed this principle, no amount of documentation would help a developer to quickly find the right class to modify. In the example, a developer will likely create 5-6 different classes, no big deal. Now what if the same principle were applied to the whole program where the orders are taken, items are entered, warehouse levels are modified and monitored… etc. The developer would easily create hundreds and even thousands of classes. Now how does another developer come in and find the right class to modify? Lots of searching, stepping through and trial and error.

Should developers just give up on object oriented methodologies? Hell no. This just means that the developer must use discretion when deciding how to make a function a function or a class. Too many classes makes just as big a mess as too few classes. SRP is a good guideline… a guideline is not a rule or law. It is good to separate functionality, but most of the time a function will suffice and still maintain good object oriented design principles. Just because you are using objects, does not mean that you are using object oriented designs.

I may be taking SRP to the extreme, but in all the SRP articles I have read, they never offer up the idea that maybe several functions are better than making each function a class.  The biggest problem I face when working on code is not that the developer is not concerned with object oriented design, its that the developer loses sight of the purpose of object oriented design: to make fixing, extending and designing functionality easier and faster. If you keep that idea in your head while developing, then it should be difficult to not follow object oriented methods.