Better Ruby    Through Design Principles@mikegehardhttps://github.com/msgehardTech Lead – User AcquisitionLivingSocial
"Nothing endures but change.”Heraclitus of Ephesus (c.535 BC - 475 BC)
Thats great but how does that applyto Ruby?
Is my application going to change?
How is your application going to adjustto change?
What decides how your app is going torespond to change?
The design (1)
The interactions between classes (2)
Im using Rails so I dont need to do design
http://martinfowler.com/bliki/DesignStaminaHypothesis.html
Processing Requirements1.Parse a CSV file2.Report status of the parsing via email
Processing Requirements Week Two1.Parse either CSV or TSV file2.Report status of the parsing via email
What is the difference?
FileProcessor is no longer responsiblefor file parsing.
FileProcessor can parse new file typeswithout having to change.
Testing of parsing can be done inisolation.
Processing Requirements Week Three1.Parse either CSV or TSV file2.Report status of the parsing via Email or SMS
What is the difference?
Each class is responsible for one thing.
Reporters are functionallyinterchangeable and reusable.
Contracts between FileReporter andsupporting objects are small and easyto learn.
Testing of reporting can be done inisolation.
Future Processing Requirements1.Download file from FTP site or Dropbox.2.Parse either CSV, TSV or PDF files3.Report status...
SOLID
Single Responsibility Principle
Open for extensionClosed to modification
Liskov Substitution Principle
Interface Segregation
Dependency Inversion
Your mileage may vary (3)
Image Attributions(1) http://www.flickr.com/people/span112/(2) http://www.flickr.com/people/emsl/(3) http://www.flickr.com...
Any questions? (4)http://speakerrate.com/talks/9437                                    @mikegehard                        ...
Better Ruby Through Design Principles
Better Ruby Through Design Principles
Better Ruby Through Design Principles
Better Ruby Through Design Principles
Better Ruby Through Design Principles
Upcoming SlideShare
Loading in...5
×

Better Ruby Through Design Principles

967

Published on

A talk given at Mountain West Ruby Conf 2012 about software design in Ruby.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
967
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Apps change because their requirement change.
  • This is why you should pay attention to design, it pays off in the long run.So if you feel like your app is going to not be around that long then you can stop listening.
  • Show file_processor2.rb and file_processor2a.rb.
  • These are principles, not hard and fast rules.Sometimes they conflict with other principles or just don’t make sense.
  • Thanks to the conference organizers.Thanks to you all for listening.Thanks to the Boulder Ruby Group, especially David Hassler, for improving this talk via feedback.
  • Better Ruby Through Design Principles

    1. 1. Better Ruby Through Design Principles@mikegehardhttps://github.com/msgehardTech Lead – User AcquisitionLivingSocial
    2. 2. "Nothing endures but change.”Heraclitus of Ephesus (c.535 BC - 475 BC)
    3. 3. Thats great but how does that applyto Ruby?
    4. 4. Is my application going to change?
    5. 5. How is your application going to adjustto change?
    6. 6. What decides how your app is going torespond to change?
    7. 7. The design (1)
    8. 8. The interactions between classes (2)
    9. 9. Im using Rails so I dont need to do design
    10. 10. http://martinfowler.com/bliki/DesignStaminaHypothesis.html
    11. 11. Processing Requirements1.Parse a CSV file2.Report status of the parsing via email
    12. 12. Processing Requirements Week Two1.Parse either CSV or TSV file2.Report status of the parsing via email
    13. 13. What is the difference?
    14. 14. FileProcessor is no longer responsiblefor file parsing.
    15. 15. FileProcessor can parse new file typeswithout having to change.
    16. 16. Testing of parsing can be done inisolation.
    17. 17. Processing Requirements Week Three1.Parse either CSV or TSV file2.Report status of the parsing via Email or SMS
    18. 18. What is the difference?
    19. 19. Each class is responsible for one thing.
    20. 20. Reporters are functionallyinterchangeable and reusable.
    21. 21. Contracts between FileReporter andsupporting objects are small and easyto learn.
    22. 22. Testing of reporting can be done inisolation.
    23. 23. Future Processing Requirements1.Download file from FTP site or Dropbox.2.Parse either CSV, TSV or PDF files3.Report status of the parsing via Email, SMS or Nagios.
    24. 24. SOLID
    25. 25. Single Responsibility Principle
    26. 26. Open for extensionClosed to modification
    27. 27. Liskov Substitution Principle
    28. 28. Interface Segregation
    29. 29. Dependency Inversion
    30. 30. Your mileage may vary (3)
    31. 31. Image Attributions(1) http://www.flickr.com/people/span112/(2) http://www.flickr.com/people/emsl/(3) http://www.flickr.com/people/kennejima/(4) http://www.flickr.com/people/27282406@N03/References• http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf• http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod• http://confreaks.com/videos/240-goruco2009-solid-object-oriented-design• http://confreaks.com/videos/185-rubyconf2009-solid-ruby• http://blog.rubybestpractices.com/posts/gregory/055-issue-23-solid-design.html• http://mmiika.wordpress.com/oo-design-principles/
    32. 32. Any questions? (4)http://speakerrate.com/talks/9437 @mikegehard https://github.com/msgehard

    ×