Object Oriented
Design In Ruby
Presented By- Swapnil Abnave

Kiprosh, 5 December 2013
CHANGE
Fact: your application is going to
change. How will your application
handle that change?
Your App may be o

o

o

o

Rigid: Making a change somewhere will
break something somewhere else.
Fragile: You can’t predi...
Design is all about
dependencies
• If you refer to something, you depend

on it.
• When the things you depend on

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 staticallytyped, compiled languages.

“Because we’re in Ruby, we don’t ...
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 – ...
Resistance
Resistance is a resource => Listen to what
the pain is telling you.
Listen to what the code smells are telling
...
Your Checkpoint for Design
When you get to the refactor stage of
red-green-refactor, ask yourself …
●

Is it DRY?

●

Does...
"Triangle of Responsibility"
Refactoring
●

●

●

Refactor
Extract - Pull functionality out
where necessary
Inject - Injec...
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 typic...
Act like an idiot
●

●

"You don't have to know where
you're going to successfully
refactor."

When you see someone's code...
Dependency Injection
When injecting dependencies into a
class, do so only via arguments to
the
#initialize method
def
inti...
Argument Order
Dependency
When you need to inject a few
dependencies, you can use an options
hash to remove the dependency...
Dependency is unavoidable
How to assess: "Does each object
depend on things that change less
than it does?”
●

Line up the...
Conclude to begin with design
TDD is not enough
DRY is not enough

Design because you expect your
application to succeed(a...
Upcoming SlideShare
Loading in …5
×

Object Oriented Design in Ruby

420 views
378 views

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
420
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Object Oriented Design in Ruby

  1. 1. Object Oriented Design In Ruby Presented By- Swapnil Abnave Kiprosh, 5 December 2013
  2. 2. CHANGE Fact: your application is going to change. How will your application handle that change?
  3. 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. 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. 5. SOLID ● Single Responsibility ● Open Closed ● Liskov Substitution ● Interface Segregation ● Dependency Inversion
  6. 6. Single Responsibility There should never be more than one reason for a class to change
  7. 7. Open/Closed A module should be open for extension but closed for modification
  8. 8. Dependency Inversion Depend upon abstractions. Do not depend upon concretions
  9. 9. IGNORABLE RULES SOLID principles we can ignore in ruby: ● Interface Segregation ● Liskov Substitution WHY ?
  10. 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. 11. Interface Segregation • What is it ? - “Many client specific interfaces are better than one general purpose interface”
  12. 12. Liskov Substitution When you design, don’t break the contract of the superclass in the subclass.
  13. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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)

×