152

SRP is perhaps the most misunderstood software principle. A software application is built from modules, which are built from modules, which are built from... At the bottom, a single function such as CheckInput will only contain a tiny bit of logic, but as you go upward, each successive module encapsulates more and more logic and this is normal. SRP is not ...


116

One way to wrap your head around this is to imagine potential requirements changes in future projects and ask yourself what you will need to do to make them happen. For example: New business requirement: Users located in California get a special discount. Example of "good" change: I need to modify code in a class that computes discounts. Example ...


104

Now, to build a simple file saving application you have a class to check if the file already exists, a class to write the metadata, a class to abstract away DateTime.Now so you can inject times for unit testing, interfaces for every file containing logic, files to contain unit tests for each class out there, and one or more files to add everything to your DI ...


87

If your class has 20 parameters in the constructor, it doesn't sound like your team quite knows what SRP is. If you have a class that does only one thing, how does it have 20 dependencies? That's like going on a fishing trip and bringing along a fishing pole, tackle box, quilting supplies, bowling ball, nunchucks, flame thrower, etc.... If you need all that ...


76

Practically speaking, responsibilities are bounded by those things that are likely to change. Thus, there's no scientific or formulaic way to arrive at what constitutes a responsibility, unfortunately. It's a judgement call. It's about what, in your experience, is likely to change. We tend to apply the language of the principle in a hyperbolic, literal, ...


68

Single Responsibility should be understood as an abstraction of logical tasks in your system. A class should have the single responsibility to (do everything necessary in order to) perform one single, specific task. This can actually bring a lot into a well-designed class, depending on what the responsibility is. The class that runs your script engine, ...


67

The concept of the SRP is to stop modules doing 2 different things when doing them individually makes for better maintenance and less spaghetti in time. As the SRP says "one reason to change". In your case, if you had a routine that "updates and returns the updated object", you are still changing the object once - giving it 1 reason to change. That you ...


62

I would say you're taking SRP far too seriously. If your code is tidy enough that logging is the only "violation" of SRP then you are doing better than 99% of all other programmers, and you should pat yourself on the back. The point of SRP is to avoid horrific spaghetti code where code that does different things is all mixed up together. Mixing logging with ...


57

Modularity. Any decent language will give you the means to glue together pieces of code, but there's no general way to unglue a large piece of code without the programmer performing surgery on the source. By jamming a lot of tasks into one code construct, you rob yourself and others of the opportunity to combine its pieces in other ways, and introduce ...


53

The case for any change of practice is made by identifying the pain points created by the existing design. Specifically, you need to identify what is harder than it should be because of the existing design, what is fragile, what is breaking now, what behaviors can't be implemented in a simple manner as a direct (or even somewhat indirect) result of the ...


52

The key here is scope, or, if you prefer, granularity. A part of functionality represented by a class can be further separated into parts of functionality, each part being a method. Here's an example. Imagine you need to create a CSV from a sequence. If you want to be compliant with RFC 4180, it would take quite some time to implement the algorithm and ...


50

Many potential performance concerns are not really a problem in practice. The issue you raise may be one of them. In the vernacular, we call worrying about those problems without proof that they are actual problems premature optimization. If you are writing a front-end for a web service, your performance is not going to be significantly affected by ...


46

As always, this is a question of degree. The SRP should stop you from writing a method that retrieves a record from an external database, performs a fast Fourier transform on it and updates a global statistics registry with the result. I think almost everyone would agree these things should be done by different methods. Postulating a single responsibility ...


43

Quoting Uncle Bob about the SRP (https://8thlight.com/blog/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html): The Single Responsibility Principle (SRP) states that each software module should have one and only one reason to change. ... This principle is about people. ... When you write a software module, you want to make sure that when changes are ...


41

Single Responsibility Principle is only concerned with whether or not a piece of code (in OOP, typically we're talking about classes) has responsibility over one piece of functionality. I think your friend saying that functions and data can't co-mingle didn't really understand that idea. If Employee were to also contain information about his workplace, how ...


37

No, this change is not informed by the SRP. Ask yourself why there is no check in your checker for "the object passed in is a stream". The answer is obvious: the language prevents the caller from compiling a program that passes in a non-stream. The type system of C# is insufficient to meet your needs; your checks are implementing enforcement of invariants ...


36

What you're encountering is the cognitive dissonance that comes from listening to people who favor slavish adherence to guidelines under the guise of "best practices" over reasoned decision making. You've clearly done your homework: The function's purpose is understood. The workings of its implementation is understood (i.e., readable). There are full-...


33

I think it's in Martin Fowler's Refactoring that I once read a counter-rule to SRP, defining where it's going too far. There is a second question, as important as "does every class have only one reason to change?" and that is "does every change only affect one class?" If the answer to the first question is, in every case, "yes" but the second question is "...


32

YAGNI means to avoid investing effort into code changes for hypothetical requirements which may arrive later, and instead focus on the requirements one has now. But this is not restricted to functional requirements - as long as one does not create "use-once-and-then-throw away" software, there is always the non-functional requirement of keeping code readable,...


31

[Note: I'm going to be talking about objects here. Objects is what object-oriented programming is about, after all, not classes.] What the responsibility of an object is depends mostly on your domain model. There are usually many ways to model the same domain, and you will choose one way or the other based on how the system is going to be used. As we all ...


31

The single responsibility might not be something that a single function can fulfill. class Location { public int getX() { return x; } public int getY() { return y; } } This class may break the single responsibility principle. Not because it has two functions, but if the code for getX() and getY() have to satisfy ...


31

A function is a function. A responsibility is a responsibility. A mechanic has the responsibility to fix cars, which will involve diagnostics, some simple maintenance tasks, some actual repair work, some delegation of tasks to others, etc. A container class (list, array, dictionary, map, etc) has the responsibility to store objects, which involves ...


30

Better maintenance, easy testing, faster bug-fixing are just (very pleasant) outcomes of applying SRP. The main reason (as Robert C. Matin puts it) is: A class should have one, and only one, reason to change. In other words, SRP raises change locality. SRP also promotes DRY code. As long as we have classes that have only one responsibility, we may ...


30

Tasks that used to take 5-10 files can now take 70-100! This is the opposite of the single-responsibility principle (SRP). To get to that point, you must have divided up your functionality in a very fine-grained way, but that's not what the SRP is about -- doing that ignores the key idea of cohesiveness. According to the SRP, software should be divided ...


29

I follow "classes should have only one reason to change". For me, this means thinking of harebrained schemes that my product owner might come up with ("We need to support mobile!", "We need to go to the cloud!", "We need to support Chinese!"). Good designs will limit the impact of these schemes to smaller areas, and make them relatively easy to accomplish. ...


29

Sending a notification that the persistent data store changed seems like a sensible thing to do when saving. Of course you shouldn't treat Add as a special case - you'd have to fire events for Modify and Delete as well. It's the special treatment of the "Add" case that smells, forces the reader to explain why it smells, and ultimately leads some readers of ...


27

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


27

No one knows. Or at least, we are unable to agree on one definition. That is what makes SPR (and other SOLID principles) quite controversial. I would argue being able to figure out what is or isn't a responsibility is one of the skills software developer has to learn over course of his career. The more code you write and review, the more experience you will ...


26

Given some divergences between languages, this can be a tricky topic. Thus, I'm formulating the following commentaries in a way that tries to be as comprehensive as I can inside the realm of OO. First of all, the so called "Single Responsibility Principle" is a reflex -- explicitly declared -- of the concept cohesion. Reading the literature of the time (...


26

Not all responsibilities are created equal. Here are two drawers. They both have one responsibility. They each have names that let you know what belongs in them. One is the silverware drawer. The other is the junk drawer. So what's the difference? The silverware drawer makes clear what doesn't belong in it. The junk drawer however accepts anything that ...


Only top voted, non community-wiki answers of a minimum length are eligible