020 RR Object Oriented Programming in Rails with Jim Weirich
Podcast: Play in new window
| Download (Duration: 1:09:13 — 49.4MB)
Discussed in this Episode
- What is Object Oriented Programming?
- If Ruby or Rails programmers aren’t programming in an object oriented way does it matter?
- The goal isn’t to do OO for OO’s sake.
- Tell, don’t ask
- Case switching on the object’s class can be refactored to take advantage of Polymorphism
- Law of Demeter: Am I allowed to know this?
- Single Responsibility Principle
- Ask “What does this object do?” rather than building around the data contained in the object.
- Presenters (The Presenter Pattern)
- Steven Kabnik’s Post on Object Oriented Programming and the Presenter Pattern in Rails
- The problem with Helpers
- In OO, you’re allowed to add more Objects (or Classes)
- Building your models without referencing ActiveRecord
- Business objects that reference ActiveRecord data access objects
- Object Thinking
- The database is the last bastion of non-object oriented thinking
- Behavior centric vs data centric design
- The impedance mismatch between the database and the object oriented designs
- Object Oriented Design centers around maintainability and complexity
- Don’t use generators
- Create classes and evolve them into models as you need the persistence
- Rather than asking for data, tell a class to do something for you
- Three small things to watch out for:
- Switch/case on class
- Arrays and hashes or arrays of hashes of arrays (Primitive Obsession)
- Subclassing Array or Hash
- Don’t inherit from String
- Enumerable module
- Rake’s FileList
- Skinny Controllers
- Is REST simply a way of pulling the impedance mismatch from the database all the way up to URL’s?