SOLID design principles in Ruby
•
7 j'aime•3,529 vues
The document discusses the SOLID principles of object-oriented design, which are Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. It defines each principle, provides examples of how to apply it in code, and explains how following the principles can help create code that is loosely coupled, highly cohesive, reusable, and easily testable.
Recommandé
Contenu connexe
En vedette
En vedette (10)
Similaire à SOLID design principles in Ruby
Similaire à SOLID design principles in Ruby (20)
Dernier
Dernier (20)
SOLID design principles in Ruby
- 1. SOLID Anil Wadghule Software Engineer, Equal Experts awadghule@equalexperts.com Design principles in Ruby
- 3. In the beginning your application was perfect
- 4. Your application will change.
- 6. Then it has changed.
- 7. Modular code doesn’t mean good design
- 8. Design is all about managing dependencies.
- 10. Design might save you. Unmanaged dependencies are killing your application
- 11. What are smells of bad design?
- 12. Design smells
- 14. Rigid Difficult to change. (Every change causes too many changes in other parts of the system) Design smells
- 15. Design smells
- 17. Fragile Easily breakable (Each change breaks distant and unrelated things) Design smells
- 18. Design smells
- 20. Design smells Immobile Reuse is impossible (The code is hopelessly entangled)
- 21. Design smells
- 23. Design smells Viscous Toughness in preserving design (Doing things right is harder than doing things wrong
- 24. It did not start that way.
- 26. Why SOLID? It helps us to write code which is
- 27. • Loosely Coupled - Dependency Injection Why SOLID? It helps us to write code which is
- 28. • Loosely Coupled - Dependency Injection • Highly Cohesive - Single Responsibility Why SOLID? It helps us to write code which is
- 29. • Loosely Coupled - Dependency Injection • Highly Cohesive - Single Responsibility • Easily Composable - Can be changed 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 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 Why SOLID? It helps us to write code which is
- 32. • 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
- 38. Single Responsibility Open/Closed Liskov Substitution Interface Segregation D Principles
- 39. Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion Principles
- 40. Lets look at these principles in detail. Principles
- 42. Single Responsibility ! • A class should serve a single purpose
- 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 • Generates ‘Highly cohesive’ code. • Removes ‘Immobility Smell’
- 45. Code example. Single Responsibility Requirement: Client needs Feed saver application
- 46. Open/Closed
- 47. Software entities (classes/ modules, methods) should be open for extension, but closed for modification Open/Closed
- 48. Open/Closed • Helps to remove snake of ‘if- else’ cases. • and remove those bad switch cases.
- 49. Code example. Open/Closed Requirement: Client says application should save Atom feeds
- 50. Parser + parse(xml) RSS Parser Atom Parser parse parse has been closed for modification Open/Closed
- 52. 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
- 53. 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
- 54. • Implement inheritance based on behaviour. • Obey the pre and postconditions rules. Liskov Substitution Rules
- 55. Code example. Liskov Substitution Lets see classic Rectangle, Square problem Also preconditions and postconditions rules
- 57. Many client specific interfaces are better than one general purpose interface. Interface Segregation
- 58. Many client specific interfaces are better than one general purpose interface. Interface Segregation
- 59. Many client specific classes are better than one general purpose class. Interface Segregation
- 60. Interface Segregation • Helps for ‘Highly cohesive’ code. • Removes ‘Immobility Smell’
- 61. Code example. Interface Segregation Lets see HDTV, Normal TV application Also car, driver, mechanic app
- 63. 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.
- 64. Dependency Inversion Copy ReadKeyboard char char Dependencies downwards WritePrinter Dependent design
- 65. Copy ReadKeyboard char char Dependent design Dependencies downwards Dependency Inversion WriteDisk
- 67. Code example. Dependency Inversion Lets see classic Button & Lamp application
- 69. Abstract Button Button Client Inverted Dependencies. Dependency Inversion Button Lamp Abstract Details Details
- 71. It’s possible to learn Software Design and aim for good Software Design
- 72. 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)
- 73. • Design principles — Set of guidelines • Design patterns — Reusable solution to commonly occurring problems Design Principles vs Design Patterns
- 74. Abstraction is the key.
- 75. Thank you !!! Follow me on Twitter @anildigital
- 76. Recommended Read
- 78. 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
- 79. Questions?