• Save
Better Ruby Through Design Principles
Upcoming SlideShare
Loading in...5
×
 

Better Ruby Through Design Principles

on

  • 1,169 views

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.

Statistics

Views

Total Views
1,169
Views on SlideShare
1,122
Embed Views
47

Actions

Likes
2
Downloads
0
Comments
0

2 Embeds 47

http://lanyrd.com 45
http://www.hanrss.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 Better Ruby Through Design Principles Presentation Transcript

  • 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 of the parsing via Email, SMS or Nagios.
  • 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/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/
  • Any questions? (4)http://speakerrate.com/talks/9437 @mikegehard https://github.com/msgehard