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
   

   View Slide

2. View Slide

3. In the beginning your application was perfect
   

   View Slide

4. View Slide

5. Then it has changed
   

   View Slide

6. Your application will change.
   

   View Slide

7. View Slide

8. It happened because of bad
   design
   

   View Slide

9. Modular code doesn’t mean
   good design
   

   View Slide

10. Design is all about managing
    dependencies.
    

    View Slide

11. Dependencies are important
    M
    A
    X
    Y
    Z
    T
    S
    class
    subclass
    Z
    X
    Y
    

    View Slide

12. Design might save you.
    Unmanaged dependencies are killing your
    application
    

    View Slide

13. What are smells of bad design?
    

    View Slide

14. Design smells
    

    View Slide

15. Rigid
    Difficult to change.
    (Every change causes too
    many changes in other
    parts of the system)
    Design smells
    

    View Slide

16. Design smells
    

    View Slide

17. Fragile
    Easily breakable
    (Each change breaks
    distant and unrelated
    things)
    Design smells
    

    View Slide

18. Design smells
    

    View Slide

19. Design smells
    Immobile
    Reuse is impossible
    (The code is hopelessly
    entangled)
    

    View Slide

20. Design smells
    

    View Slide

21. Design smells
    Viscous
    Toughness in preserving
    design
    (Doing things right is
    harder than doing things
    wrong
    

    View Slide

22. It did not start that way.
    

    View Slide

23. It did not start that way.
    Changes killed it
    

    View Slide

24. View Slide

25. Why SOLID?
    It helps us to write code which is
    

    View Slide

26. • Loosely Coupled - Dependency Injection
    Why SOLID?
    It helps us to write code which is
    

    View Slide

27. • Loosely Coupled - Dependency Injection
    • Highly Cohesive - Single Responsibility
    Why SOLID?
    It helps us to write code which is
    

    View Slide

28. • Loosely Coupled - Dependency Injection
    • Highly Cohesive - Single Responsibility
    • Easily Composable - Can be changed
    Why SOLID?
    It helps us to write code which is
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

32. • Easy to maintain and extend
    over time
    Why SOLID?
    Ultimately it helps us to write code which is
    

    View Slide

33. Robert Martin
    http://www.objectmentor.com
    

    View Slide

34. Michael Feathers coined SOLID mnemonic
    acronym
    

    View Slide

35. S
    O
    L
    I
    D
    Principles
    

    View Slide

36. Single Responsibility
    O
    L
    I
    D
    Principles
    

    View Slide

37. Single Responsibility
    Open/Closed
    L
    I
    D
    Principles
    

    View Slide

38. Single Responsibility
    Open/Closed
    Liskov Substitution
    I
    D
    Principles
    

    View Slide

39. Single Responsibility
    Open/Closed
    Liskov Substitution
    Interface Segregation
    D
    Principles
    

    View Slide

40. Single Responsibility
    Open/Closed
    Liskov Substitution
    Interface Segregation
    Dependency Inversion
    Principles
    

    View Slide

41. Lets look at these principles in
    detail !
    

    View Slide

42. Single Responsibility
    

    View Slide

43. Single Responsibility
    !
    • A class should serve a single
    purpose

    • There should never be more
    than one reason for a class to
    change.
    

    View Slide

44. Single Responsibility
    • Reveal intent
    • Rename
    • Introduce constant
    • Introduce variable

    • Extract ‘Til you drop http://j.mp/extractDrop
    Achieve using following techniques
    

    View Slide

45. Single Responsibility
    • Generates ‘Highly cohesive’
    code.
    • Removes ‘Immobility Smell’
    

    View Slide

46. Code example.
    Single Responsibility
    Requirement: Client needs Feed Saver application
    

    View Slide

47. Open/Closed
    Bertrand Meyer
    

    View Slide

48. Software entities (classes/
    modules, methods) should be
    open for extension, but closed
    for modification
    Open/Closed
    

    View Slide

49. Open/Closed
    • Inheritance
    • Composition
    Achieved using
    

    View Slide

50. Open/Closed
    !
    • snake of ‘if-else’ cases.
    • long switch cases.
    Smells
    

    View Slide

51. Open/Closed
    • Replace branching with delegation.
    • Inject behaviour
    • Extract method
    • Extract class
    • Wrap behaviour with abstraction
    

    View Slide

52. Code example.
    Open/Closed
    Requirement: Client says application should save Atom feeds
    

    View Slide

53. Parser
    + parse(xml)
    RSS
    Parser
    Atom
    Parser
    parse
    parse has been closed for modification
    Open/Closed
    Abstraction
    

    View Slide

54. Liskov Substitution
    Barbara Liskov
    

    View Slide

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
    

    View Slide

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
    

    View Slide

57. • Implement inheritance based on behaviour.
    • Do not violate behaviour of parent class

    • Obey the pre and postconditions rules.
    Liskov Substitution
    Rules
    

    View Slide

58. Code example.
    Liskov Substitution
    Lets see classic Rectangle, Square problem
    Also we will see what are preconditions and postconditions rules
    

    View Slide

59. Interface Segregation
    

    View Slide

60. Many client specific interfaces
    are better than one general
    purpose interface.
    Interface Segregation
    

    View Slide

61. Many client specific interfaces
    are better than one general
    purpose interface.
    Interface Segregation
    

    View Slide

62. Many client specific modules are
    better than one general purpose
    module.
    Interface Segregation
    

    View Slide

63. Many client specific classes are
    better than one general purpose
    class.
    Interface Segregation
    

    View Slide

64. Clients should not be forced to
    depend on methods they do not
    use.
    Interface Segregation
    

    View Slide

65. Interface Segregation
    • Helps for ‘Highly cohesive’
    code.
    • Removes ‘Immobility Smell’
    

    View Slide

66. Code example.
    Interface Segregation
    Lets see HDTV, Normal TV app example
    And car, driver, mechanic app example
    

    View Slide

67. Dependency Inversion
    

    View Slide

68. Depend on abstractions.
    Do not depend on concretions.
    Dependency Inversion
    

    View Slide

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.
    

    View Slide

70. Dependency Inversion
    Dependent design
    Copier
    Keyboard Reader
    char char
    Dependencies downwards
    Printer
    

    View Slide

71. Copier
    Keyboard Reader
    char char
    Dependent design
    Dependencies downwards
    Dependency Inversion
    Disk
    

    View Slide

72. Reader
    Inverted Dependencies.
    Dependency Inversion
    Copier
    Writer
    Keyboard Reader Printer Writer
    

    View Slide

73. Code example.
    Lets see the code
    Dependency Inversion
    

    View Slide

74. Can be achieved with different
    techniques.

    • Dependency Injection
    Dependency Inversion
    

    View Slide

75. • .new keyword
    • class method calls
    DI Smells
    Dependency Inversion
    

    View Slide

76. • Rigid code
    • Fragile code
    • Scary code
    Where does applying SOLID lead?
    

    View Slide

77. • Rigid code —> Flexible code
    • Fragile code —> Robust code
    • Scary code —> Cuddly code
    Where does applying SOLID lead?
    

    View Slide

78. View Slide

79. It’s possible to learn Software Design and aim
    for good Software Design
    

    View Slide

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)
    

    View Slide

81. • Design principles — Set of guidelines
    • Design patterns — Reusable solution
    to commonly occurring problems
    Design Principles vs Design Patterns
    

    View Slide

82. Abstraction is the key.
    

    View Slide

83. Thank you !!!
    @anildigital
    

    View Slide

84. Recommended Read
    

    View Slide

85. Recommended Watch
    

    View Slide

86. Recommended Watch
    SOLID Principles videos
    

    View Slide

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
    

    View Slide

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
    

    View Slide

89. Q&A
    

    View Slide