Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Consider avoid using base Use Case classes to avoid redundant code

Open
  • Is something wrong?
#60 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Refactor
Clarity
Needs clarification
Activity status
Stale
Tech stack
dart
Domain
tooling

Research direction

Locate the base use case classes and their implementations, then review custom_lint and the linked validator examples. Completion would mean removing the inheritance without losing a consistent public run method and adding IDE-visible validation; no specific files or tests are named, so the scope needs investigation.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Dart
Stars
36
Forks
23
No merged PRs in 30d

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ml-opensource/flutter-template

All issues in ml-opensource/flutter-template

Similar issues

More Dart issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.