Interfaces in the view package

[charlesbts]

In the presentation layer, the interfaces from View package (UserDetailsView, UserListView...) shouldn't be in the Presenter package? If I understood the Dependency Inversion Principle, the Presenter should define the interface that the view have to implement.

[Trikke]

I don't see what this has to do with the Dependency Inversion Principle, would you care to explain your viewpoint?

[charlesbts]

First, thanks for reply.

My point is, the view (Android thing) there's in the outermost layer in the Clean Architecture.
Therefore, the dependency should point from View to the Presenter.
Thus as the Domain Layer define the interface UserRepository for the Data Layer implements, I think that the Presenter should define the interfaces
for the View implements, in this case, the dependency is not from the Presenter to view.

I hope I have been clear, my english doesn't help.

[Trikke]

Presenters are also part of the same outmost "View layer". If there's anything said about dependency, it is that a Presenter should not know about the implementation of the view it is given. This is why the presenter is passed an Interface of this "View", as it then become easily to use multiple concrete implementations of that "View" for the same Presenter. The Dependency Inversion Principle doesn't come into play here.

[charlesbts]

Yes, I understand the MVP part, but in the scheme of README, suggest to me that the Presenter is the Interface Adapter
and the UI (View) is the Framework/Drivers, different layers. Threrefore, I thought that the View package should depend from
interfaces inside the Presenter package. Anyway, maybe I have missed anything.

[Trikke]

Ah, now i see where you are coming from! It wasn't full clear to me where you'd gotten that idea. But yes, in a certain way you are correct. That circle diagram makes more sense for very large projects where an application could be distributed with several UI's. Image that this application would exist as an Android app, but also als a Command Line tool. Of course, in the current example this would require some work. But if you would be creating such an app, it does make sense that the Presenters are pure java implementations and the UI is further abstracted away in a separate Android module and a separate Java (for CLI) module. Then the views in these module should indeed implement the Interfaces existing on the level of the Presenters.

But the current example in this repository is not multi-UI, but just an Android app. So for the sake of both simplicity an it not being a requirement, the Presenters and Views live in the same layer. And in this configuration, it makes sense that the presenters just use an interface of the View and the actual implementation is injected by Dagger.

The key is only doing as much work as the scope of your project requires.

[charlesbts]

Yeah, you're right, for simplicity this way is more appropriate.
This idea came mainly from a Uncle Bob article (bellow). In this article, he speak about make the Tool be dependent on the Business rules.

http://blog.cleancoder.com/uncle-bob/2016/01/04/ALittleArchitecture.html