Is Single Responsibility Principle a rule of OOP? [closed]

Answer 1

To quote Captain Barbossa:

"..And secondly, you must be a pirate for the pirate's code to apply and you're not. And thirdly, the code is more what you'd call "guidelines" than actual rules...."

To quote Jack Sparrow & Gibbs. "I thought you were supposed to keep to the code." Mr. Gibbs: "We figured they were more actual guidelines. "

So clearly Pirates understand this pretty well.

The "rules" could be understood via the patterns movement as "Forces"

So there is a force trying to make the class have a single responsibility. (cohesion)

But there is also a force trying to keep the coupling to other classes down.

As with all design ( not just code) the answer is that it depends.

Answer 2

As many of the other posters have said, all rules are made to be broken.
That being said, I do think that SRP is one of the more important rules for writing good code. It's not specific to Object Oriented programming, but the "encapsulation" part of OOP is very hard to do right if the class does not have a single responsibility.

After all, how do you correctly and simply encapsulate a class with multiple responsibilities? Usually the answer is multiple interfaces and in many languages that can help quite a bit, but it's still confusing to the users of your class that it may apply in completely different ways in different situations.

Answer 3

Ahh, I guess this pertains to an answer I gave. :)

As with most rules and laws, there are underlying motives by which these rules are relevant -- if the underlying motive is not present or applicable to your case, then you are free to bend/break the rules according to your own needs.

That being said, SRP is not a rule of OOP per se, but are considered best practices to create OOP applications that are both easily extensible and unit-testable.

Both are characteristics that I consider as of utmost importance in enterprise application development, where maintenance of existing applications occupies more time than new development does.

Answer 4

Very few rules, if any, in software development are without exception. Some people think there are no place for goto but they're wrong.

As far as OOP goes, there isn't a single definition of object-orientedness so depending on who you ask you'll get a different set of hard and soft principles, patterns, and practices.

The classic idea of OOP is that messages are sent to otherwise opaque objects and the objects interpret the message with knowledge of their own innards and then perform a function of some sort.

SRP is a software engineering principle that can apply to the role of a class, or a function, or a module. It contributes to the cohesion of something so that it behaves well put together without unrelated bits hanging off of it or having multiple roles that intertwine and complicate things.

Even with just one responsibilty, that can still range from a single function to a group of loosely related functions that are part of a common theme. As long as you're avoiding jury-rigging an element to take the responsibilty of something it wasn't primarily designed for or doing some other ad-hoc thing that dilute the simplicity of an object, then violate whatever principle you want.

But I find that it's easier to get SRP correct then to do something more elaborate that is just as robust.

Answer 5

SRP is just another expression of ISP :-) .

And the "P" means "principle" , not "rule" :D

Answer 6

None of these rules are laws. They are more guidelines and best practices. There are times when it doesn't make sense to follow "the rules" and you need to do what is best for your situation.

Don't be afraid to do what you think is right. You might actually come up with newer and better rules.