SOLID Design Principles in Ruby

SOLID Design Principles in Ruby

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

2ad20e87f55ce79b113a12c516ec9d09?s=128

anildigital

June 27, 2014
Tweet

Transcript

  1. SOLID Anil Wadghule Software Engineer, Equal Experts awadghule@equalexperts.com Design principles

    in Ruby
  2. None
  3. In the beginning your application was perfect

  4. None
  5. Then it has changed

  6. Your application will change.

  7. None
  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

  24. None
  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?
  78. None
  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