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.

1. WRITING S.O.L.I.D CODE
RAJEEV N B

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

6. THEN SOMETHING HAPPENED
6

7. YOUR APPLICATION
CHANGED
7

8. DESIGN TO THE
RESCUE
8

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

14. DEPENDENCY HELL
14

15. SUCCESSFUL DESIGN
• INCREASED COHESION
• DECREASED COUPLING
• SUPPORTS REUSE
• TESTABLE
• FLEXIBLE
15

16. DESIGN STAMINA
16

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

36. OO DESIGN
PRINCIPLES
36

37. S.O.L.I.D
37
Single Responsibility Principle
Open/Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

38. SINGLE
RESPONSIBILITY
38

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

57. DESIGN BY CONTRACT
57

58. LISKOV
SUBSTITUTION
58

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

62. ELLIPSE/CIRCLE
62

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

68. INTERFACE
SEGREGATION
68

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

75. DEPENDENCY
INVERSION
75

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

89. REVEALS INTENTION
89

90. 90

91. REVEALS INTENTION
91
● Self Documenting code
● Meaningful names to software entities
● Clear code

92. NO DUPLICATION
92

93. 93

94. NO DUPLICATION
94
● Once and only once
● DRY

95. FEWEST ELEMENTS
95

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