Timeline for When using the Single Responsibility Principle, what constitutes a "responsibility?"
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 29, 2017 at 15:32 | comment | added | Michael L. | I heartily second @TripeHound and others who have pointed out that all these "rules" don't exist to define the One True Religion of development, but to increase the likelihood of developing maintainable software. Be very wary of following a "best practice" if you can't explain how it promotes maintainable software, improves quality or increases efficiency of development.. | |
| Mar 29, 2017 at 15:29 | comment | added | Michael L. | By "No one knows", I hope @Euphoric simply means that there is no precise definition that will work for every use case. It is something that requires a degree of judgment. I think one of the best ways to determine where your responsibilities lay is to iterate rapidly and let your codebase tell you. Look for "smells" that your code is not easily maintainable. For instance, when a change to a single business rule starts having cascading affects through seemingly unrelated classes, you probably have a violation of SRP. | |
| Mar 28, 2017 at 14:10 | comment | added | svidgen | This is very good clarification on one aspect of SRP. But, even if the SOLID principles are not hard rules, they're not terribly valuable if no one understands what they mean--even less so if your claim that "no one knows" is actually true! ... it makes sense for them to be hard to understand. As with any skill, there's something that distinguishes the good from the less good! But ... "no one knows" makes it more of a hazing ritual. (And I don't believe that's the intent of SOLID!) | |
| Mar 28, 2017 at 11:11 | comment | added | TripeHound | +42 for the last paragraph. As @RobertHarvey says, things like SPR, SOLID and YAGNI should not be taken as "absolute rules", but as general principals of "good advice". Between them (and others) the advice will sometimes be contradictory, but balancing that advice (as opposed to following a rigid set of rules) will (over time, as your experience grows) guide you to produce better software. There should be only one "absolute rule" in software development: "There are no absolute rules". | |
| Mar 27, 2017 at 22:40 | comment | added | Robert Harvey | New programmers do have a tendency to treat SOLID as if it were a set of laws, which it isn't. It's merely a grouping of good ideas to help people get better at class design. Alas, people tend to take these principles far too seriously; I recently saw a job posting that cited SOLID as one of the job requirements. | |
| Mar 27, 2017 at 20:24 | history | answered | Euphoric | CC BY-SA 3.0 |