Design – Am I making the classes too granular? How should Single Responsibility Principle be applied

clean codedesignsingle-responsibility

I write lots of code that involves three basic steps.

Get data from somewhere.
Transform that data.
Put that data somewhere.

I typically end up using three types of classes – inspired by their respective design patterns.

Factories – to build an object from some resource.
Mediators – to use the factory, perform the transformation, then use the commander.
Commanders – to put that data somewhere else.

My classes tend to me be quite small, often a single (public) method, e.g. get data, transform data, do work, save data. This leads to a proliferation of classes, but in general works well.

Where I struggle is when I come to testing, I end up will tightly coupled tests. For example;

Factory – reads files from disk.
Commander – writes files to disk.

I can't test one without the other. I could write additional 'test' code to do disk read/write also, but then I'm repeating myself.

Looking at .Net, the File class takes a different approach, it combines the responsibilities (of my) factory and commander together. It has functions for Create, Delete, Exists, and Read all in one place.

Should I look to to follow the example of .Net and combine – particularly when dealing with external resources – my classes together? The code it still coupled, but it's more intentional – it happens at the original implementation, rather than in the tests.

Is my issue here that I have applied Single Responsibility Principle somewhat overzealously? I have separate classes responsible for read and write. When I could have a combined class which is responsible for dealing with a particular resource, e.g. system disk.

Best Answer

Following the Single Responsibility principle may have been what guided you here but where you are has a different name.

Command Query Responsibility Segregation

Go study that and I think you'll find it following a familiar pattern and that you're not alone in wondering how far to take this. The acid test is if following this is getting you real benefits or if it's just a blind mantra you follow so you don't have to think.

You've expressed concern about testing. I don't think following CQRS precludes writing testable code. You might simply be following CQRS in a way that makes your code not be testable.

It helps to know how to use polymorphism to invert source code dependencies without needing to change the flow of control. I'm not really sure where your skill set is on writing tests.

A word of caution, following the habits you find in libraries is not optimal. Libraries have their own needs and are frankly old. So even the best example is only the best example from back then.

This isn't to say there aren't perfectly valid examples that don't follow CQRS. Following it will always be a bit of a pain. It's not always one worth paying. But if you need it you'll be glad you used it.

If you do use it heed this word of warning:

In particular CQRS should only be used on specific portions of a system (a BoundedContext in DDD lingo) and not the system as a whole. In this way of thinking, each Bounded Context needs its own decisions on how it should be modeled.

Martin Flowler: CQRS

Related Solutions

Design – Single Responsibility Principle Implementation

I've always considered the single responsbility principle more of a philosophy than principle.

Robert C. Martin (Uncle Bob) restates the Single Responsibility Principle (linked to PDF):

There should never be more than one reason for a class to change

Quoted from the reply you got your post.

When we try to appease the SPR, we focus on the implementation rather than on the purpose.

Major mistake.

My understanding of the SRP is this, when an addition blurs the responsibility of an implementation, the focal point should be reconsidered.

For me, it is all about the relationships between purposes.

Sure, a user has to be authenticated and authorized regarding actions to take - but the authentication and authorization should be separated from the user.

It's not like you are going to try to authorize/authenticate a non-user anyway?

And thus, you should consider splitting implementation when the responsibilities of a class outgrows it purpose. After all, design patterns have purposes too.

Take a look at GRASP when you get a chance.

Single Responsibility Principle – Applying to New Code

Of course, the YAGNI principle will tell you to apply SRP not before you really need it. But the question you should ask yourself is: do I need to apply SRP first and only when I have to actually change my code?

To my experience, the application of SRP gives you a benefit much earlier: when you have to find out where and how to apply a specific change in your code. For this task, you have to read and understand your existing functions and classes. This gets very much easier when all your functions and classes have a specific responsibility. So IMHO you should apply SRP whenever it makes your code easier to read, whenever it makes your functions smaller and more self-describing. So the answer is yes, it makes sense to apply SRP even for new code.

For example, when your printing code reads a document, formats the document and prints the result to a specific device, these are 3 clear separable responsibilities. So make at least 3 functions out of them, give them according names. For example:

 void RunPrintWorkflow()
 {
     var document = ReadDocument();
     var formattedDocument = FormatDocument(document);
     PrintDocumentToScreen(formattedDocument);
 }

Now, when you get a new requirement to change document formatting or another one to print to PDF, you know exactly at which of these functions or locations in code you have to apply changes, and even more important, where not.

So, whenever you come to a function you don't understand because the function does "too much", and you are not sure if and where to apply a change, then consider to refactor the function into separate, smaller functions. Don't wait until you have to change something. Code is 10x more often read than changed, and smaller functions are much easier to read. To my experience, when a function has a certain complexity, you can always split the the function into different responsibilities, independent of knowing which changes will come in the future. Bob Martin typically goes a step further, see the link I gave in my comments below.

EDIT: to your comment: The main responsibility of the outer function in the example above is not to print to a specific device, or to format the document - it is to integrate the printing workflow. Thus, at the abstraction level of the outer function, a new requirement like "docs should not be formatted anymore" or "doc should be mailed instead of printed" is just "the same reason" - namely "printing workflow has changed". If we talk about things like that, it is important to stick to the right level of abstraction.

Best Answer

Related Solutions

Design – Single Responsibility Principle Implementation

Single Responsibility Principle – Applying to New Code

Related Topic