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