SOLID Design Principles in Ruby

Slides of my talk on 'SOLID Design Principles in Ruby' at RedDot Ruby Conf Singapore.

Transcript

1. SOLID Anil Wadghule Software Engineer, Equal Experts awadghule@equalexperts.com Design principles in Ruby
3. In the beginning your application was perfect
5. Then it has changed
6. Your application will change.
8. It happened because of bad design
9. Modular code doesn’t mean good design
10. Design is all about managing dependencies.
11. Dependencies are important M A X Y Z T S class subclass Z X Y
12. Design might save you. Unmanaged dependencies are killing your application
13. What are smells of bad design?
14. Design smells
15. Rigid Difficult to change. (Every change causes too many changes in other parts of the system) Design smells
16. Design smells
17. Fragile Easily breakable (Each change breaks distant and unrelated things) Design smells
18. Design smells
19. Design smells Immobile Reuse is impossible (The code is hopelessly entangled)
20. Design smells
21. Design smells Viscous Toughness in preserving design (Doing things right is harder than doing things wrong
22. It did not start that way.
23. It did not start that way. Changes killed it
25. Why SOLID? It helps us to write code which is
26. • Loosely Coupled - Dependency Injection Why SOLID? It helps us to write code which is
27. • Loosely Coupled - Dependency Injection • Highly Cohesive - Single Responsibility Why SOLID? It helps us to write code which is
28. • Loosely Coupled - Dependency Injection • Highly Cohesive - Single Responsibility • Easily Composable - Can be changed Why SOLID? It helps us to write code which is
29. • 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
30. • 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
31. • 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
32. • Easy to maintain and extend over time Why SOLID? Ultimately it helps us to write code which is
33. Robert Martin http://www.objectmentor.com
34. Michael Feathers coined SOLID mnemonic acronym
35. S O L I D Principles
36. Single Responsibility O L I D Principles
37. Single Responsibility Open/Closed L I D Principles
38. Single Responsibility Open/Closed Liskov Substitution I D Principles
39. Single Responsibility Open/Closed Liskov Substitution Interface Segregation D Principles
40. Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion Principles
41. Lets look at these principles in detail !
42. Single Responsibility
43. Single Responsibility ! • A class should serve a single purpose
 • There should never be more than one reason for a class to change.
44. Single Responsibility • Reveal intent • Rename • Introduce constant • Introduce variable
 • Extract ‘Til you drop http://j.mp/extractDrop Achieve using following techniques
45. Single Responsibility • Generates ‘Highly cohesive’ code. • Removes ‘Immobility Smell’
46. Code example. Single Responsibility Requirement: Client needs Feed Saver application
47. Open/Closed Bertrand Meyer
48. Software entities (classes/ modules, methods) should be open for extension, but closed for modification Open/Closed
49. Open/Closed • Inheritance • Composition Achieved using
50. Open/Closed ! • snake of ‘if-else’ cases. • long switch cases. Smells
51. Open/Closed • Replace branching with delegation. • Inject behaviour • Extract method • Extract class • Wrap behaviour with abstraction
52. Code example. Open/Closed Requirement: Client says application should save Atom feeds
53. Parser + parse(xml) RSS Parser Atom Parser parse parse has been closed for modification Open/Closed Abstraction
54. Liskov Substitution Barbara Liskov
55. 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
56. 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
57. • Implement inheritance based on behaviour. • Do not violate behaviour of parent class
 • Obey the pre and postconditions rules. Liskov Substitution Rules
58. Code example. Liskov Substitution Lets see classic Rectangle, Square problem Also we will see what are preconditions and postconditions rules
59. Interface Segregation
60. Many client specific interfaces are better than one general purpose interface. Interface Segregation
61. Many client specific interfaces are better than one general purpose interface. Interface Segregation
62. Many client specific modules are better than one general purpose module. Interface Segregation
63. Many client specific classes are better than one general purpose class. Interface Segregation
64. Clients should not be forced to depend on methods they do not use. Interface Segregation
65. Interface Segregation • Helps for ‘Highly cohesive’ code. • Removes ‘Immobility Smell’
66. Code example. Interface Segregation Lets see HDTV, Normal TV app example And car, driver, mechanic app example
67. Dependency Inversion
68. Depend on abstractions. Do not depend on concretions. Dependency Inversion
69. 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.
70. Dependency Inversion Dependent design Copier Keyboard Reader char char Dependencies downwards Printer
71. Copier Keyboard Reader char char Dependent design Dependencies downwards Dependency Inversion Disk
72. Reader Inverted Dependencies. Dependency Inversion Copier Writer Keyboard Reader Printer Writer
73. Code example. Lets see the code Dependency Inversion
74. Can be achieved with different techniques.
 • Dependency Injection Dependency Inversion
75. • .new keyword • class method calls DI Smells Dependency Inversion
76. • Rigid code • Fragile code • Scary code Where does applying SOLID lead?
77. • Rigid code —> Flexible code • Fragile code —> Robust code • Scary code —> Cuddly code Where does applying SOLID lead?
79. It’s possible to learn Software Design and aim for good Software Design
80. 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)
81. • Design principles — Set of guidelines • Design patterns — Reusable solution to commonly occurring problems Design Principles vs Design Patterns
82. Abstraction is the key.
83. Thank you !!! @anildigital
84. Recommended Read
85. Recommended Watch
86. Recommended Watch SOLID Principles videos
87. 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
88. 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
89. Q&A