Better Ruby Through Design Principles

  • 896 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
896
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

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

Transcript

  • 1. Better Ruby Through Design Principles@mikegehardhttps://github.com/msgehardTech Lead – User AcquisitionLivingSocial
  • 2. "Nothing endures but change.”Heraclitus of Ephesus (c.535 BC - 475 BC)
  • 3. Thats great but how does that applyto Ruby?
  • 4. Is my application going to change?
  • 5. How is your application going to adjustto change?
  • 6. What decides how your app is going torespond to change?
  • 7. The design (1)
  • 8. The interactions between classes (2)
  • 9. Im using Rails so I dont need to do design
  • 10. http://martinfowler.com/bliki/DesignStaminaHypothesis.html
  • 11. Processing Requirements1.Parse a CSV file2.Report status of the parsing via email
  • 12. Processing Requirements Week Two1.Parse either CSV or TSV file2.Report status of the parsing via email
  • 13. What is the difference?
  • 14. FileProcessor is no longer responsiblefor file parsing.
  • 15. FileProcessor can parse new file typeswithout having to change.
  • 16. Testing of parsing can be done inisolation.
  • 17. Processing Requirements Week Three1.Parse either CSV or TSV file2.Report status of the parsing via Email or SMS
  • 18. What is the difference?
  • 19. Each class is responsible for one thing.
  • 20. Reporters are functionallyinterchangeable and reusable.
  • 21. Contracts between FileReporter andsupporting objects are small and easyto learn.
  • 22. Testing of reporting can be done inisolation.
  • 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. SOLID
  • 25. Single Responsibility Principle
  • 26. Open for extensionClosed to modification
  • 27. Liskov Substitution Principle
  • 28. Interface Segregation
  • 29. Dependency Inversion
  • 30. Your mileage may vary (3)
  • 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. Any questions? (4)http://speakerrate.com/talks/9437 @mikegehard https://github.com/msgehard