Upload
xp-conference-india
View
535
Download
0
Embed Size (px)
Citation preview
RAJEEV N B
2
Developer at ThoughtWorks
Blogs at www.rajeevnb.com
@rbharshetty - Twitter
@rshetty - Github
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
SUCCESSFUL DESIGN
• INCREASED COHESION
• DECREASED COUPLING
• SUPPORTS REUSE
• TESTABLE
• FLEXIBLE
15
WHY DOES SOFTWARE ROT ?
• Changing requirements
• Improper Design
• No Continuos Design - Refactoring
• Limited Project Resources
• Complexity
18
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
• 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
• 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 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
S.O.L.I.D
37
Single Responsibility Principle
Open/Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
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
BENEFITS ?
45
• Reduced Coupling • Separation of Concerns • Better readability • Your code evolves cleanly (Maintainable)
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
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
ELLIPSE/CIRCLE
63
● Violation of LSP
● Circle violates the post conditions
● Circle not substitutable for Ellipse
SIGNS ?
66
• Explicit Checking type of a class in the code
• Derived types not substitutable for the base
types
SIGNS ?
73
● Client requiring things it does not need
● Methods littered with “NotImplemented”
exceptions
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.
SIGNS ?
83
● High level modules are harder to reuse
● Changes in the lower level modules directly
affect the higher level modules
FEWEST ELEMENTS
97
● No Superfluous parts/elements
● YAGNI
● KISS
● Minimum number of classes/methods
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