Writing S.O.L.I.D Code
-
Upload
rajeev-bharshetty -
Category
Technology
-
view
540 -
download
0
Transcript of Writing S.O.L.I.D Code
WRITING S.O.L.I.D CODERAJEEV 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, Reusability, Flexibility
and Maintainability of your applications decrease
• Unmanaged dependencies lead to “Dependency Hell”
13
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 Resources
• Complexity
18
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 can’t be estimated
• Time and Cost can’t be quantified
23
FRAGILITY
24
25
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
IMMOBILITY
27
28
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
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 thing
• As time progresses, it will become increasingly difficult to
continue developing the application
33
VISCOSITY OF ENVIRONMENT
• Development Environment is slow and inefficient
• Slower feedback
Ex: Longer compile times, Slower builds, Long running tests
34
PREVENTING SOFTWARE ROT
• Refactoring (Continuos Improvement of Design)
• Testing (Unit/Integration/Contract tests)
• Code Reviews
• Documentation
• Design Principles
• Simplicity
35
OO DESIGN PRINCIPLES
36
S.O.L.I.D
37
Single Responsibility Principle
Open/Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
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 change
• Changes in one responsibility may affect another
• Coupling among classes leads to Fragile Design
43
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
implementation
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 method
to execute
• Upon completion, method guarantees that
the post conditions are met
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 should not depend on details. Details should depend on abstractions.
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 modules
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 - Split into Focussed interfaces
● DIP - Depend on Abstractions
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
THANK YOU