[LRUG] Rails - The Missing Parts
Erich Kaderka
erich.kaderka at gmail.com
Tue Mar 4 12:13:08 PST 2014
Hi Tom,
I enjoyed reading the article until this point:
private
def send_emails_for(grouper)
LeaderMailer.grouper_confirmed(member: grouper.leader.id).deliver
WingMailer.grouper_confirmed(wings: grouper.wings.map(&:id)).deliver
AdminMailer.grouper_confirmed(grouper: grouper.admin.id).deliver
end
def assign_bar_for(grouper)
# Asynchronous job because it’s a little slow
AssignBarForGrouper.enqueue(grouper.id)
end
You can't test this class in isolation (you need to require all 3 mailers and AssignBarForGrouper). Maybe it seems ok now, but if there is in future another email with simple logic, you end up mocking every hard coded dependency for different scenarios. Plus I don't like passing ids to mailers, then in your mailer class you need to query for email ... I would suggest make both private methods public and introduce new object for sending emails
def send_emails_for(confirm_grouper_mailer: ConfirmGrouperMailer.new(leader_email: grouper.leader.email, wings_emails: grouper.wings.collect(&:email), admin_email: grouper.admin_email)
confirm_grouper_mailer.deliver
end
I don't think you need to test successful interactor, this scenario should be covered by end-to-end test
context “when the interactor is a success” do
let(:success) { true }
it { should redirect_to home_path }
end
The HN's discussion reminds of similar one here https://gist.github.com/justinko/2838490
You can find DHH's opinions on architecture etc on Ruby Rogues episode 056 http://rubyrogues.com/056-rr-david-heinemeier-hansson/
Thank you for your article,
Erich
On 4 Mar 2014, at 15:36, Najaf Ali <ali at happybearsoftware.com> wrote:
> > Using modules to mix in behaviour is the same as inheritance and the composition over inheritance argument has already been had.
>
> I don't think I'm quite clever enough to follow the whole service objects vs. modules vs. objects vs. dependency injection debate, but this line in particular weakens your argument a little.
>
> The composition over inheritance argument has indeed already been had: the primary reason that composition is better than inheritance is that inheritance needlessly couples type to implementation. Mixing in a module doesn't do that. There are other problems with modules (in particular when you have a lot of them, implicit dependencies can creep in between them) but "they are the same as inheritance therefore bad" strikes me as a little lazy.
>
>
> On Tue, Mar 4, 2014 at 2:15 PM, Stephen Best <bestie at gmail.com> wrote:
> @Riccardo Using decorators over extend gives you
>
> * No method / instance variable naming collisions (counts for private methods too)
> * Separate state
> * Very obvious which decorations have been applied
> * You can unwrap the decorators and get the original object back
>
> The annoying this really is that the difference in effort is negligible yet the module approach is widely cargo-culted.
>
> Using modules to mix in behaviour is the same as inheritance and the composition over inheritance argument has already been had.
>
>
> On 4 March 2014 10:24, Riccardo Tacconi <rtacconi at gmail.com> wrote:
> I created this project (very incomplete) to try few things and one was DCI: https://github.com/rtacconi/scriptrunner/blob/master/app/contexts/runner_on_project.rb. Yes I used 'extend' but it is 'expensive' and using mixins seems okay to me. What's the advantage of using decorators?
>
>
> On 4 March 2014 09:37, Stephen Best <bestie at gmail.com> wrote:
> Also why do Ruby developers insist on implementing DCI by mixing in modules at runtime? It's just completely unnecessary, why not decorate?
>
>
> Stephen Best
>
> +44 7745 790523
> theaudaciouscodeexpiment.com
> github.com/bestie
> @thebestie
>
>
> On 4 March 2014 09:35, Stephen Best <bestie at gmail.com> wrote:
> DHH as usual saying the best way to design your objects is don't. GOOD LUCK WITH THAT.
>
>
> Stephen Best
>
> +44 7745 790523
> theaudaciouscodeexpiment.com
> github.com/bestie
> @thebestie
>
>
> On 3 March 2014 23:09, Mark Burns <markthedeveloper at gmail.com> wrote:
> It's kind of similar, but DCI is kind of like a run-time only ActiveSupport::Concern.
> It's still a big bag o' methods, but a big dynamic bag of methods. Maybe less chance of collisions, but
> the principle is still the same as AS::Concern.
> Interactors in the sense of the interactor gem are cleaner as you're not polluting a potentially already
> overloaded domain model/persistence object hybrid.
>
>
> On 3 March 2014 22:18, Riccardo Tacconi <rtacconi at gmail.com> wrote:
> Hi Tom,
>
> Your interactor reminds me the I part (interaction) of DCI, am I wrong? I see few similarities.
>
>
> On 3 March 2014 20:38, Tom Blomfield <tomblomfield at gmail.com> wrote:
> Hi all,
>
> I wrote a blog post on Interactors in Rails - http://eng.joingrouper.com/blog/2014/03/03/rails-the-missing-parts-interactors
>
> You might enjoy the discussion on HN, with DHH wading in https://news.ycombinator.com/item?id=7335211
>
> Tom
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
>
>
> --
> Riccardo Tacconi
> Ruby on Rails and PHP development - System Administration
> VIRTUELOGIC LIMITED
>
> http://github.com/rtacconi
> http://riccardotacconi.blogspot.com
> http://twitter.com/rtacconi
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
>
>
>
>
> --
> Riccardo Tacconi
> Ruby on Rails and PHP development - System Administration
> VIRTUELOGIC LIMITED
>
> http://github.com/rtacconi
> http://riccardotacconi.blogspot.com
> http://twitter.com/rtacconi
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140304/e9cbf8f1/attachment.html>
More information about the Chat
mailing list