帶任務委託的責任鏈設計模式推薦

Question

我有一個接口，讓我們說2個方法，並有3個不同的實現。

public interface IFace { 
    public void method1(Param param1); 
    public void method2(Param param2); 
} 

public class A implements IFace { 
    public void method1(Param param1){} 
    public void method2(Param param2){} 
} 

public class B implements IFace { 
    public void method1(Param param1){} 
    public void method2(Param param2){} 
} 

public class C implements IFace { 
    public void method1(Param param1){} 
    public void method2(Param param2){} 
} 

現在我有一個要求，因爲每隻有這兩種方法中的一種，需要改進和有一些先決條件按我決定調用特定的實現和模式是，我可能有辦法逐個完成這些實現。這似乎像一個完美的適合責任鏈，我創建了一個這樣的：

public interface IChain { 
    public void method1(Param param1); 
    public void setNextChain(IChain iChain); 
} 

public class AA implements IChain { 
    private IChain chain; 

    private IFace a; 

    public void method1(Param param1){ 
     if (thisConditionIsSatisfied(param1)) { 
      a.method1(param1); 
     } else { 
      chain.method1(); 
     } 
    } 

    public void setNextChain(IChain chain){ 
     this.chain = chain 
    } 

    public void setA(IFace a) { 
     this.a = a; 
    } 
} 

public class BB implements IChain { 
    private IChain chain; 

    private IFace b; 

    public void method1(Param param1){ 
     if (thisConditionIsSatisfied(param1)) { 
      b.method1(param1); 
     } else { 
      chain.method1(); 
     } 
    } 

    public void setNextChain(IChain chain){ 
     this.chain = chain 
    } 

    public void setA(IFace b) { 
     this.b = b; 
    } 
} 

public class CC implements IChain { 
    private IChain chain; 

    public void method1(Param param1){ 
     if (thisConditionIsSatisfied(param1)) { 
      //process it here 
     } else { 
      throw new RuntimeException("Couldn't process request.") 
     } 
    } 

    public void setNextChain(IChain chain){ 
     this.chain = chain 
    } 

} 

正如你所看到的，CC不委託給其實施IFACE，是一個完全新的實現C類。

這是我顯示非常小的一部分，但問題實際上是我在條件評估，異常處理方面看到了很多重複的相同，調用正確實施的接口等

儘管這比嘗試擴展現有接口要好得多，但我想知道是否有任何建議使它在未來的可擴展性或OOPS模式方面更好。

Answer 1

我不這麼認爲。雖然看起來好像可以通過更少的重複來實現更好的設計，但它似乎並不存在。你的解決方案雖然很好，但我認爲這可能是最好的解決方法。

Answer 2

我覺得這不是一個軟件工程問題，而是一個設計相關的問題。我的答案如下。

這整體遵循責任鏈（COR）設計模式（除CC類違規外）。在COR中，所有具體的處理程序（AA，BB，CC）都應該是Abstract Handler類型（最好將它作爲常用/默認處理程序代碼的地方）綁定在一個鏈中。在你的實施CC中違反了這個合同，並沒有把機會傳遞給下一個處理程序。如果在N個處理程序的動態鏈中，如果CC是頭，則只處理CC類型的請求。而不是拋出異常CC可以調用super.handle（）並委託給後繼者（如下面的代碼）。作爲您的主要觀點，重複代碼來自合同，將其委託給後繼者（如果處理程序無法處理，委託給後繼者（如果存在的話））此代碼可以放在抽象處理程序中，如super.handle所示）。後繼者的實例也與抽象處理程序保持一致。

每個處理程序在handle（）方法中執行的操作都與COR相關的代碼無關。從抽象處理程序擴展到只有每個具體處理程序應該像誠實處理程序一樣。

public class AbsChain implements IChain { 
    private IChain successor; // as each handler has it 
    @Override 
    public void method1(Param param1) { 
     if (getSuccessor() != null) { 
      getSuccessor().method1(param1); 
     } else { 
      // Control comes here for totally unhandled request 
     } 
    } 
} 

public class AA extends AbsChain { 
    private IFace a; 

    public void method1(Param param1){ 
     // Handle if you can 
     if (thisConditionIsSatisfied(param1)) { 
      a.method1(param1); 
     } else { 
      //else allow next one to try (default behavior) 
      super.handleRequest(param1); 
     } 
    } 
} 

public class CC implements IChain { 

    public void method1(Param param1){ 
     if (thisConditionIsSatisfied(param1)) { 
      //process it here 
     } else { 
      //throwing Ex here breaks the chain 
      super.handleRequest(param1); // keep passing it 
     } 
    } 
}