SOLID Design Principles in Ruby

Slides from my talk on applying SOLID design principles in Ruby. Originally gave the talk at Nash.rb meetup.

Transcript

1. SOLID Design Principles in Ruby @jjbohn
2. What is good design? • Easy to reason about • Easy to change
3. Change Happens • Good design is a design that facilitates change
4. How do we facilitate change? • Make it easy to swap one type of object for another • Give objects a common interface to work from
5. Limit the reasons for a class to change • Classes that only need to change for one reason are easy to change. • Classes that have multiple responsibilities are harder to change. Changing something about one responsibility may break another.
6. That’s what the Single Responsibility Principle • It’s not “a class should only have one job” • It’s “A software entity should only have one reason to change”
7. Facilitating change with Interfaces • Other languages allow us to formally define this • Ruby does not • Java for instance has Interfaces. Interfaces define a set of methods that you are going to implement. Objective-C has protocols which is a set of methods and properties
8. Keep things private • Dynamic languages have implied contracts hidden in the code. When you call a method from another object, you are defining this contract. • Keep this contract as small as possible • Minimum viable method set
9. Dependency Inversion Principle • Depend upon Abstractions. Do not depend upon concretions. • Write code that relies on quacking, not ducks.
10. Interface Segregation Principle • Keep those contracts small
11. Interface Segregation/Single Responsibility as modules • Keep common interface implementations in modules that can be included • eg. Sluggable, Badgeable, PublishesLifeCycleEvents
12. Keeping objects that share virtual interfaces similar • If you inherit from a class, really inherit all the way. • Don’t explode because something is not set up right • You have a leaky abstraction and you need to take a look at your design
13. Liskov Substitution Principle • If it looks like a duck and quacks like a duck, but the duck needs batteries, you’ve broken LSP (you have the wrong abstraction) • Preconditions • return or raise if • Postcondition • Catch/Ensure • Try to stay away from new exceptions specific for sub classes. They are hard to catch.
14. Another Way - Allow Substitution via Optional Conversion • Tell the object to convert itself to what you are looking for
15. Make it so you can add functionality without modifying the class (or method) • Classic Example • Callbacks/Blocks • Config loops • Dependency Injection • #call • That’s the Open/Close Principle
16. Thanks! Single Responsilbity A class should have only one reason to change Open/Closed Software entities should be open for extension, but closed for modification Liskov Substition Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program Interface Segregation Many client-specific interfaces are better than one general-purpose interface Dependency Inversion Principle Depend on abstractions, not concretions