Where to instantiate object on clean architecture

Question

I am trying to wrap my head around clean architecture but I am struggling with the concept of how to avoid some dependencies.

I am implementing an API in Java for personal use, however I was trying to find some examples and came across this post: https://android.jlelse.eu/a-complete-idiots-guide-to-clean-architecture-2422f428946f

I've checked out the project and was checking the implementation until one thing bothered me and that was on how objects get instantiated.

The data layer and domain layer both seemed pretty devoid of problems. Data and models are separated and use Interfaces to talk to one another. As of my understanding the data layer and presentation are both on the "outer rings", i.e. on a same level, but I thought they should be completely independent. However, in this project, in the presentation layer all instantiation from all necessary objects happen. they get passed it to the domain layer or even data layer. (this happens on the TownshipListActivity.java if you are curious)

This seems to me to make little sense. You would end up coupling your view with your data layer. Yes I agree that the domain layer is still wild and free, but is this correct?

Else where should these be created? In my application I started to play with the idea of having a context object that creates them all but somehow this also feels fishy to me...

Answer 1

The author of that blog post is using the Model View Presenter (MVP) design approach for their application. I haven't done much with Android development, but if the UI doesn't offer dynamic binding of the UI elements to the model then MVP is the appropriate approach. As a result your View is tightly coupled to the model and there is no way around that.

There are other ways of doing UI work, but they do require API support for it, namely the ability to dynamically bind to your data. Angular and WPF both have dynamic binding of the view to the model and what they call a "View Model". Dynamic binding just declares that the UI is expecting an object with an exposed property by a certain name. It doesn't care if it's a foo or a bar. The pattern used there is called Model-View-ViewModel.

At some point, at least logically, your UI is going to have to be coupled with your model. Using an established approach to minimized the coupling to one layer if at all possible does help. The bottom line is that clean architecture is a good ideal to aspire to, but it is a case where perfect is the enemy of good--or sometimes even useful.

I recommend writing your application as clean as you can, but don't get hung up on being perfect with it. When you have your minimally viable product, look at what you've created and try to figure out if there is any way to clean things up. If you've hit an epiphany, try it out. Then see if the epiphany makes things better from the standpoint of being able to understand the code, debug the code, or modify the application.

You'll probably be able to take it further than your first stab, but you'll hit a point where chasing the ideal actually makes things worse.