Clean Architecture 中的单一职责原则，将 UseCase 聚合在一个 UseCaseManager 中，可以提供基于 In & Out 对象的 UseCase。

Question

我想在我的项目领域层（Clean MVVM）中实现单一职责原则。

我有大约。 200 个不同的用例管理起来非常忙碌。 现在我正在考虑创建一个 UseCaseManager，它可以根据输入和输出对象为我提供所需的用例。

我尝试了一种方法，但看起来不太好。我提到了一些示例代码，请帮助我如何将所有 UseCases 聚合到一个 UseCaseManager。

用例 1：

public class ActualUseCase1 extends AsyncUseCase<Object3,Object4> {

    public ActualUseCase1(SchedulerProvider schedulerProvider) {
        super(schedulerProvider);
    }

    @Override
    public Flowable<Object4> buildUseCaseFlowable(Object3 input) {
        return Flowable.just(new Object4());
    }
}

用例2：

public class ActualUseCase2 extends AsyncUseCase<Object1, Object2> {

    public ActualUseCase2(SchedulerProvider schedulerProvider) {
        super(schedulerProvider);
    }

    @Override
    public Flowable<Object2> buildUseCaseFlowable(Object1 input) {
        return Flowable.just(new Object2());
    }
}

用例管理器：

public interface UseCaseManager<In, Out> {
    <T> T getUseCase(In input, Out output);
}

T 可以是具有不同输入和输出对象的不同用例。

用例管理器Impl：

public class UseCaseManagerImpl  implements UseCaseManager {

    @Override
    public Object getUseCase(Object object1, Object object2) {
        return null;
    }
}

现在这是主要问题，我无法理解。 我如何实现 getUseCase 方法。

Answer 1

我认为您正在重新发明抽象工厂模式。 Google 会为您提供有关该主题的大量内容...

棘手的一点是你如何决定实例化和返回哪个子类型； 这可以像 switch 语句一样简单，也可以涉及查找表等。关键是将该逻辑隔离到一个地方，您可以在那里对其进行单元测试。

一个更大的问题是 - 你如何最终得到 200 个子类？

Answer 2

好的，我在这里得到一个想法，即您想要一种系统，其中对于给定的输入，您可以获得一些输出。 您可以有 200 个这样的输入，其中 200 个相应的输出是可能的。 而且您想让所有这些都易于管理。

我将尝试解释我想到的解决方案。 我是 Java 的初学者，因此无法生成很多代码。

您可以使用责任链模式来实现这一点。 在此设计模式中，您有一个作业运行程序（在您的案例中为 UseCaseManagaer）和多个要运行的作业（UseCases），它们将按顺序运行，直到其中一个返回输出。

您可以创建一个 RequestPipeline 类，它将作为作业运行程序。 在 UseCaseManager 中，您将管道实例化一次，并使用 Builder Pattern 添加要添加的所有用例，如下所示：

RequestPipeline.add(new UseCase1())
RequestPipeline.add(new UseCase2())...

当输入进来时，您会触发 RequestPipeline，它将依次运行添加到其中的所有作业。 如果 UseCase 返回 null，则作业运行器将调用行中的下一个 UseCase，直到找到可以管理输入并产生答案的 UseCase。

这种设计模式的优点是：

1. 抽象：RequestPipeline 负责在线运行作业，但对它正在运行的作业一无所知。 另一方面，用例只知道处理它自己的用例。 它本身就是一个单元。 因此，单一职责原则得到满足，因为两者都是相互独立的，并且在我们以后有类似的设计要求时都可以重用。
2. 易于扩展：如果您必须添加 10 个其他用例，您可以轻松地将它们添加到 RequestPipeline 中，您就完成了。
3. 没有 switch case 和 if-else 。 这本身就是一个巨大的成就。 正是因为这个原因，我喜欢责任链。
4. 声明式编程：我们简单的声明一下，我们需要做的，离开详细介绍了如何这样做是为了在独立的单元。 新的开发人员很容易理解代码的设计。
5. 更多控制：RequestPipeline 能够动态决定在运行时运行的作业。

参考： https : //www.google.co.in/amp/s/www.geeksforgeeks.org/chain-responsibility-design-pattern/amp/

这里提供了一些 Java 代码供您检查，如果它满足您的用例。

希望这可以帮助。 如果您有任何疑问，请在评论部分告诉我。

Answer 3

你要做的不是单一的责任，而是相反的。

单一责任意味着

应该有一个改变的理由

参见单一职责原则

您尝试实现的UseCaseManager将处理您所有的 200 个用例。 因此，只要用例发生变化，它就会发生变化。” - 这是混合关注点，而不是将它们分开。

通常用例由控制器调用，通常控制器也有一个单一的职责。 因此控制器知道它必须调用哪个用例。 因此，我认为不需要UseCaseManager 。

我猜您的设计中还有另一个问题会导致您遇到的问题。 但由于我没有你的完整源代码，我不能给你任何进一步的建议。