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 。

我猜您的設計中還有另一個問題會導致您遇到的問題。 但由於我沒有你的完整源代碼，我不能給你任何進一步的建議。