Slides about design which makes difference to your app. How design can make your application more flexible to adapt future changes without breaking things.

1. Object Oriented
Design In Ruby
Presented By- Swapnil Abnave
Kiprosh, 5 December 2013

2. CHANGE
Fact: your application is going to
change. How will your application
handle that change?

3. Your App may be o
o
o
o
Rigid: Making a change somewhere will
break something somewhere else.
Fragile: You can’t predict where that break
will be.
Immobile: It’s hard to change/re-use your
code.
Viscous: It’s easier to do the wrong thing
than to fix things.

4. Design is all about
dependencies
• If you refer to something, you depend
on it.
• When the things you depend on
change, you must change.

5. SOLID
●
Single Responsibility
●
Open Closed
●
Liskov Substitution
●
Interface Segregation
●
Dependency Inversion

6. Single Responsibility
There should never be more than
one reason for a class to change

7. Open/Closed
A module should be open for
extension but closed for
modification

8. Dependency Inversion
Depend upon abstractions.
Do not depend upon concretions

9. IGNORABLE RULES
SOLID principles we can ignore in
ruby:
●
Interface Segregation
●
Liskov Substitution
WHY ?

10. Interface Segregation
●
Really only a problem for staticallytyped, 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.”

11. Interface Segregation
• What is it ? - “Many client
specific interfaces are better
than one general purpose
interface”

12. Liskov Substitution
When you design, don’t break the
contract of the superclass in the
subclass.

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

14. Resistance
Resistance 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.

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

16. "Triangle of Responsibility"
Refactoring
●
●
●
Refactor
Extract - Pull functionality out
where necessary
Inject - Inject that new
dependency into place from which
it was extracted

17. 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."

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

19. Dependency Injection
When injecting dependencies into a
class, do so only via arguments to
the
#initialize method
def
intialize(downloader=FTPDownloader.ne
w)
@downloader = downloader

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

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

22. 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)