Clean architecture UseCases vs Controller with functions

Question

I just started reading about clean architecture and I'm confused on the definitions of usecase implementations.

Consider a controller class having set of functions that accepts T and returns R after executing some logic

interface IController {
   fun usecase1(param:T) : R 
   fun usecase2(param:T) : R
}

now I can execute the use cases with the IController instance.

Another way is to define each usecases as a class and inject in other objects which requires the functionality.

class UseCase1 {
    fun execute(param:T):R {}
}

class UseCase2 {
    fun execute(param:T):R {}
}

what are the advantages/disadvantages between having usecases as separate units versus having it as functions of some class?

IMO, separate units add contruction and Injection overhead whereas other approach suffers 'inheritance problems over composition'. Which is the right way to go ?

Answer 1

According to Interface segregation principle, it is better to have separate use-case interfaces for each case. It allows you abstract use-case implementation in some way. And you can split or divide use-case's implementation independently of Controller layer.

I would deferentially recommend splitting each use case to separate class. Because when you modify one of them you will be 100% sure that you do not brake another one. But if you have plenty of use-cases, and they are small, in this case, it makes sense to group it to files. But I think high-order functions fit better than bunch of functions in a class.

It is make sense to create a class when it has state and behavior, but if you create class for use-cases it will be stateless and methods will be hardly closely related.

But what really important, according to clean architecture, it is separating layers. It is not important how to organize storing use-cases, but it is very important to have possibility to change decision later independently of another layers.

Answer 2

what are the advantages/disadvantages between having usecases as separate units versus having it as functions of some class?

If you put everything in the controller you will violate the single responsibility principle. The controller code will change of different reasons than the use case code.

E.g. The controller takes input from the user and create output for the user, often with the help of a presenter. This means that it reads input from view models and updates view models. The view models belong to the UI and will change because of UI reasons.

The use cases must not depend on the UI if you are implementing the clean architecture and they will change of different reasons than the UI. The use cases are UI agnostic. This will also make them easier to test and they can be easier re-used with other UIs.

Consider a controller class having set of functions that accepts T and returns R after executing some logic

Keep in mind that the parameter and return types of the controllers are not the same as the types of the use cases.

Your controller might use types that are made for json serialisation and deserialisation. That is a transport issue. The use cases don't care about the transport. The way the data is transported is a detail. The web is a detail. If you use the same types for controllers and use cases you will create a dependency between them.

Answer 3

Clean Architecture is one which has less coupling between it's layers. Now when we try to apply the clean architecture over a web application like Google Photos it could have several layers like,

1. UI layer (the one which is perceived by the user)
2. The routing layer, which could route the URL to the right class file
3. There could be several adapter layers based on the use cases

4. The persistence layer which again can be subcategorized to,

   4.1. Meta data persistence (Ex; Postgress, MySQL)

   4.2. Content persistence (Ex; Hadoop)

How use cases come into picture here?

Use case is one which describes user interaction over a system. This can be as simple as validating against wrong password during authentication (or) providing options to apply filter over a picture. Implementing an use case could end in a method or it could possibly spawn between multiple classes and files.

Clean Architecture is a kind of guideline which insists us to have loose coupling over the layers so that replacing one layer with another should be easy with very minimal change.