Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Better Ruby Through Design Principles

1,317 views

Published on

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

Published in: Technology
  • Be the first to comment

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

×