From Wikipedia on Single responsibility principle SoC... class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibilityclass or module should have one, and only one, responsibility . As an example, consider a module that compiles and prints a  report. Imagine such a module can be changed for two reasons. First,  the content of the report could change. Second, the format of the  report could change. These two things change for very different  causes; one substantive, and one cosmetic. The single responsibility  principle says that these two aspects of the problem are really two  separate responsibilities, and should therefore be in separate classes  or modules. It would be a bad design to couple two things that change  for different reasons at different times.The reason it is important to keep a class focused on a single concern  is that it makes the class more robust. Continuing with the foregoing  example, if there is a change to the report compilation process, there  is greater danger that the printing code will break if it is part of  the same class.Is there a rule or general guideline on how to define responsibility of methods in class?When we talk about objects inanimate objects its easy to see compile report and print report is two different responsibilities. However when it comes to animate objects like dog it becomes not so evident what methods are different in nature.Say you have:class dog {   public $breed;   public $age;   public $color;   function bark($loudness) (      ...   )    function pee($amount) (      ...   )    function run($speed, $distance, $direction) (      ...   )    function growl() (      ...   )    function drink() (      ...   ) } how can you tell what responsibility should be in a separate class?
How and to apply Single responsibility principle correctly?
object oriented;single responsibility
GeneralSingle Responsibility has something to say about semantic redundancy and false semantic cohesion of code fragments (modules, classes, methods functions). The problem is (with all SOLID principles) it's not about applying them, it's about identifying a violation them. Once you think it violates SRP you can make a thought experiment (coordinated with your business people) your code has to pass to verify your assumption.Semantic redundancyIf a functional requirement occurs and you have to change two code fragments for the same reason you violate the SRP.This often happens if a developer does not know that some logic already exists that will solve a probem for him and he develops it once again.False semantic cohesionIf a functional requirement occurs and you produce an unintentional side effect in another code fragment you violate the SRP.This happens if technically savvy developers try to reduce code duplication without consider semantics. E.g. a local part check for an email address was implemented at different locations of your code base. A developer extracts the code into one central method because it looks technically equal. Another time another developer has to change the local part check for one case and he does not check if all other usages will be correct under the new implementation.ConclusionDuplicate code may be a reason to think of SRP violation. But you have to be careful if you put code together that seems to be equal.You cannot escape from semantics. You have to identify what the code really means in the context to decide if there is a violation of SRP.You can break it down to: You have to put things together that belong together and you have to isolate thing that do not belong together. But this is an identification process.In your example you have a Dog class with several methods that represent actions of a dog. If you are paranoid you can see your first redundancies: All methods can be executed. So Execution is what they all have in common. But we have a hard time to extract this part as the programming language itself takes care of the execution. So there are lower boundaries to SRP that are related to the used programming language.Ok. Your dog barks, pees, drinks, growls and runs. I only can say, that I currently see no violation of SRP. But that doesn't mean there isn't. Once you find an indicator that may be semantically redundant or false in the context of semantic cohesion you can ignite.After all I want to say that sometimes some SRP violation can be tolerated as the code is expected to be stable in changes. But this is only about to be pragmatic and never a rule.