Question: Why the Controller RegisterAndSendEmailController receives a generic use case?

[vinipachecov]

Hi professor Lemos! First, thanks for this highly interesting piece of example of the Clean Architecture.

I was wondering about one thing reading your code. It seems that your controller RegisterAndSendEmailController, which if I'm not wrong is a part of your presentation layer, it receives a generic Usecase interface instead of the actual use case injected during main layer late binding.

I understand that gives the following architectural behavior:

1. Satisfies the Dependency inversion principle by relying as most as possible on modules(files) that are not responsible for implementation details.
2. Satisfies the Single Responsibility Principle which reasons about a module having only a main reason for changing.

However, I wish to hear your opinion about this:

Would it be better to directly mention that the use case expected inside RegisterAndSendEmailController is the RegisterAndSendEmail?

My reasoning for this change would be:

• to force type checking not only with the Usecase interface type checking but also the actual usecase RegisterAndSendEmail that the controller will receive during the late binding that is done in the main layer.