清洁架构中的单一责任原则，将UseCase聚合在一个UseCaseManager中，它可以提供基于In的UseCase

Question

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

我有大约200个不同的用例，这些用例正忙于管理。现在我正在考虑创建一个UseCaseManager，它可以根据输入为我提供所需的用例

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

UseCase2：

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);
}

在不同的情况下，T可以是不同的用例

UseCaseManagerImpl：

public class UseCaseManagerImpl  implements UseCaseManager {

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

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

Answer 1

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

单一责任意味着

应该有一个改变的理由

参见单一责任原则

您尝试实现的UseCaseManager将处理您的200个用例。因此，只要用例发生变化，它就会发生变化。“-这是各种担忧的混合，而不是将它们分开。

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

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

Answer 2

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

我会尽力解释我想到的解决办法。我是Java初学者，因此无法生成太多代码。

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

您可以创建一个RequestPipeline类，该类将作为作业运行器。在UseCaseManager中，您可以使用如下构建器模式实例化管道一次以及所有要添加的用例：

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

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

这种设计模式的优点是：

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

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

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

希望这能有所帮助。如果你有任何疑问，请在评论区告诉我。

Answer 3

我认为你在重新发明抽象的工厂模式。谷歌将为你提供大量关于这个主题的内容...

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

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