简洁架构中的单一职责原则，在一个用例管理器中聚合用例，它可以提供基于输入和输出对象的用例。

Question

我想在我的项目域层（清洁 MVVM）中实施单一职责原则。

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

我尝试了一种方法，但看起来不太好good.I我提到了一些示例代码，请帮助我如何将所有用例聚合到一个 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());
    }
}

UseCaseManager:

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

不同的输入输出对象可以是不同的用例。

UseCaseManagerImpl:

public class UseCaseManagerImpl  implements UseCaseManager {

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

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

Answer 1

我认为你正在重新发明abstract factory pattern。 Google 将为您提供有关该主题的大量内容...

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

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

Answer 2

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

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

您可以使用责任链 模式来实现。在这个设计模式中，你有一个工作运行ner（在你的例子中是UseCaseManagaer）和几个工作（UseCases）到运行，它们将按顺序运行直到其中一个returns一个输出。

您可以创建一个 RequestPipeline class 这将是一个 作业运行ner. 在 UseCaseManager 中，您实例化管道一次并使用您想要使用构建器模式添加的案例如下：

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

当有输入时，您会触发 RequestPipeline，它将运行添加到其中的所有作业，一个接一个地按顺序添加。如果一个 UseCase returns 为 null，作业运行ner 将调用下一个 UseCase，直到它找到一个可以管理输入并产生答案的 UseCase。

这种设计模式的优点是：

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

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

此处提供了一些Java代码供您检查是否满足您的用例。

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

Answer 3

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

单一职责意味着

There should be one reason to change

见The Single Responsibility Principle

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

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

我猜你的设计中还有另一个问题导致了你遇到的问题。但是因为我没有你的完整源代码，所以我不能给你任何进一步的建议。

简洁架构中的单一职责原则，在一个用例管理器中聚合用例，它可以提供基于输入和输出对象的用例。

Single Responsibility Principle in Clean Architecture, Aggregating UseCases in one UseCaseManager which can provide UseCase based on In & Out Object.

single-responsibility-principle

use-case

aggregation

clean-architecture

interactors