solid design principles in ruby
TRANSCRIPT
In the beginning your application was perfect
Your application will change.
Then it has changed.
Modular code doesn’t mean good design
Design is all about managing dependencies.
Dependencies are important
Z
A
X
YA
X
Y
Z
A
B
class
subclass
Design might save you.
Unmanaged dependencies are killing your application
What are smells of bad design?
Design smells
Design smells
Rigid
Rigid Difficult to change.
(Every change causes too many changes in other
parts of the system)
Design smells
Design smells
Design smells
Fragile
Fragile Easily breakable
(Each change breaks distant and unrelated
things)
Design smells
Design smells
Design smells
Immobile
Design smells
Immobile Reuse is impossible
(The code is hopelessly entangled)
Design smells
Design smells
Viscous
Design smells
Viscous Toughness in preserving
design (Doing things right is
harder than doing things wrong
It did not start that way.
Why SOLID?It helps us to write code which is
• Loosely Coupled - Dependency Injection
Why SOLID?It helps us to write code which is
• Loosely Coupled - Dependency Injection
• Highly Cohesive - Single Responsibility
Why SOLID?It helps us to write code which is
• Loosely Coupled - Dependency Injection
• Highly Cohesive - Single Responsibility • Easily Composable - Can be changed
Why SOLID?It helps us to write code which is
• 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
• 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
• Loosely Coupled - Dependency Injection
• Highly Cohesive - Single Responsibility • Easily Composable - Can be changed
• Context Independent - Can be rearranged
• Reusable • Easily testable code
Why SOLID?It helps us to write code which is
S O L I D
Principles
Single Responsibility O L I D
Principles
Single Responsibility Open/Closed L I D
Principles
Single Responsibility Open/Closed Liskov Substitution I D
Principles
Single Responsibility Open/Closed Liskov Substitution Interface Segregation D
Principles
Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion
Principles
Lets look at these principles in detail.
Principles
Single Responsibility
Single Responsibility
!
• A class should serve a single purpose
Single Responsibility!
• A class should serve a single purpose
• There should never be more than one reason for a class to change.
Single Responsibility
• Generates ‘Highly cohesive’ code.
• Removes ‘Immobility Smell’
Code example.
Single Responsibility
Requirement: Client needs Feed saver application
Open/Closed
Software entities (classes/modules, methods) should be open for extension, but closed for modification
Open/Closed
Open/Closed• Helps to remove snake of ‘if-
else’ cases. • and remove those bad switch
cases.
Code example.
Open/Closed
Requirement: Client says application should save Atom feeds
Parser
+ parse(xml)
RSS Parser
Atom Parser
parse
parse has been closed for modification
Open/Closed
Liskov Substitution
Subclasses should be substitutable for their base classes.
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
If a piece of client code works for a type then it must work for all derived types. A new subtype should not screw up the client code.
Liskov Substitution
• Implement inheritance based on behaviour.
• Obey the pre and postconditions rules.
Liskov Substitution
Rules
Code example.
Liskov Substitution
Lets see classic Rectangle, Square problem
Also preconditions and postconditions rules
Interface Segregation
Many client specific interfaces are better than one general purpose interface.
Interface Segregation
Many client specific interfaces are better than one general purpose interface.
Interface Segregation
Many client specific classes are better than one general purpose class.
Interface Segregation
Interface Segregation
• Helps for ‘Highly cohesive’ code.
• Removes ‘Immobility Smell’
Code example.
Interface Segregation
Lets see HDTV, Normal TV application
Also car, driver, mechanic app
Dependency Inversion
Depend on abstractions. Do not depend on concretions.
Dependency Inversion
A. High-level modules should not depend on low-level modules. Both should depend on abstractions. B. Abstractions should not depend on details. Details should depend on abstractions.
Dependency InversionCopy
ReadKeyboard
char char
Dependencies downwards
WritePrinter
Dependent design
Copy
ReadKeyboard
char char
Dependent design
Dependencies downwards
Dependency Inversion
WriteDisk
Copy
Reader
Inverted Dependencies.
Dependency Inversion
ReadKeyboard
Writer
PrinterWriter
Code example.
Dependency Inversion
Lets see classic Button & Lamp application
Dependency Inversion
Downwards dependency
Button
Lamp
Dependency Inversion
Abstract Button
Button Client
Inverted Dependencies.
Dependency InversionButton
Lamp
Abstract
Details
Details
It’s possible to learn Software Design and aim for good Software Design
Design becauseTDD is not enough
DRY is not enough
Design because you expect your application to succeed (and to change in the future to come)
• Design principles — Set of guidelines
• Design patterns — Reusable solution to commonly occurring problems
Design Principles vs Design Patterns
Abstraction is the key.
Thank you !!!Follow me on Twitter
@anildigital
Recommended Read
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
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)
References
Questions?