0

I'm trying to implement the clean architecture and I'm not sure to quite understand when to reuse interactors (use cases).

Considering that we have one use case such as get user information and we would like to reuse it in different location.

Screen A: product owners decided to display very few user information (pictures and name).

Screen B: product owners decided to display a lot more user information.

Shall we implement two separated use cases (interactors) or a single one?

What about if product owners decide that for Screen B we should not display user information if we don't have all the data retrieved from the API? It will definitely impact Screen A and it won't be valid/SOLID anymore.

  • 1
    Do you mean reusage of a use case diagram, reusage of the written text of a user story, or do you mean reusage of the code which creates the screen content? – Doc Brown Apr 3 at 19:16
  • I mean the reusage of the code and specifically the interactor in the case of implementing clean architecture. – romsi Apr 4 at 7:59
4

In my view a "use case" refers to a user, using the product. Not an internal implementation detail such as an internal API.

so you, presumably, have two use cases

  1. as a X I need to see partial data

  2. as a Y I need to see full data

Your 2 screens fulfill these requirements, one for each. How they work behind the scenes is up to you

Example "Use Case"

As a "System Admin" I need to view the full details of all "Customers" so that I can do fraud investigations.

Example "User Story" (Scrum terminology)

As a "System Admin" I need to view the full details of all "Customers" so that I can do fraud investigations.

and

As a "Customer" I need to see my name and address, so i can be sure they are correct.

BUT! importantly this is also a to do list item that you are going to pick up and implement, although it may be divided into smaller tasks.

Normally it would be one to one. But I might have multiple user stories per use case.

Example Screen. (Interactor is not a common term)

Web page with a big table of user details.

This might be the result of implementing the user story

Example service class that the screen uses

public class UserRepo
{
    public List<User> GetAllUsers();
    public List<UserLite> GetUsersWithMinimalDetails();
}

Now I can do the sysadmin screen with 'GetAllUsers' and the CustomerDetails screen with GetUsersWithMinimalDetails. Or I could use GetAllUsers for both.

I could have two screens, or one, or three. The use use and the user story dont tell me

  • Will you have the same approach with different device, such as iPhone and iPad? – romsi Apr 4 at 8:05
  • You could choose to combine them or not, eg. " as a user (with a small screen) I want an abbreviated view of X with the details on a second page, so that i can.. blah" – Ewan Apr 4 at 8:15
  • or simply "as an X I need to see all the details (via an appropriate display) regardless of screen size" – Ewan Apr 4 at 8:16
  • Having two distincts use cases will defer the responsibility of choosing between the two use cases regarding the screen on a class like a "coordinator". If we have only one Interactor, can it be the responsibility of the Interactor to provide the right amount of data? – romsi Apr 4 at 8:43
  • sorry, I don't understand that. The use case or cases describes how the user interacts with the app. So they have no direct affect on the implementation. You could fulfill all the use cases with one dynamic screen and an API which always returns all the data, or you might find it easier to make multiple screens and APIs. either way the use cases are the same. – Ewan Apr 4 at 9:04
0

You cannot really decide about code reusage when only looking at use case descriptions or user stories: this is typically the wrong level of abstraction. At the highest level, your description says

"get user information"

which gives the impression this is just two times the same use case. Going more into the details, you see there are differences in Screen A and B, which shows these are two similar use cases, but not exactly the same.

If you switch to the code level, it is often possible to find parts which can be reused, others which cannot. For some, it is probably not immediately clear if the reusage will create some unwanted coupling between screen A and B which might affect future changes.

This is a judgement call. Creating reusable components for certain uses cases is not easy. The idea should be to create components following the OCP. So they don't have to be touched in case requirements of one use cases change, and the coupling won't affect other uses cases.

  • You right about looking at use case descriptions is the wrong level of abstraction. What will your approach be? Is it correct to say that first start by having to separate components and then refactor it into one if they are similar? – romsi Apr 4 at 10:16
  • @romsi: depends on the kind (and size) of system you are building. It makes a large difference if you are building a system with 3 devs, 30 devs or 300 devs. Your overall development plan also matters - if screen A is required now, will B be required next week, next month or next year? – Doc Brown Apr 4 at 10:35
  • ... In a small team which has one code base under control, I would try to develop software for one use case using small, reasonable, testable components, and as soon as development for another use case starts, look if those components can be reused (maybe with some refactorings). Refactoring and reusage should go hand in hand. However, one has also to invest some thoughts into the risk induced by coupling, and if those risks are balanced by the benefits of reusage. – Doc Brown Apr 4 at 10:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.