Skip to main content

Wrapping Business Logic with Plain Old Ruby Objects - GoRails

General • Asked by Chris Oliver

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.

That is correct. Whoops!

Actually, do we need attr_reader once we use delegate? would we have to say `to: @customer` if we did?

The attr_reader makes it so you don't have to reference the instance variable. "to: customer" points to the attr_reader, allowing you to go swap that out at some point with some other type of reference in the future if you wanted, rather than an instance variable which is useful for future potential refactoring since a attr_reader or function called "customer" would look exactly the same.


more like this plis!


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.

oh ok! makes a lot of sense! Thanks for the quick answer :)


Login or Create An Account to join the conversation.

Subscribe to the newsletter

Join 22,346+ developers who get early access to new screencasts, articles, guides, updates, and more.

    By clicking this button, you agree to the GoRails Terms of Service and Privacy Policy.

    More of a social being? We're also on Twitter and YouTube.