theirishpenguin/gist:7356daa8bab784536a6c

## gistfile1.txt
Ya, there are a few good interactor based gems floating around, including collectiveideas. I usually just apply the basic pattern discussed at https://www.youtube.com/watch?v=WpkDN78P884 ie. instead of object 1 and 2 talking to each other, introduce a third object to facilitate the communication. So this can be a Service object, or just another object.

I guess if that third object isn't quite at the Service level it's just another object - ie. in the case of an Interactor that depends on another Interactor, the top-level Interactor is a Service Object and the lower level Interactor is just another object. This scenario isn't common but by not assuming that every Interactor is a Service Object you reserve the right to do keep applying this technique to simplify code in a complex scenario.

So introducing a higher-level third object helps solve fat controllers/models in Rails, which would otherwise be too tightly coupled to each other and harder to test. And introducing a higher-level third object helps solve event spaghetti in Backbone, as does similar patterns in React/Flux. The takeaway point for me was - regardless of what type of code is being written - it seems that introducing a new orchestrating object which takes a bunch of other objects into it's constructor (and exposes a method to do something to them) is great to have in the toolbox to manage complexity.
	Ya, there are a few good interactor based gems floating around, including collectiveideas. I usually just apply the basic pattern discussed at https://www.youtube.com/watch?v=WpkDN78P884 ie. instead of object 1 and 2 talking to each other, introduce a third object to facilitate the communication. So this can be a Service object, or just another object.

	I guess if that third object isn't quite at the Service level it's just another object - ie. in the case of an Interactor that depends on another Interactor, the top-level Interactor is a Service Object and the lower level Interactor is just another object. This scenario isn't common but by not assuming that every Interactor is a Service Object you reserve the right to do keep applying this technique to simplify code in a complex scenario.

	So introducing a higher-level third object helps solve fat controllers/models in Rails, which would otherwise be too tightly coupled to each other and harder to test. And introducing a higher-level third object helps solve event spaghetti in Backbone, as does similar patterns in React/Flux. The takeaway point for me was - regardless of what type of code is being written - it seems that introducing a new orchestrating object which takes a bunch of other objects into it's constructor (and exposes a method to do something to them) is great to have in the toolbox to manage complexity.