1 / 44

The Single Responsibility Principle (SRP)

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.

taline
Download Presentation

The Single Responsibility Principle (SRP)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Single ResponsibilityPrinciple (SRP) A class should have only one reason to change

  2. Agenda • Motivation • The problemwithnot having a singleresponsibility • When to separate responsibilities • How to separate responsibilities • Separation • Facadepattern • AnotherExample • Conclusion

  3. 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

  4. 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

  5. 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“

  6. Motivation “There should never be more than one reason for a class to change.” Robert C. Martin, Principles of Object Oriented Design

  7. Agenda • Motivation • The problemwithnot having a singleresponsibility • When to separate responsibilities • How to separate responsibilities • Separation • Facadepattern • AnotherExample • Conclusion

  8. 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

  9. 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

  10. 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

  11. The problemwith not having a singleresponsibility Example:Rectangle

  12. The problemwith not having a singleresponsibility

  13. The problemwith not having a singleresponsibility • 2 responsibilities, used by 2 different applications • area() for geometriccalculations • draw() for rendering

  14. 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

  15. The problemwith not having a singleresponsibility • Want to changeGraphicalApplication • Have to changeRectangleclass • ComputationalGeometryApplicationmightbreak (Fragility) • Coupledresponsibilities

  16. The problemwith not having a singleresponsibility • A responsibilityisspreadacross different modules • Rigidity

  17. Agenda • Motivation • The problemwithnot having a singleresponsibility • When to separate responsibilities • How to separate responsibilities • Separation • Facadepattern • AnotherExample • Conclusion

  18. When to separate responsibilities Example:Modem

  19. When to separate responsibilities

  20. When to separate responsibilities • 2 responsibilities • Connection management • Data communication • Separate them?

  21. 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

  22. Agenda • Motivation • The problemwithnot having a singleresponsibility • When to separate responsibilities • How to separate responsibilities • Separation • Facadepattern • AnotherExample • Conclusion

  23. How to separate responsibilities: Separation Example:Rectangle

  24. How to separate responsibilities: Separation

  25. How to separate responsibilities: Separation • Separate the responsibilities • Straight forward

  26. How to separate responsibilities: Separation

  27. How to separate responsibilities: Separation Example:Modem

  28. How to separate responsibilities: Separation

  29. How to separate responsibilities

  30. How to separate responsibilities: Separation

  31. Agenda • Motivation • The problemwithnot having a singleresponsibility • When to separate responsibilities • How to separate responsibilities • Separation • Facadepattern • AnotherExample • Conclusion

  32. How to separate responsibilities: Facadepattern • Classesarenowscattered all over but thereis still somerelationbetweenthem • Facadepatternto offer a singleinterface

  33. How to separate responsibilities: Facadepattern

  34. How to separate responsibilities: Facadepattern Example:Modem

  35. How to separate responsibilities: Facadepattern

  36. How to separate responsibilities: Facadepattern

  37. Agenda • Motivation • The problemwithnot having a singleresponsibility • When to separate responsibilities • How to separate responsibilities • Separation • Facadepattern • AnotherExample • Conclusion

  38. AnotherExample Example:Online Casino

  39. AnotherExample

  40. AnotherExample: Change it? • No symptoms, no need to adjust • If it wasn‘t for BalanceManagement, the design might be ok

  41. AnotherExample: How to change it • Wrongdecisions • IncludeUserSettings in BalanceManagement • Needlesscomplexity • Unnecessarydependency • Copy + Paste checkAccess() • Needlessrepetition • The problem stems from multiple responsibilities

  42. AnotherExample

  43. 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

  44. Questions?

More Related