SOLID design principles in Ruby

  • 794 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
794
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
8
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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

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