Writing S.O.L.I.D Code
3 likes1,286 views
This document discusses principles for writing solid code, including the SOLID principles and Kent Beck's four simple design rules. The SOLID principles are: single responsibility principle, open/closed principle, Liskov substitution principle, interface segregation principle, and dependency inversion principle. Applying these principles helps reduce coupling between classes and modules, increase cohesion and reuse, prevent dependency hell, and make code more maintainable and flexible over time. Kent Beck's design rules are that code should pass all tests, reveal intention, have no duplication, and have the fewest elements. Following these best practices helps write code that is understandable, extensible and resistant to rotting over time.
Writing S.O.L.I.D Code
- 2. RAJEEV N B 2 Developer at ThoughtWorks Blogs at www.rajeevnb.com @rbharshetty - Twitter @rshetty - Github
- 3. XP 3
- 4. This is me doing XP 4
- 5. IN THE BEGINNING 5 YOUR APPLICATION WAS PERFECT
- 9. DESIGN ? 9
- 10. It is all about managing your DEPENDENCIES 10
- 11. DEPENDENCIES 11 Client Dependent on Logger
- 12. DEPENDENCIES 12
- 13. DEPENDENCY MANAGEMENT • Controlling interdependencies among various software entities • As interdependencies increase, Reusability, Flexibility and Maintainability of your applications decrease • Unmanaged dependencies lead to “Dependency Hell” 13
- 15. SUCCESSFUL DESIGN • INCREASED COHESION • DECREASED COUPLING • SUPPORTS REUSE • TESTABLE • FLEXIBLE 15
- 17. SOFTWARE ROTS 17
- 18. WHY DOES SOFTWARE ROT ? • Changing requirements • Improper Design • No Continuos Design - Refactoring • Limited Project Resources • Complexity 18
- 19. ROBERT MARTIN 19 Design Principles and Design Patterns
- 20. SYMPTOMS OF ROTTING SOFTWARE • RIGIDITY • FRAGILITY • IMMOBILITY • VISCOSITY 20
- 21. RIGIDITY 21
- 22. 22
- 23. RIGIDITY • Difficult to change • Cascading of Changes in Dependent Modules • Impact of change cannot be predicted • Thus, It can’t be estimated • Time and Cost can’t be quantified 23
- 24. FRAGILITY 24
- 25. 25
- 26. FRAGILITY • Break many places when changed • Errors appear in areas unrelated to changed areas • Quality is unpredictable • Development Team Credibility Loss • Sometimes breakage increases with time 26
- 27. IMMOBILITY 27
- 28. 28
- 29. IMMOBILITY • Inability to reuse Software Components • Lack of reusable modules • Desirable parts of the system dependent on undesirable parts • Work and risk of extracting greater than cost of writing it from scratch 29
- 30. VISCOSITY 30
- 31. 31
- 32. VISCOSITY • VISCOSITY OF DESIGN • VISCOSITY OF ENVIRONMENT 32
- 33. VISCOSITY OF DESIGN • Design Preserving methods are harder than Hacks • Easy to do Wrong thing but harder to do right thing • As time progresses, it will become increasingly difficult to continue developing the application 33
- 34. VISCOSITY OF ENVIRONMENT • Development Environment is slow and inefficient • Slower feedback Ex: Longer compile times, Slower builds, Long running tests 34
- 35. PREVENTING SOFTWARE ROT • Refactoring (Continuos Improvement of Design) • Testing (Unit/Integration/Contract tests) • Code Reviews • Documentation • Design Principles • Simplicity 35
- 37. S.O.L.I.D 37 Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
- 39. 39
- 40. 40 A software entity should have one and only one reason to change
- 41. BEFORE 41
- 42. AFTER 42
- 43. Why is it important to separate these two responsibilities into separate classes ? • Each responsibility is an axis of change • Changes in one responsibility may affect another • Coupling among classes leads to Fragile Design 43
- 44. SIGNS ? 44 • Description of class ( and/or ) • Rigidity and Fragility in code
- 45. BENEFITS ? 45 • Reduced Coupling • Separation of Concerns • Better readability • Your code evolves cleanly (Maintainable)
- 46. OPEN/CLOSED 46
- 47. 47
- 48. 48 Software entities should be closed for modification but open for extension
- 49. OCP 49 Add functionality by adding new code, not by modifying old code
- 50. ABSTRACTION IS THE KEY 50 • Client/Server relationship is open • Changes in Server cause changes in the client
- 51. ABSTRACTION IS THE KEY 51 • Client/Server relationship is closed • Abstract Servers close clients to changes in implementation
- 52. BEFORE 52
- 53. AFTER 53
- 54. SIGNS ? 54 ● Switch cases littered all over your application ● Hunt and replace policy
- 55. BENEFITS ? 55 • Reusability • Maintainability • Flexible design
- 56. DESIGN BY CONTRACT 56 • Methods of class define pre-conditions and post-conditions • The preconditions must be met for method to execute • Upon completion, method guarantees that the post conditions are met
- 59. 59 Sub-types must be substitutable for their base- types
- 60. When is something Substitutable ? 60
- 61. Requires No Less Promises No More 61
- 63. ELLIPSE/CIRCLE 63 ● Violation of LSP ● Circle violates the post conditions ● Circle not substitutable for Ellipse
- 64. BEFORE 64
- 65. AFTER 65
- 66. SIGNS ? 66 • Explicit Checking type of a class in the code • Derived types not substitutable for the base types
- 67. BENEFITS ? 67 • Ability to re-use code increases • Flexible code
- 69. 69
- 70. 70 Clients should not be forced to depend on methods it does not use
- 71. BEFORE 71
- 72. AFTER 72
- 73. SIGNS ? 73 ● Client requiring things it does not need ● Methods littered with “NotImplemented” exceptions
- 74. BENEFITS ? 74 • Lot of small, focused interfaces • Flexible design
- 76. 76
- 77. 77 Depend upon Abstractions not upon Concretions
- 78. DIP 78 • High Level Modules should not depend on low level modules, Both should depend on Abstractions • Abstractions should not depend on details. Details should depend on abstractions.
- 79. BEFORE 79
- 80. AFTER 80
- 81. BEFORE 81
- 82. AFTER 82
- 83. SIGNS ? 83 ● High level modules are harder to reuse ● Changes in the lower level modules directly affect the higher level modules
- 84. ADVANTAGES ? 84 • Reusable modules • Easier to extend • Low Coupled code
- 85. KENT BECK 85 4 Simple Design Rules
- 86. PASSES TESTS 86
- 87. 87
- 88. PASSES TESTS 88 ● Unit tests with Red, Green, Refactor cycles ● Tests help communicate Design
- 90. 90
- 91. REVEALS INTENTION 91 ● Self Documenting code ● Meaningful names to software entities ● Clear code
- 93. 93
- 94. NO DUPLICATION 94 ● Once and only once ● DRY
- 96. 96
- 97. FEWEST ELEMENTS 97 ● No Superfluous parts/elements ● YAGNI ● KISS ● Minimum number of classes/methods
- 98. 98
- 99. WRAPPING UP 99 ● SRP - One responsibility per class ● OCP - Extend not modify ● LSP - Derived substitutable for base ● ISP - Split into Focussed interfaces ● DIP - Depend on Abstractions
- 100. REFERENCES 100 ● Design Principles and Patterns (http:// www.objectmentor.com/resources/articles/ Principles_and_Patterns.pdf) ● Design By Contract - Eiffel (https://www.eiffel.com/values/ design-by-contract/) ● Code from the talk - Java: https://github.com/rShetty/ S.O.L.I.D-Java ● Code from the talk - Ruby: https://github.com/rshetty/ S.O.L.I.D
- 101. THANK YOU