SRP it is a practical principle of reduction of connectivity generally, not only in compile time. Connectivity in the project should be reduced for reduction of an amount of ghost effects, increase of stability to changes in the code. Accordingly, SRP helps to solve both tasks. An example from runtime: we admit at your class is not only two groups of methods, but also any state corresponding to each of groups (if we speak about OOP, instead of about procedural programming most likely so it and is). At first, you can have explicit ghost effects when one of groups changes a state of the second group. Secondly, you can have the implicit ghost effects connected to life cycle of object. Uniting two different states in one object, you rigidly connect them with each other, from the moment of creation till the moment of clearing of storage that can be bad or even it is very bad for your architecture (memory leak, leak of personal data and passwords through long-living and, terrifying, objects, etc.) . The example which has been not connected to OOP generally: let you have a method calculateAndPrint (Model m) which calculates, and deduces result in the console. Obviously, it unites at once two roles - computing and information output in the console. If you want for choice the user to write down result instead of the console in a DB it is necessary or to write a new method, or to break old into two according to SRP. An example from Java c a pattern singleton. Why a class containing a static field with a unique copy (self-contained singleton), unconditional harm and an antipattern? Yes it is equal for the same reason: breaks SRP, combining at once two roles - the main business role and a role connected to initialization, storage and access provision to the single copy. This violation leads to difficulties with writing of tests and to the considerable lowering of flexibility of the code. It is corrected it is trivial class-factory introduction, for example, from DI-frejmvorka type Spring or Guice.