Interactors vs Use Case Controller

[Facundo Javier Gelatti]

In my OOD class we use Larman's book Applying UML and Patterns, and in there he uses the GRASP Controller Pattern (which I think has a sad name, because is often confused with the controller in MVC, an issue addressed in the book).

That pattern suggest an object to be implemented per use case (a use case controller), that receives the messages from the presentation layer and communicates with the domain entities in order to realize that use case (much like interactors). In the case study of the book (a point of sale system), a use case controller like this is used (I've modified it a bit so that it uses gateways, since the original patterns for communicating with the persistence layer are different):

The controller keeps the state of the transaction corresponding to the use case, and provides the operations that can be done to modify that state (a good opportunity to implement the state pattern). It can also validate that the operations are executed in the correct order, if necessary (cannot enter an item if the sale was already paid).

So, in the case that we decide to implement this use case using interactors, will only one interactor be needed, or one per operation? (for example, one to start the transaction, another to enter an item, and so on) Where do we keep the state of the transaction? And should we separate that state from the operations that modifies it?

[Norbert Nemes]

Hello

The way I understand interactors and how Uncle Bob describes them, is that they represent use cases (not operations). They also hold the state for that use case. So what you are calling a controller in your post sounds awfully a lot like an interactor to me.

Regards,

Norbert

[Juan Manuel Gimeno Illa]

El lunes, 5 de enero de 2015 11:24:43 UTC+1, Norbert Nemes escribió:

Hello

The way I understand interactors and how Uncle Bob describes them, is that they represent use cases (not operations). They also hold the state for that use case. So what you are calling a controller in your post sounds awfully a lot like an interactor to me.

Larman's controllers represent use-cases as well and contain the operations neeeded by the UI to implement the use case. In my opinion they are the same as interactors. 

What Larman's architecture does not cover is the way Interactors and the delivery mechanism communicate (Presenters and Boundary in the Clean Architecture).

Juan Manuel 

[Facundo Javier Gelatti]

I agree. I was having problems when trying to implement the interactors for "multi-step" use cases, like process sale (in which you are incrementally performing the use case) using the command pattern with an unifying interface for all interactors (with only one execute() operation)