Robert C Martin - The Single Responsibility Principle

What people said

Recommends MichelHenrich · 2014-12 · Software Engineering Stack Exchange · on “In MVC should a model contain subview models?”

The key in understanding MVC lies in the separation of the responsibilities, as MVC is simply SRP [this video] applied to UI code. It separates what data has to be displayed, from how to display it, from how to handle screen events. But an important (and often missed) detail of the original definition of MVC is that it was designed for a far more granular level. For instance, you'd have ButtonModel, ButtonView and ButtonController objects, "just" to present a single button on a screen. Missing this detail is what causes so many different opinions on the subject. You can check the Java Swing architecture [LINK] to see what I mean. The point of MVC is to allow the code that serves each responsibili

Recommends MichelHenrich · 2015-03 · Software Engineering Stack Exchange · on “Is the Single Responsibility Principle applicable to functions?”

One often missed detail of the Single Responsibility Principle is that the "reasons for change" are grouped by use-case actors (you can see a full explanation here [this video] ). So, in your example, the calculatePay method will need to be changed whenever new types of Employees are required. Since one type of employee may have nothing to do with another, it would be a violation of the principle if you keep them together, since the change would affect different user-groups (or use-case actors) in the system. Now, about whether the principle applies to functions: Even if you have a violation in only one method, you are still changing a class for more than one reason, so it is still a violation of

Recommends Kevin Wittek · 2015-08 · Software Engineering Stack Exchange · on “SRP and Getters/Encapsulation”

I recently watched this presentation of Robert C. Martin about the Single Responsibility Principle: [this video] He presents an Employee class with multiple responsibilities and suggests splitting the functionality into classes like EmployeeRepository and EmployeeReporter . I can very much relate to these refactorings, but I wonder if this is only possible, if we introduce lots of getters to the Employee class. How else is it possible for the Reporter class, to generate the Report? So for me it seems this breaks OO encapsulation and leads to classes, which pull data out of objects to perform operations with this data instead of the object operating on its data itself. There are many discussions a

Recommends user7941334 · 2017-06 · Stack Overflow · on “Creating subclass instances from base class constructor”

@Kisner I missed to present you something: the car MUST have a single responsibility: to go on a road. This "**single responsibility**" is in fact a very important principle, as part of the so-called **S.O.L.I.D. principles** in OOP. Please search for **Robert C. Martin (or Uncle Bob)**, the famous founder of them. Here is one link of many more: Robert C Martin - The Single Responsibility Principle [this video] . Bye and thank you for the appreciation.

Recommends BPL · 2017-11 · Software Engineering Stack Exchange · on “Is SRP an ambiguous principle?”

From all explanations about SRP i've read I'd agree Martin's to be one of the best attempts to clarify what this principle is all about... for instance, the way he explains it here [this video] is more or less kind of useful. But can you still say we're talking about a real principle? Is there any possible way to identify clearly who the "change agents" are clearly in a non-ambiguous way? Are these ones a static set or by contrary you can't be sure? Unless the organization defines strictly beforehand who the "change agents" exactly are the principle is useless

Recommends René Link · 2019-07 · Stack Overflow · on “Code duplication and SRT according to Robert C. Martin”

either we implement this method twice (which would be code duplication) It looks like code duplication, but it's not. The fact that the implementation for calculateRegularHours that calculatePay and reportHours uses is the same, is just an accident. Since calculatePay and reportHours serve different actors, they will change for different reasons at different times. So it's likely that one of these actors will request a change that the other actor don't want. So when it comes to this request, what would you do? I guess you would separate the calculateRegularHours logic into 2 implementations. One for the calculatePay and one for reportHours . But it's also likely that you forget it and you wi

Cites MichelHenrich · 2014-12 · Software Engineering Stack Exchange · on “Saving an object via a method of its own or via another class?”

Single Responsibility Principle , Separation of Concerns and Functional Cohesion . If you read up on these concepts, the answer you get is: Separate them . A simple reason to separate the Student from the "DB" class (or StudentRepository , to follow more popular conventions) is to allow you to change your "business rules", present in the Student class, without affecting code that is responsible for persistence, and vice-versa. This kind of separation is very important, not only between business rules and persistence, but between the many concerns of your system, to allow you to make changes with minimal impact in unrelated modules (minimal because sometimes it is unavoidable). It helps to bu

Cites MichelHenrich · 2014-12 · Software Engineering Stack Exchange · on “We'd like to release only the services that have changed, in a continuous delivery context. How would we do that?”

Well, to my understanding, you already have your answer. Replace "common code" to "common business rules" and it becomes obvious. If the behaviors of both services A and B have changed, you have to redeploy both A and B. However , I think this situation smells familiar... Do you have "common code" for things that aren't really common business rules? If you do, you're in for some surprises. I may just be straying from the topic here, but I've seen this happen before. Quite often, people see two similar blocks of code and think "Hey, I've seen this before... A for-loop at a collection of Orders, filtering by isSubmitted... Yep, just like in that other component. I think I can extract that into

Cites radarbob · 2015-04 · Software Engineering Stack Exchange · on “Dealing with class optional dependencies”

You seem to be getting at the Open/Close principle [LINK] here. Frequent class modification suggests a a design issue of some kind. A coherent class would tend to not change - at best would change for one reason; i.e. it's responsibility changed. [this video]

Cites MichelHenrich · 2016-10 · Software Engineering Stack Exchange · on “Clean code: consequences of short methods with few parameters”

As someone who has read Clean Code and watched the Clean Coders series, multiple times, and often teach and coach other people in writing cleaner code, I can indeed vouch that your observations are correct - the metrics you point out are all mentioned in the book. However, the book goes on to make other points which should also be applied alongside the guidelines that you pointed out. These were seemingly ignored in the code you're dealing with. This may have happened because your colleague is still in the learning phase, in which case, as much as it is necessary to point out the smells of their code, it's good to remember that they're doing it in good will, learning and trying to write bett