android10 / Android-CleanArchitecture-Kotlin

This is a movies sample app in Kotlin, which is part of a serie of blog posts I have written about architecting android application using different approaches.
https://fernandocejas.com/2018/05/07/architecting-android-reloaded/
4.68k stars 928 forks source link

ViewModel knows all the implementation of UseCases #89

Closed RicardAparicio closed 4 years ago

RicardAparicio commented 4 years ago

Sorry if this topic has been already discussed, but I don't understand why ViewModel (presentation layer) knows all implementation of UseCases which belongs to Domain layer, is this violating the dependency inversion principle of SOLID?

I can see that ViewModel has an instance of Repository (Data layer) knowing only its abstraction using an interface, for me ViewModel should do the same with UseCases somehow.

My question is, should ViewModel knows only the abstraction of the UseCases instead of all the implementation? Or it's OK in this case and if it is, why?

Thanks!

Zhuinden commented 4 years ago

Well is there a second implementation of any of the UseCases? If not, then they don't need an interface.

RicardAparicio commented 4 years ago

Well is there a second implementation of any of the UseCases? If not, then they don't need an interface.

I understand that if there was more UseCase should be advisable to use some kind of common abstraction, but I am referring to the concept of dependency inversion principle between layers, which I can see between DOMAIN -> DATA but not in PRESENTATION -> DOMAIN.

Zhuinden commented 4 years ago

there was more UseCase should be advisable to use some kind of common abstraction

No, that'd just make independent UseCases be coupled together.

azisuazusa commented 4 years ago

but I am referring to the concept of dependency inversion principle between layers, which I can see between DOMAIN -> DATA but not in PRESENTATION -> DOMAIN.

Because Presentation is the outer layer and Domain is the inner layer the Presentation can access domain directly and no need to use the concept of dependency inversion principle. It's different with Domain -> Data, because data is the outer layer and the inner layer cannot access the outer layer directly.