Object Oriented
Design In Ruby
Presented By- Swapnil AbnaveKiprosh, 5 December 2013
CHANGE
Fact: your application is going to change. How will your application handle that change?
Your App may be -
o Rigid: Making a change somewhere will break something somewhere else.
o Fragile: You can’t predict where that break will be.
o Immobile: It’s hard to change/re-use your code.
o Viscous: It’s easier to do the wrong thing than to fix things.
Design is all about dependencies
• If you refer to something, you depend on it.
• When the things you depend on change, you must change.
SOLID
● Single Responsibility
● Open Closed
● Liskov Substitution
● Interface Segregation
● Dependency Inversion
Single Responsibility
There should never be more than one reason for a class
to change
Open/Closed
A module should be open for extension but closed for
modification
Dependency Inversion
Depend upon abstractions.
Do not depend upon concretions
IGNORABLE RULES
SOLID principles we can ignore in ruby:
● Interface Segregation● Liskov Substitution
WHY ?
Interface Segregation● Really only a problem for statically-
typed, compiled languages.
“Because we’re in Ruby, we don’t have this problem! Win!”
● “Dynamic languages obey this rule in the most extreme way possible: duck typing.”
Interface Segregation
• What is it ? - “Many client specific interfaces are better than one general purpose interface”
Liskov Substitution
When you design, don’t break the contract of the superclass in the subclass.
DESIGN MIGHT SAVE YOU
To avoid dependencies, your design should be:
● Loosely coupled – D – Inject
● Highly cohesive – SRP
● Easily composable – Can be changed
● Context independent – Can be rearranged
ResistanceResistance is a resource => Listen to
what the pain is telling you.
● Listen to what the code smells are telling you.
● Embrace the friction.
● Fix the problem.
If testing seems hard – examine your design.
Your Checkpoint for Design
When you get to the refactor stage of red-green-refactor, ask yourself …
● Is it DRY?
● Does it have just one responsibility?
● Does everything change at the same rate?
● Does it depend on things that change less than it does?
"Triangle of Responsibility"
Refactoring● Refactor● Extract - Pull functionality out where necessary
● Inject - Inject that new dependency into place from which it was extracted
Act like an idiot
● What if I don't know where I want this refactoring to take me?
● That's OK. In fact, that's typical.
● "Refactor, not because you know the abstraction, but because you want to find it."
Act like an idiot
● "You don't have to know where you're going to successfully refactor."
● When you see someone's code and think it's beautiful and you wonder how they thought of it, they didn't. They evolved it to that point.
Dependency Injection
When injecting dependencies into a class, do so only via arguments to the
#initialize method
def intialize(downloader=FTPDownloader.new)
@downloader = downloader
end
Argument Order Dependency
When you need to inject a few dependencies, you can use an options hash to remove the dependency on the order of the arguments
def intialize(opts)
@env = opts[:env] || Rails.env
filename = opts[:filename]
end
Dependency is unavoidable
How to assess: "Does each object depend on things that change less than it does?”
● Line up the objects from left to right
Left = lower likelihood of change
Right = higher likelihood of change
● Only depend on things on your left
Conclude to begin with design
TDD is not enough
DRY is not enough
Design because you expect your application to
succeed(and to change in the future to come)