620 likes | 1.02k Views
The Single Responsibility Principle (SRP). A class should have only one reason to change. Agenda. Motivation The problem with not having a single responsibility When to separate responsibilities How to separate responsibilities Separation Facade pattern Another Example Conclusion.
E N D
The Single ResponsibilityPrinciple (SRP) A class should have only one reason to change
Agenda • Motivation • The problemwithnot having a singleresponsibility • When to separate responsibilities • How to separate responsibilities • Separation • Facadepattern • AnotherExample • Conclusion
Motivation • The Single ResponsibilityPrinciple (SRP) is.. • .. a basic principle of Object OrientatedProgramming • .. a principle created by Robert C. Martin • .. the "S" of the SOLID acronym by Robert C. Martin • .. easy to understand, but hard to master
Motivation • The Single ResponsibilityPrinciple (SRP) is.. • .. a basic principle of Object OrientatedProgramming • .. a principle created by Robert C. Martin • .. the "S" of the SOLID acronym by Robert C. Martin • .. easy to understand, but hard to master • The Single Responsibility Principle means.. • .. thateveryclass only hasoneresponsibility • .. thatthisresponsibilityisfullyencapsulated by the class
Motivation • The Single ResponsibilityPrinciple (SRP) is.. • .. a basic principle of Object OrientatedProgramming • .. a principle created by Robert C. Martin • .. the "S" of the SOLID acronym by Robert C. Martin • .. easy to understand, but hard to master • The Single Responsibility Principle means.. • .. thateveryclass only hasoneresponsibility • .. thatthisresponsibilityisfullyencapsulated by the class • A responsibilityisdefinedas „a reason to change“
Motivation “There should never be more than one reason for a class to change.” Robert C. Martin, Principles of Object Oriented Design
Agenda • Motivation • The problemwithnot having a singleresponsibility • When to separate responsibilities • How to separate responsibilities • Separation • Facadepattern • AnotherExample • Conclusion
The problemwith not having a singleresponsibility • Symptoms of badcode • Rigidity of a program: Describes how easy it is to change the program • Cascades of changes • In different modules
The problemwith not having a singleresponsibility • Symptoms of badcode • Rigidity of a program: Describes how easy it is to change the program • Cascades of changes • In different modules • Fragility of a program: Describes the probability that something breaks after making a change to a seemingly unrelated module
The problemwith not having a singleresponsibility • Symptoms of badcode • Rigidity of a program: Describes how easy it is to change the program • Cascades of changes • In different modules • Fragility of a program: Describes the probability that something breaks after making a change to a seemingly unrelated module • Needless complexity • Needless repetition
The problemwith not having a singleresponsibility Example:Rectangle
The problemwith not having a singleresponsibility • 2 responsibilities, used by 2 different applications • area() for geometriccalculations • draw() for rendering
The problemwith not having a singleresponsibility • ComputationalGeometryApplicationdepends on draw() and the GUI, eventhough it might not evenusethem • Compile time, Link time, Filesize, Shipping of code
The problemwith not having a singleresponsibility • Want to changeGraphicalApplication • Have to changeRectangleclass • ComputationalGeometryApplicationmightbreak (Fragility) • Coupledresponsibilities
The problemwith not having a singleresponsibility • A responsibilityisspreadacross different modules • Rigidity
Agenda • Motivation • The problemwithnot having a singleresponsibility • When to separate responsibilities • How to separate responsibilities • Separation • Facadepattern • AnotherExample • Conclusion
When to separate responsibilities Example:Modem
When to separate responsibilities • 2 responsibilities • Connection management • Data communication • Separate them?
When to separate responsibilities • Depends on how the classisused • Applicationsuse all functions and whenchangesappeartheyinvolvebothresponsibilities: Don‘t separate • Needlesscomplexity • Applicationsuse only parts of the class and changescaninvolve only oneresponsibility: Separate them
Agenda • Motivation • The problemwithnot having a singleresponsibility • When to separate responsibilities • How to separate responsibilities • Separation • Facadepattern • AnotherExample • Conclusion
How to separate responsibilities: Separation Example:Rectangle
How to separate responsibilities: Separation • Separate the responsibilities • Straight forward
How to separate responsibilities: Separation Example:Modem
Agenda • Motivation • The problemwithnot having a singleresponsibility • When to separate responsibilities • How to separate responsibilities • Separation • Facadepattern • AnotherExample • Conclusion
How to separate responsibilities: Facadepattern • Classesarenowscattered all over but thereis still somerelationbetweenthem • Facadepatternto offer a singleinterface
How to separate responsibilities: Facadepattern Example:Modem
Agenda • Motivation • The problemwithnot having a singleresponsibility • When to separate responsibilities • How to separate responsibilities • Separation • Facadepattern • AnotherExample • Conclusion
AnotherExample Example:Online Casino
AnotherExample: Change it? • No symptoms, no need to adjust • If it wasn‘t for BalanceManagement, the design might be ok
AnotherExample: How to change it • Wrongdecisions • IncludeUserSettings in BalanceManagement • Needlesscomplexity • Unnecessarydependency • Copy + Paste checkAccess() • Needlessrepetition • The problem stems from multiple responsibilities
Conclusion • A class should have only one reason to change • Separate responsibilities only ifneeded (Needlesscomplexity) • When an applicationuses only certainfunctions of a class (Fragility) • Whencodebreakswhichyoudidn‘t evenintend to change (Fragility) • Whenyouwant to reusecode but cannot (Needlessrepetition) • Ifneeded, useFacadepattern to make the scattering of classesbearable