Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
WRITING S.O.L.I.D CODE
RAJEEV N B
RAJEEV N B
2
Developer at ThoughtWorks
Blogs at www.rajeevnb.com
@rbharshetty - Twitter
@rshetty - Github
XP
3
This is me doing XP
4
IN THE BEGINNING
5
YOUR APPLICATION WAS PERFECT
THEN SOMETHING HAPPENED
6
YOUR APPLICATION
CHANGED
7
DESIGN TO THE
RESCUE
8
DESIGN ?
9
It is all about
managing your
DEPENDENCIES
10
DEPENDENCIES
11
Client Dependent on Logger
DEPENDENCIES
12
DEPENDENCY MANAGEMENT
• Controlling interdependencies among various software
entities
• As interdependencies increase, Reu...
DEPENDENCY HELL
14
SUCCESSFUL DESIGN
• INCREASED COHESION
• DECREASED COUPLING
• SUPPORTS REUSE
• TESTABLE
• FLEXIBLE
15
DESIGN STAMINA
16
SOFTWARE ROTS
17
WHY DOES SOFTWARE ROT ?
• Changing requirements
• Improper Design
• No Continuos Design - Refactoring
• Limited Project Re...
ROBERT MARTIN
19
Design Principles and Design Patterns
SYMPTOMS OF ROTTING SOFTWARE
• RIGIDITY
• FRAGILITY
• IMMOBILITY
• VISCOSITY
20
RIGIDITY
21
22
RIGIDITY
• Difficult to change
• Cascading of Changes in Dependent Modules
• Impact of change cannot be predicted
• Thus, It...
FRAGILITY
24
25
FRAGILITY
• Break many places when changed
• Errors appear in areas unrelated to changed areas
• Quality is unpredictable
...
IMMOBILITY
27
28
IMMOBILITY
• Inability to reuse Software Components
• Lack of reusable modules
• Desirable parts of the system dependent o...
VISCOSITY
30
31
VISCOSITY
• VISCOSITY OF DESIGN
• VISCOSITY OF ENVIRONMENT
32
VISCOSITY OF DESIGN
• Design Preserving methods are harder than Hacks
• Easy to do Wrong thing but harder to do right thin...
VISCOSITY OF ENVIRONMENT
• Development Environment is slow and inefficient
• Slower feedback
Ex: Longer compile times, Slowe...
PREVENTING SOFTWARE ROT
• Refactoring (Continuos Improvement of Design)
• Testing (Unit/Integration/Contract tests)
• Code...
OO DESIGN
PRINCIPLES
36
S.O.L.I.D
37
Single Responsibility Principle
Open/Closed Principle
Liskov Substitution Principle
Interface Segregation Pri...
SINGLE
RESPONSIBILITY
38
39
40
A software entity should
have one and only one
reason to change
BEFORE
41
AFTER
42
Why is it important to separate these two
responsibilities into separate classes ?
• Each responsibility is an axis of cha...
SIGNS ?
44
• Description of class ( and/or )
• Rigidity and Fragility in code
BENEFITS ?
45
• Reduced Coupling
• Separation of Concerns
• Better readability
• Your code evolves cleanly (Maintainable)
OPEN/CLOSED
46
47
48
Software entities should be
closed for modification but
open for extension
OCP
49
Add functionality by adding new code, not
by modifying old code
ABSTRACTION IS THE KEY
50
• Client/Server relationship is open
• Changes in Server cause changes in the
client
ABSTRACTION IS THE KEY
51
• Client/Server relationship is closed
• Abstract Servers close clients to changes in
implementa...
BEFORE
52
AFTER
53
SIGNS ?
54
● Switch cases littered all over your application
● Hunt and replace policy
BENEFITS ?
55
• Reusability
• Maintainability
• Flexible design
DESIGN BY CONTRACT
56
• Methods of class define pre-conditions and
post-conditions
• The preconditions must be met for meth...
DESIGN BY CONTRACT
57
LISKOV
SUBSTITUTION
58
59
Sub-types must be
substitutable for their
base- types
When is something
Substitutable ?
60
Requires No Less
Promises No More
61
ELLIPSE/CIRCLE
62
ELLIPSE/CIRCLE
63
● Violation of LSP
● Circle violates the post conditions
● Circle not substitutable for Ellipse
BEFORE
64
AFTER
65
SIGNS ?
66
• Explicit Checking type of a class in the code
• Derived types not substitutable for the base
types
BENEFITS ?
67
• Ability to re-use code increases
• Flexible code
INTERFACE
SEGREGATION
68
69
70
Clients should not be forced
to depend on methods it
does not use
BEFORE
71
AFTER
72
SIGNS ?
73
● Client requiring things it does not need
● Methods littered with “NotImplemented”
exceptions
BENEFITS ?
74
• Lot of small, focused interfaces
• Flexible design
DEPENDENCY
INVERSION
75
76
77
Depend upon Abstractions
not upon Concretions
DIP
78
• High Level Modules should not depend on low
level modules, Both should depend on
Abstractions
• Abstractions shou...
BEFORE
79
AFTER
80
BEFORE
81
AFTER
82
SIGNS ?
83
● High level modules are harder to reuse
● Changes in the lower level modules directly
affect the higher level m...
ADVANTAGES ?
84
• Reusable modules
• Easier to extend
• Low Coupled code
KENT BECK
85
4 Simple Design Rules
PASSES TESTS
86
87
PASSES TESTS
88
● Unit tests with Red, Green, Refactor cycles
● Tests help communicate Design
REVEALS INTENTION
89
90
REVEALS INTENTION
91
● Self Documenting code
● Meaningful names to software entities
● Clear code
NO DUPLICATION
92
93
NO DUPLICATION
94
● Once and only once
● DRY
FEWEST ELEMENTS
95
96
FEWEST ELEMENTS
97
● No Superfluous parts/elements
● YAGNI
● KISS
● Minimum number of classes/methods
98
WRAPPING UP
99
● SRP - One responsibility per class
● OCP - Extend not modify
● LSP - Derived substitutable for base
● ISP...
REFERENCES
100
● Design Principles and Patterns (http://
www.objectmentor.com/resources/articles/
Principles_and_Patterns....
THANK YOU
Upcoming SlideShare
Loading in …5
×

Writing S.O.L.I.D Code

1,091 views

Published on

Presentation on S.O.L.I.D Design principles

Published in: Technology
  • You might get some help from ⇒ www.HelpWriting.net ⇐ Success and best regards!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Hello! I can recommend a site that has helped me. It's called ⇒ www.WritePaper.info ⇐ So make sure to check it out!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Very nice tips on this. In case you need help on any kind of academic writing visit website ⇒ www.HelpWriting.net ⇐ and place your order
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Copas Url to Read PDF Format === http://hellowbookeas.cf/b001c9jb12-education-correctionnelle-application-des-articles-66-et-67-du-code-penal-par-m-flandin.html
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Writing S.O.L.I.D Code

  1. 1. WRITING S.O.L.I.D CODE RAJEEV N B
  2. 2. RAJEEV N B 2 Developer at ThoughtWorks Blogs at www.rajeevnb.com @rbharshetty - Twitter @rshetty - Github
  3. 3. XP 3
  4. 4. This is me doing XP 4
  5. 5. IN THE BEGINNING 5 YOUR APPLICATION WAS PERFECT
  6. 6. THEN SOMETHING HAPPENED 6
  7. 7. YOUR APPLICATION CHANGED 7
  8. 8. DESIGN TO THE RESCUE 8
  9. 9. DESIGN ? 9
  10. 10. It is all about managing your DEPENDENCIES 10
  11. 11. DEPENDENCIES 11 Client Dependent on Logger
  12. 12. DEPENDENCIES 12
  13. 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
  14. 14. DEPENDENCY HELL 14
  15. 15. SUCCESSFUL DESIGN • INCREASED COHESION • DECREASED COUPLING • SUPPORTS REUSE • TESTABLE • FLEXIBLE 15
  16. 16. DESIGN STAMINA 16
  17. 17. SOFTWARE ROTS 17
  18. 18. WHY DOES SOFTWARE ROT ? • Changing requirements • Improper Design • No Continuos Design - Refactoring • Limited Project Resources • Complexity 18
  19. 19. ROBERT MARTIN 19 Design Principles and Design Patterns
  20. 20. SYMPTOMS OF ROTTING SOFTWARE • RIGIDITY • FRAGILITY • IMMOBILITY • VISCOSITY 20
  21. 21. RIGIDITY 21
  22. 22. 22
  23. 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. 24. FRAGILITY 24
  25. 25. 25
  26. 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. 27. IMMOBILITY 27
  28. 28. 28
  29. 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. 30. VISCOSITY 30
  31. 31. 31
  32. 32. VISCOSITY • VISCOSITY OF DESIGN • VISCOSITY OF ENVIRONMENT 32
  33. 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. 34. VISCOSITY OF ENVIRONMENT • Development Environment is slow and inefficient • Slower feedback Ex: Longer compile times, Slower builds, Long running tests 34
  35. 35. PREVENTING SOFTWARE ROT • Refactoring (Continuos Improvement of Design) • Testing (Unit/Integration/Contract tests) • Code Reviews • Documentation • Design Principles • Simplicity 35
  36. 36. OO DESIGN PRINCIPLES 36
  37. 37. S.O.L.I.D 37 Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
  38. 38. SINGLE RESPONSIBILITY 38
  39. 39. 39
  40. 40. 40 A software entity should have one and only one reason to change
  41. 41. BEFORE 41
  42. 42. AFTER 42
  43. 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. 44. SIGNS ? 44 • Description of class ( and/or ) • Rigidity and Fragility in code
  45. 45. BENEFITS ? 45 • Reduced Coupling • Separation of Concerns • Better readability • Your code evolves cleanly (Maintainable)
  46. 46. OPEN/CLOSED 46
  47. 47. 47
  48. 48. 48 Software entities should be closed for modification but open for extension
  49. 49. OCP 49 Add functionality by adding new code, not by modifying old code
  50. 50. ABSTRACTION IS THE KEY 50 • Client/Server relationship is open • Changes in Server cause changes in the client
  51. 51. ABSTRACTION IS THE KEY 51 • Client/Server relationship is closed • Abstract Servers close clients to changes in implementation
  52. 52. BEFORE 52
  53. 53. AFTER 53
  54. 54. SIGNS ? 54 ● Switch cases littered all over your application ● Hunt and replace policy
  55. 55. BENEFITS ? 55 • Reusability • Maintainability • Flexible design
  56. 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
  57. 57. DESIGN BY CONTRACT 57
  58. 58. LISKOV SUBSTITUTION 58
  59. 59. 59 Sub-types must be substitutable for their base- types
  60. 60. When is something Substitutable ? 60
  61. 61. Requires No Less Promises No More 61
  62. 62. ELLIPSE/CIRCLE 62
  63. 63. ELLIPSE/CIRCLE 63 ● Violation of LSP ● Circle violates the post conditions ● Circle not substitutable for Ellipse
  64. 64. BEFORE 64
  65. 65. AFTER 65
  66. 66. SIGNS ? 66 • Explicit Checking type of a class in the code • Derived types not substitutable for the base types
  67. 67. BENEFITS ? 67 • Ability to re-use code increases • Flexible code
  68. 68. INTERFACE SEGREGATION 68
  69. 69. 69
  70. 70. 70 Clients should not be forced to depend on methods it does not use
  71. 71. BEFORE 71
  72. 72. AFTER 72
  73. 73. SIGNS ? 73 ● Client requiring things it does not need ● Methods littered with “NotImplemented” exceptions
  74. 74. BENEFITS ? 74 • Lot of small, focused interfaces • Flexible design
  75. 75. DEPENDENCY INVERSION 75
  76. 76. 76
  77. 77. 77 Depend upon Abstractions not upon Concretions
  78. 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. 79. BEFORE 79
  80. 80. AFTER 80
  81. 81. BEFORE 81
  82. 82. AFTER 82
  83. 83. SIGNS ? 83 ● High level modules are harder to reuse ● Changes in the lower level modules directly affect the higher level modules
  84. 84. ADVANTAGES ? 84 • Reusable modules • Easier to extend • Low Coupled code
  85. 85. KENT BECK 85 4 Simple Design Rules
  86. 86. PASSES TESTS 86
  87. 87. 87
  88. 88. PASSES TESTS 88 ● Unit tests with Red, Green, Refactor cycles ● Tests help communicate Design
  89. 89. REVEALS INTENTION 89
  90. 90. 90
  91. 91. REVEALS INTENTION 91 ● Self Documenting code ● Meaningful names to software entities ● Clear code
  92. 92. NO DUPLICATION 92
  93. 93. 93
  94. 94. NO DUPLICATION 94 ● Once and only once ● DRY
  95. 95. FEWEST ELEMENTS 95
  96. 96. 96
  97. 97. FEWEST ELEMENTS 97 ● No Superfluous parts/elements ● YAGNI ● KISS ● Minimum number of classes/methods
  98. 98. 98
  99. 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. 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. 101. THANK YOU

×