Slide 1
Slide 1 text
SOLID
Anil Wadghule
Software Engineer, Equal Experts
[email protected]
Design principles in Ruby
Slide 2
Slide 2 text
No content
Slide 3
Slide 3 text
In the beginning your application was perfect
Slide 4
Slide 4 text
No content
Slide 5
Slide 5 text
Then it has changed
Slide 6
Slide 6 text
Your application will change.
Slide 7
Slide 7 text
No content
Slide 8
Slide 8 text
It happened because of bad
design
Slide 9
Slide 9 text
Modular code doesn’t mean
good design
Slide 10
Slide 10 text
Design is all about managing
dependencies.
Slide 11
Slide 11 text
Dependencies are important
M
A
X
Y
Z
T
S
class
subclass
Z
X
Y
Slide 12
Slide 12 text
Design might save you.
Unmanaged dependencies are killing your
application
Slide 13
Slide 13 text
What are smells of bad design?
Slide 14
Slide 14 text
Design smells
Slide 15
Slide 15 text
Rigid
Difficult to change.
(Every change causes too
many changes in other
parts of the system)
Design smells
Slide 16
Slide 16 text
Design smells
Slide 17
Slide 17 text
Fragile
Easily breakable
(Each change breaks
distant and unrelated
things)
Design smells
Slide 18
Slide 18 text
Design smells
Slide 19
Slide 19 text
Design smells
Immobile
Reuse is impossible
(The code is hopelessly
entangled)
Slide 20
Slide 20 text
Design smells
Slide 21
Slide 21 text
Design smells
Viscous
Toughness in preserving
design
(Doing things right is
harder than doing things
wrong
Slide 22
Slide 22 text
It did not start that way.
Slide 23
Slide 23 text
It did not start that way.
Changes killed it
Slide 24
Slide 24 text
No content
Slide 25
Slide 25 text
Why SOLID?
It helps us to write code which is
Slide 26
Slide 26 text
• Loosely Coupled - Dependency Injection
Why SOLID?
It helps us to write code which is
Slide 27
Slide 27 text
• Loosely Coupled - Dependency Injection
• Highly Cohesive - Single Responsibility
Why SOLID?
It helps us to write code which is
Slide 28
Slide 28 text
• Loosely Coupled - Dependency Injection
• Highly Cohesive - Single Responsibility
• Easily Composable - Can be changed
Why SOLID?
It helps us to write code which is
Slide 29
Slide 29 text
• Loosely Coupled - Dependency Injection
• Highly Cohesive - Single Responsibility
• Easily Composable - Can be changed
• Context Independent - Can be
rearranged
Why SOLID?
It helps us to write code which is
Slide 30
Slide 30 text
• Loosely Coupled - Dependency Injection
• Highly Cohesive - Single Responsibility
• Easily Composable - Can be changed
• Context Independent - Can be
rearranged
• Reusable
Why SOLID?
It helps us to write code which is
Slide 31
Slide 31 text
• Loosely Coupled - Dependency Injection
• Highly Cohesive - Single Responsibility
• Easily Composable - Can be changed
• Context Independent - Can be rearranged
• Reusable
• Easily testable
Why SOLID?
It helps us to write code which is
Slide 32
Slide 32 text
• Easy to maintain and extend
over time
Why SOLID?
Ultimately it helps us to write code which is
Slide 33
Slide 33 text
Robert Martin
http://www.objectmentor.com
Slide 34
Slide 34 text
Michael Feathers coined SOLID mnemonic
acronym
Slide 35
Slide 35 text
S
O
L
I
D
Principles
Slide 36
Slide 36 text
Single Responsibility
O
L
I
D
Principles
Slide 37
Slide 37 text
Single Responsibility
Open/Closed
L
I
D
Principles
Slide 38
Slide 38 text
Single Responsibility
Open/Closed
Liskov Substitution
I
D
Principles
Slide 39
Slide 39 text
Single Responsibility
Open/Closed
Liskov Substitution
Interface Segregation
D
Principles
Slide 40
Slide 40 text
Single Responsibility
Open/Closed
Liskov Substitution
Interface Segregation
Dependency Inversion
Principles
Slide 41
Slide 41 text
Lets look at these principles in
detail !
Slide 42
Slide 42 text
Single Responsibility
Slide 43
Slide 43 text
Single Responsibility
!
• A class should serve a single
purpose
• There should never be more
than one reason for a class to
change.
Slide 44
Slide 44 text
Single Responsibility
• Reveal intent
• Rename
• Introduce constant
• Introduce variable
• Extract ‘Til you drop http://j.mp/extractDrop
Achieve using following techniques
Slide 45
Slide 45 text
Single Responsibility
• Generates ‘Highly cohesive’
code.
• Removes ‘Immobility Smell’
Slide 46
Slide 46 text
Code example.
Single Responsibility
Requirement: Client needs Feed Saver application
Slide 47
Slide 47 text
Open/Closed
Bertrand Meyer
Slide 48
Slide 48 text
Software entities (classes/
modules, methods) should be
open for extension, but closed
for modification
Open/Closed
Slide 49
Slide 49 text
Open/Closed
• Inheritance
• Composition
Achieved using
Slide 50
Slide 50 text
Open/Closed
!
• snake of ‘if-else’ cases.
• long switch cases.
Smells
Slide 51
Slide 51 text
Open/Closed
• Replace branching with delegation.
• Inject behaviour
• Extract method
• Extract class
• Wrap behaviour with abstraction
Slide 52
Slide 52 text
Code example.
Open/Closed
Requirement: Client says application should save Atom feeds
Slide 53
Slide 53 text
Parser
+ parse(xml)
RSS
Parser
Atom
Parser
parse
parse has been closed for modification
Open/Closed
Abstraction
Slide 54
Slide 54 text
Liskov Substitution
Barbara Liskov
Slide 55
Slide 55 text
Subtypes must be substitutable
for their base types.
Liskov Substitution
Let q(x) be a property provable about objects x of type T.
Then q(y) should be true for objects y of type S where S is
subtype of T
Slide 56
Slide 56 text
If a piece of client code works for a
type then it must work for all derived/
variant types.
A new subtype should not screw up
the client code.
Liskov Substitution
Slide 57
Slide 57 text
• Implement inheritance based on behaviour.
• Do not violate behaviour of parent class
• Obey the pre and postconditions rules.
Liskov Substitution
Rules
Slide 58
Slide 58 text
Code example.
Liskov Substitution
Lets see classic Rectangle, Square problem
Also we will see what are preconditions and postconditions rules
Slide 59
Slide 59 text
Interface Segregation
Slide 60
Slide 60 text
Many client specific interfaces
are better than one general
purpose interface.
Interface Segregation
Slide 61
Slide 61 text
Many client specific interfaces
are better than one general
purpose interface.
Interface Segregation
Slide 62
Slide 62 text
Many client specific modules are
better than one general purpose
module.
Interface Segregation
Slide 63
Slide 63 text
Many client specific classes are
better than one general purpose
class.
Interface Segregation
Slide 64
Slide 64 text
Clients should not be forced to
depend on methods they do not
use.
Interface Segregation
Slide 65
Slide 65 text
Interface Segregation
• Helps for ‘Highly cohesive’
code.
• Removes ‘Immobility Smell’
Slide 66
Slide 66 text
Code example.
Interface Segregation
Lets see HDTV, Normal TV app example
And car, driver, mechanic app example
Slide 67
Slide 67 text
Dependency Inversion
Slide 68
Slide 68 text
Depend on abstractions.
Do not depend on concretions.
Dependency Inversion
Slide 69
Slide 69 text
Dependency Inversion
Abstractions should not depend on details. Details
should depend on abstractions.
High-level modules should not depend on low-level modules.
Both should depend on abstractions.
Slide 70
Slide 70 text
Dependency Inversion
Dependent design
Copier
Keyboard Reader
char char
Dependencies downwards
Printer
Slide 71
Slide 71 text
Copier
Keyboard Reader
char char
Dependent design
Dependencies downwards
Dependency Inversion
Disk
Slide 72
Slide 72 text
Reader
Inverted Dependencies.
Dependency Inversion
Copier
Writer
Keyboard Reader Printer Writer
Slide 73
Slide 73 text
Code example.
Lets see the code
Dependency Inversion
Slide 74
Slide 74 text
Can be achieved with different
techniques.
• Dependency Injection
Dependency Inversion
Slide 75
Slide 75 text
• .new keyword
• class method calls
DI Smells
Dependency Inversion
Slide 76
Slide 76 text
• Rigid code
• Fragile code
• Scary code
Where does applying SOLID lead?
Slide 77
Slide 77 text
• Rigid code —> Flexible code
• Fragile code —> Robust code
• Scary code —> Cuddly code
Where does applying SOLID lead?
Slide 78
Slide 78 text
No content
Slide 79
Slide 79 text
It’s possible to learn Software Design and aim
for good Software Design
Slide 80
Slide 80 text
Design because
TDD is not enough
DRY is not enough
Design because you expect your
application to succeed (and to change
in the future to come)
Slide 81
Slide 81 text
• Design principles — Set of guidelines
• Design patterns — Reusable solution
to commonly occurring problems
Design Principles vs Design Patterns
Slide 82
Slide 82 text
Abstraction is the key.
Slide 83
Slide 83 text
Thank you !!!
@anildigital
Slide 84
Slide 84 text
Recommended Read
Slide 85
Slide 85 text
Recommended Watch
Slide 86
Slide 86 text
Recommended Watch
SOLID Principles videos
Slide 87
Slide 87 text
http://www.flickr.com/photos/scjn/3586487445
http://www.flickr.com/photos/51241173@N03/8083645853
http://www.flickr.com/photos/wouterrietberg/12076192934
http://www.flickr.com/photos/clonedmilkmen/3604999084
http://lostechies.com/wp-content/uploads/2011/03/pablos_solid_ebook.pdf
Photo credits
Slide 88
Slide 88 text
Sandi Metz - SOLID Object-Oriented Design talk 2009
Clean Coders Videos - Uncle Bob Martin
SOLID Ruby - Jim Weirich - Ruby Conference 2009
https://github.com/kevinbuch/solid for examples (ISP, DIP)
Pablo's SOLID Software Development - http://lostechies.com/wp-content/uploads/
2011/03/pablos_solid_ebook.pdf
http://blog.groupbuddies.com/posts/19-solid-principles-in-ruby for examples (ISP)
http://www.codeproject.com/Articles/613304/SOLID-Principles-The-Liskov-Principle-
What-Why-and for examples (LSP
http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
References
Slide 89
Slide 89 text
Q&A