Your SlideShare is downloading. ×
0
SOLID
Anil Wadghule
Software Engineer, Equal Experts
awadghule@equalexperts.com
Design principles in Ruby
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 wh...
• Loosely Coupled - Dependency Injection
• Highly Cohesive - Single Responsibility
• Easily Composable - Can be changed
Wh...
• Loosely Coupled - Dependency Injection
• Highly Cohesive - Single Responsibility
• Easily Composable - Can be changed
• ...
• Loosely Coupled - Dependency Injection
• Highly Cohesive - Single Responsibility
• Easily Composable - Can be changed
• ...
• Loosely Coupled - Dependency Injection
• Highly Cohesive - Single Responsibility
• Easily Composable - Can be changed
• ...
Robert Martin
http://www.objectmentor.com
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 ...
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 objec...
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
th...
• 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-...
Dependency Inversion
Copy
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 Inversion
Button
Lamp
Abstract
Details
Details
It’s possible to learn Software Design and aim
for good Software Design
Design because
TDD is not enough
DRY is not enough
Design because you expect your
application to succeed (and to change
in...
• Design principles — Set of guidelines
• Design patterns — Reusable solution
to commonly occurring problems
Design Princi...
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/ph...
Sandi Metz - SOLID Object-Oriented Design talk 2009
Clean Coders Videos - Uncle Bob Martin
SOLID Ruby - Jim Weirich - Ruby...
Questions?
SOLID design principles in Ruby
SOLID design principles in Ruby
SOLID design principles in Ruby
SOLID design principles in Ruby
Upcoming SlideShare
Loading in...5
×

SOLID design principles in Ruby

1,360

Published on

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,360
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
16
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Transcript of "SOLID design principles in Ruby"

  1. 1. SOLID Anil Wadghule Software Engineer, Equal Experts awadghule@equalexperts.com Design principles in Ruby
  2. 2. In the beginning your application was perfect
  3. 3. Your application will change.
  4. 4. Then it has changed.
  5. 5. Modular code doesn’t mean good design
  6. 6. Design is all about managing dependencies.
  7. 7. Dependencies are important Z A X YA X Y Z A B class subclass
  8. 8. Design might save you. Unmanaged dependencies are killing your application
  9. 9. What are smells of bad design?
  10. 10. Design smells
  11. 11. Design smells Rigid
  12. 12. Rigid Difficult to change. (Every change causes too many changes in other parts of the system) Design smells
  13. 13. Design smells
  14. 14. Design smells Fragile
  15. 15. Fragile Easily breakable (Each change breaks distant and unrelated things) Design smells
  16. 16. Design smells
  17. 17. Design smells Immobile
  18. 18. Design smells Immobile Reuse is impossible (The code is hopelessly entangled)
  19. 19. Design smells
  20. 20. Design smells Viscous
  21. 21. Design smells Viscous Toughness in preserving design (Doing things right is harder than doing things wrong
  22. 22. It did not start that way.
  23. 23. Why SOLID? It helps us to write code which is
  24. 24. • Loosely Coupled - Dependency Injection Why SOLID? It helps us to write code which is
  25. 25. • Loosely Coupled - Dependency Injection • Highly Cohesive - Single Responsibility Why SOLID? It helps us to write code which is
  26. 26. • Loosely Coupled - Dependency Injection • Highly Cohesive - Single Responsibility • Easily Composable - Can be changed Why SOLID? It helps us to write code which is
  27. 27. • 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
  28. 28. • 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
  29. 29. • 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
  30. 30. Robert Martin http://www.objectmentor.com
  31. 31. S O L I D Principles
  32. 32. Single Responsibility O L I D Principles
  33. 33. Single Responsibility Open/Closed L I D Principles
  34. 34. Single Responsibility Open/Closed Liskov Substitution I D Principles
  35. 35. Single Responsibility Open/Closed Liskov Substitution Interface Segregation D Principles
  36. 36. Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion Principles
  37. 37. Lets look at these principles in detail. Principles
  38. 38. Single Responsibility
  39. 39. Single Responsibility ! • A class should serve a single purpose

  40. 40. Single Responsibility ! • A class should serve a single purpose
 • There should never be more than one reason for a class to change.
  41. 41. Single Responsibility • Generates ‘Highly cohesive’ code. • Removes ‘Immobility Smell’
  42. 42. Code example. Single Responsibility Requirement: Client needs Feed saver application
  43. 43. Open/Closed
  44. 44. Software entities (classes/ modules, methods) should be open for extension, but closed for modification Open/Closed
  45. 45. Open/Closed • Helps to remove snake of ‘if- else’ cases. • and remove those bad switch cases.
  46. 46. Code example. Open/Closed Requirement: Client says application should save Atom feeds
  47. 47. Parser + parse(xml) RSS Parser Atom Parser parse parse has been closed for modification Open/Closed
  48. 48. Liskov Substitution
  49. 49. 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
  50. 50. 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
  51. 51. • Implement inheritance based on behaviour. • Obey the pre and postconditions rules. Liskov Substitution Rules
  52. 52. Code example. Liskov Substitution Lets see classic Rectangle, Square problem Also preconditions and postconditions rules
  53. 53. Interface Segregation
  54. 54. Many client specific interfaces are better than one general purpose interface. Interface Segregation
  55. 55. Many client specific interfaces are better than one general purpose interface. Interface Segregation
  56. 56. Many client specific classes are better than one general purpose class. Interface Segregation
  57. 57. Interface Segregation • Helps for ‘Highly cohesive’ code. • Removes ‘Immobility Smell’
  58. 58. Code example. Interface Segregation Lets see HDTV, Normal TV application Also car, driver, mechanic app
  59. 59. Dependency Inversion
  60. 60. 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.
  61. 61. Dependency Inversion Copy ReadKeyboard char char Dependencies downwards WritePrinter Dependent design
  62. 62. Copy ReadKeyboard char char Dependent design Dependencies downwards Dependency Inversion WriteDisk
  63. 63. Copy Reader Inverted Dependencies. Dependency Inversion ReadKeyboard Writer PrinterWriter
  64. 64. Code example. Dependency Inversion Lets see classic Button & Lamp application
  65. 65. Dependency Inversion Downwards dependency Button Lamp Dependency Inversion
  66. 66. Abstract Button Button Client Inverted Dependencies. Dependency Inversion Button Lamp Abstract Details Details
  67. 67. It’s possible to learn Software Design and aim for good Software Design
  68. 68. 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)
  69. 69. • Design principles — Set of guidelines • Design patterns — Reusable solution to commonly occurring problems Design Principles vs Design Patterns
  70. 70. Abstraction is the key.
  71. 71. Thank you !!! Follow me on Twitter @anildigital
  72. 72. Recommended Read
  73. 73. 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
  74. 74. 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
  75. 75. Questions?
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×