Ruby on Rails with Interactors
guillecarlos.com
Ruby on Rails with Interactors
1–8 of 8 posts
Re: Ruby on Rails with Interactors
#2I'm not sure I understand the point of this. Am I just dense? Can someone explain in some detail?
To me this looks like a superfluous layer of indirection that causes you to have to manage your object method calls through an "interactor" instead of the object itself. That's just breaking the encapsulation pattern of OOP and I imagine this is nightmarish in terms of its impact on reusability of your code.
did I get it wrong or is this actually just a huge anti-pattern?
Re: Ruby on Rails with Interactors
#3I'm not sure I understand the point of this. Am I just dense? Can someone explain in some detail? To me this looks like a superfluous layer of indirection that causes you to have to manage your object method calls through an "interactor" instead of the object itself. That's just breaking the encapsulation pattern of OOP and I imagine this is nightmarish in terms of its impact on reusability of your code. did I get it…
Sometimes methods don't fit neatly into a specific model object. They may cut across multiple model objects, or call out to external libraries for logging and metrics.
When this happens, you can either have model objects that know too much about their surrounding environment, or you can put the code somewhere else.
In Rails, that "somewhere else" is usually a controller. But that's messy because now your application's logic is spread between a controller and multiple model objects.
Interactors are a way to clean that up. It allows you to put all of the code to accomplish a use case into one well-named place.
Good programming is about managing complexity. In practice, interactors have served us very well in managing complexity.
(Note: I work on the same code-base as the author of the article.)
Re: Ruby on Rails with Interactors
#4I'm not sure I understand the point of this. Am I just dense? Can someone explain in some detail? To me this looks like a superfluous layer of indirection that causes you to have to manage your object method calls through an "interactor" instead of the object itself. That's just breaking the encapsulation pattern of OOP and I imagine this is nightmarish in terms of its impact on reusability of your code. did I get it…
You can obviously build them wrong and end up with an anti-pattern but no, the Interactor pattern is all about managing how your objects communicate and building code units that are single business cases. In the OP's case, the Comment model shouldn't ever care about Mixpanel, or potentially emailing people that a new comment was posted, that logic can all go in an Interactor, where encapsulation and SRP is not invalidated.
Interactors let models handle only what they need to know, and help minimize the coupling between these models. Trying to follow how a feature is implemented in a "typical Rails app" can be a nightmare of View -> Controller -> Model -> lib -> Model -> etc. With this pattern, as long as the interactors are well named, an entire feature can be encapsulated in one object.
Re: Ruby on Rails with Interactors
#5I'm not sure I understand the point of this. Am I just dense? Can someone explain in some detail? To me this looks like a superfluous layer of indirection that causes you to have to manage your object method calls through an "interactor" instead of the object itself. That's just breaking the encapsulation pattern of OOP and I imagine this is nightmarish in terms of its impact on reusability of your code. did I get it…
Sometimes methods don't fit neatly into a specific model object. They may cut across multiple model objects, or call out to external libraries for logging and metrics. When this happens, you can either have model objects that know too much about their surrounding environment, or you can put the code somewhere else. In Rails, that "somewhere else" is usually a controller. But that's messy because now your application'…
do you find the Interactor pattern preferable to implementing a different re-use pattern for Controllers though? Why not use, for example, use Abstract Controllers and just include them as a Mixin to your Controllers.
e.g. CommentMixin would be an abstract controller class that is included in any controller that has an object that can be commented on.
Re: Ruby on Rails with Interactors
#6Earlier quoted context omitted.
Sometimes methods don't fit neatly into a specific model object. They may cut across multiple model objects, or call out to external libraries for logging and metrics. When this happens, you can either have model objects that know too much about their surrounding environment, or you can put the code somewhere else. In Rails, that "somewhere else" is usually a controller. But that's messy because now your application'…
do you find the Interactor pattern preferable to implementing a different re-use pattern for Controllers though? Why not use, for example, use Abstract Controllers and just include them as a Mixin to your Controllers. e.g. CommentMixin would be an abstract controller class that is included in any controller that has an object that can be commented on.
Interactors are not always triggered by a user event. Many of our interactors are triggered by a scheduled job or some other system process that doesn't touch a controller.
Also, as the article describes, interactors are plain old ruby objects, so are straightforward to test. An Abstract Controller, being a Rails construct, would require you to jump through some Rails hoops to test.
Re: Ruby on Rails with Interactors
#7Pedantic question here: Which of the classic Gang of Four patterns does interactors fall into? Mediator?
http://geekswithblogs.net/subodhnpushpak/archive/2009/09/18/...
Re: Ruby on Rails with Interactors
#8Once upon a time the Rails Brogrammers laughed at Java, where there was endless design pattern abuse and needless armchair architecture. Now the same has happened to Rails.
When you even think you might need to use Inter actors, it's time to roll onto a better and maybe newer platform, as it's downhill all way from now on.