Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider avoid using base Use Case classes to avoid redundant code #60

Open
nivisi opened this issue Aug 1, 2022 · 0 comments
Open

Comments

@nivisi
Copy link
Contributor

nivisi commented Aug 1, 2022

The problem

The base use case classes like UseCase, StreamUseCase etc bring us only one benefit: they keep the use cases interface consistent. They force us to use the run method.

But we never operate with use cases using their base classes, e.g. you will never see

final UseCase<int, int> _calculateSomethingUseCase = injector<CalculateSomethingUsecase>();

It will always be:

final CalculateSomethingUseCase _calculateSomethingUseCase = injector<CalculateSomethingUseCase>();

But by using the base class we are forced to always have a single parameter in the run method. If we'd need two or more parameters, we would be forced to create an Input class. This is:

  • Not convenient
  • Expands our code base for no reason
// Bad
_myUseCase.run(MyInput(param1: 0, param2: 1));

// Good
_myUseCase.run(param1: 0, param2: 1);

The solution

Remove the inheritance from all the use cases. But then we will have to somehow ensure that all the use cases follow the same interface, having a public run method.

We could use this GitHub action to validate our pull requests to have the same use case structure. You can find an example here, it has a valid PR and an invalid PR.

But it is less convenient than a linter rule that could highlight the error in our IDE right when we code, not when we submit a PR.

So... We can create a linter rule that would validate our use case classes. custom_lint could be used for this purpose — but it needs investigation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant