Wrapping Business Logic with Plain Old Ruby Objects - GoRails
Awesome video. I didn't know about the classify method, I'd been leaning on camelize or more manual conversions if it didn't deal with pluralization gracefully. Which is silly, because they're all right here: http://api.rubyonrails.org/...
Maybe worth noting these are provided by Rails/not in regular Ruby? Who knows.
Ideas for future episodes: are there any parts of Rails that you've traditionally found useful to pull out into PORO's? (I'm mainly thinking of ActiveModel, but really anything.) Sort of a generic question: what makes blocks useful? When would you want to use a block with .call here instead of regular arguments? Lastly, where might an ActiveRecord::Attribute be used for cases like this?
Chris, another great one! You had 3 tests at the beginning for the 3 fee types. With having the code moved to the new classes would you write new tests or you think it's enough to have those 3 tests?
I would rewrite those tests to use those classes directly. It'll clean up the tests and then you can optionally have the test for the Customer model that tests the integration of the two classes if you keep that.
Great episode! Thanks.
I think that in the delegate statement shown (at around 19:50), the suffix 'to: customer' is missing.
Why do we initialize the customer in the base class when its already initialized after a customer object/instance is created in the controller?
You save the customer to an instance variable in the initializer so that you can save it around and use it in any of your subclasses automatically. They don't have to worry about how they get the customer, they just know they have it so they can implement only the calculation.