[metaphorm]

I'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?

[RKlophaus]

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

[metaphorm]

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.

[RKlophaus]

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.

[jameskilton]

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.