SOLID design principles in Ruby
Upcoming SlideShare
Loading in...5
×
 

SOLID design principles in Ruby

on

  • 424 views

 

Statistics

Views

Total Views
424
Slideshare-icon Views on SlideShare
423
Embed Views
1

Actions

Likes
0
Downloads
4
Comments
0

1 Embed 1

http://www.slideee.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    SOLID design principles in Ruby SOLID design principles in Ruby Presentation Transcript

    • SOLID Anil Wadghule Software Engineer, Equal Experts awadghule@equalexperts.com Design principles in Ruby
    • In the beginning your application was perfect
    • Your application will change.
    • Then it has changed.
    • Modular code doesn’t mean good design
    • Design is all about managing dependencies.
    • Dependencies are important Z A X YA X Y Z A B class subclass
    • Design might save you. Unmanaged dependencies are killing your application
    • What are smells of bad design?
    • Design smells
    • Design smells Rigid
    • Rigid Difficult to change. (Every change causes too many changes in other parts of the system) Design smells
    • Design smells
    • Design smells Fragile
    • Fragile Easily breakable (Each change breaks distant and unrelated things) Design smells
    • Design smells
    • Design smells Immobile
    • Design smells Immobile Reuse is impossible (The code is hopelessly entangled)
    • Design smells
    • Design smells Viscous
    • Design smells Viscous Toughness in preserving design (Doing things right is harder than doing things wrong
    • It did not start that way.
    • Why SOLID? It helps us to write code which is
    • • Loosely Coupled - Dependency Injection Why SOLID? It helps us to write code which is
    • • Loosely Coupled - Dependency Injection • Highly Cohesive - Single Responsibility Why SOLID? It helps us to write code which is
    • • Loosely Coupled - Dependency Injection • Highly Cohesive - Single Responsibility • Easily Composable - Can be changed Why SOLID? It helps us to write code which is
    • • 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
    • • 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
    • • 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
    • Robert Martin http://www.objectmentor.com
    • S O L I D Principles
    • Single Responsibility O L I D Principles
    • Single Responsibility Open/Closed L I D Principles
    • Single Responsibility Open/Closed Liskov Substitution I D Principles
    • Single Responsibility Open/Closed Liskov Substitution Interface Segregation D Principles
    • Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion Principles
    • Lets look at these principles in detail. Principles
    • Single Responsibility
    • Single Responsibility ! • A class should serve a single purpose

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