Clean Architecture - Why do we need an interactor interface?

[Breno Sarkis]

Hello,

A coworker and I were discussing this yesterday, it makes sense for a presenter to have an interface, that way he can be implemented at the ui boundary, which conforms to the architecture rule about inner cicles knowing nothing about outer cicles.

But why do we need an interactor interface? if the interactor is contained in an inner cicle, why cant the controller call it directly? how likely it is that you'll have more than one implementation of an interactor? 

PS: I'm not playing agains't having this interface, I just want to understand its true porpose.

A side question, Isn't, after all, the gateway a boundary?

Imagining the project structure, Uncle Bob suggested once that you would have a folder for gateway, interactor, boundaries and entities, shouldn't the gateway be inside the boundary folder?

[Sebastian Gozin]

I suppose so you can recompile your 1 implementation of your interactor without having to recompile the ui.
You would be able to see all the collaborators and if you used the same logic on those you'd know exactly which concrete collaborators they are causing even more reason for recompilation.

The issue is not being able to swap the implementation but being able to hide implementation details.
The gateway interface would be inside the boundary component I'd think.

As a side note, I tend to use implicit interfaces these days by using dynamic language features. I've found this has motivated me to set on a few generic ways to communicate which rarely change.

[Breno Sarkis]

Thanks Sebastian,

I guess we were too much into the architectural side of things, we absolutelly forgot that in order to test, we need to decouple, so we _need_ an interactor interface!!! that was so silly, were embarrassed!

At the architectural side, we need the power of having the ability to split the implementation of the ui and use cases also, we must always strive for independent deployability.

[Carson H]

I agree that it isn't necessary to have an interface for an interactor. In fact I don't even have an interface for my repositories. 

The positives:

- Less code to maintain, 

- Easier to navigate around your app.

The negatives:

- Harder to replace interactors or repositories

- Danger of someone modifying public fields

If you aren't dynamically changing your interactor or repository implementations, in my opinion the positives of no interfaces win if you have good control over your review process.

If you're using dependency injection, testing is the same

[Łukasz Duda]

Hi Breno,

Some languages such as Java or C# forces you to use explicit interfaces.

In other cases you may need them if one person specifies contract and different one implements the behavior.

You may want to publish documentation without references to concrete implementation.

I use explicit interface as a facade pattern to simplify use case activation.

Anyway, I think in many cases there's no need to use explicit interface. Just remember about the implicit interface.

Regards

Łukasz