5

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

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

我尝试了一种方法，但看起来不太好。我提到了一些示例代码，请帮助我如何将所有 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 可以是具有不同 In & Out 对象的不同 UseCase。

用例管理器实现：

public class UseCaseManagerImpl  implements UseCaseManager {

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

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

4

3 回答 3

3

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

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

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

于 2018-06-25T13:34:27.190 回答
1

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

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

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

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

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

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

这种设计模式的优点是：

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

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

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

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

于 2018-06-25T18:39:13.223 回答
0

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

单一责任意味着

改变应该有一个理由

参见单一职责原则

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

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

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

于 2021-05-12T06:50:44.027 回答