All threads / Wrapping Business Logic with Plain Old Ruby Objects - GoRails

Ask A Question

Notifications

You’re not receiving notifications from this thread.

Wrapping Business Logic with Plain Old Ruby Objects - GoRails

Chris Oliver asked in General

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.

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.

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 :)

Join the discussion

Want to stay up-to-date with Ruby on Rails?

Join 33,665+ developers who get early access to new tutorials, screencasts, articles, and more.

    We care about the protection of your data. Read our Privacy Policy.

    logo Created with Sketch.

    Ruby on Rails tutorials, guides, and screencasts for web developers learning Ruby, Rails, Javascript, Turbolinks, Stimulus.js, Vue.js, and more. Icons by Icons8

    © 2020 GoRails, LLC. All rights reserved.