Cleaner Swift Architecture

I would say that Software developers and artists have some things in common. Artists make art, we make Software. We are also artists in a kind of way

Palmeral de las sorpresas — Pier one — Málaga

Few days ago I was talking to a friend about how we were dealing with the architecture in the iOS project. I told him that we were using Clean Swift with the VIP lifecycle (View — Interactor — Presenter). I showed him a well explained example from Hackernoon and he actually liked it. However, we were talking about the concept of Clean architecture and we reached out some concepts that are not clear enough for new software developers that want to implement this architecture.

Worker should not be a place to request all use case of a scene

We could think, basing on the flow scheme that Worker is the place where we should implement functions to ask our API Manager to fetch the data (API calls or local DB fetching) but actually this is not a good solution for a Clean Architecture. In many cases, the ViewController shows more than one simple use case to the user. In fact, is very common to find a screen where user can get/add/edit/delete different types of data at the same time (Show a profile and recent posts *). because of this, if we used the Worker to handle different use cases for different type of data, we would be creating a non-reusable massive piece of shitty code, and it smells.

Thus, Worker should be a runway to our use cases, and it is inside these use cases where we could implement our functions (keeping in mind that SRP and all SOLID patterns should be applied to these use cases). Knowing this, we could move from this worker:

Worker for show profile and posts

As you see, if we wanted to use MassiveWorker.swift in other situation, we would have to include also the logic for posts. Also, image that in the future we add another use case to the same scene, the MassiveWorker.swift would also have to adapt itself to this new use case. A better solution would be to create two Worker file, one for each type of data so we would create UserWorker.swift and PostWorker.swift:

Now, we are able to use these Workers separately, we only need to add them to any Interactor. And in our example, we would have two Workers in the Interactor:

With this approach we give Worker the responsibility of manage one type of data so that we can reuse it in another scene that show user data without importing the posts business logic. We could improve it a bit more by separating it for each use case, of course, but at least we have cleaned our architecture a bit more. Now it’s your turn to improve it and continue programming always with the best practices. And remember:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live — John F. Woods

References:

Introducing Clean Swift Architecture (VIP)

Authors: Jaime Suárez, Francisco Navarro