Facade模式的最佳實踐是什么？

Question

我的代碼工作正常，但我不知道我實現它的方式是否合適。 基本上，我想保持模式而不違反它。

代碼如下所示：

包模型（省略了setter / getters）：

public class CA {
    private Integer in;
    private Integer jn;
}

public class CB {
    private Integer kn;
    private Integer ln;
}

public class CC {    
    private static CC instancia;
    private CA a;
    private CB b;

    public static CC getInstancia() {
         if(instancia == null) {
             instancia = new CC();          
         }

         return instancia; 
    }
}

包裝業務：

class CCBusiness {

    static CC c = CC.getInstancia();

    void alter(Integer input) {
        c.getCA.setIn(input);
        Integer num = c.getCB.getLn();
    }
}

包裝外觀：

class FacadeOne {

void methodOne() {
    CCBusiness.alter(1);
    // And more xxBusiness.xx()
}

真正的代碼更復雜，但為了解釋我的疑慮，我認為這應該有效。

在一個外觀中，我調用了幾個Business對象，但是一個Business（在這種情況下，CC類中的一個）可以修改其他類的屬性（在這種情況下，CC中的屬性）是合適的嗎？ 我應該創建CABusiness和CBBusiness嗎？

因為，據我所知，一個企業不能稱之為另一個企業，所以第二個是參數化從FacadeOne接收對象（如果我創建CABusiness和CBBusiness）？

Answer 1

我認為一些澄清可能會對您有所幫助：外觀模式可以幫助您為幾個 隱藏在外立面后面隱藏到外部世界的類提供單一訪問點 。 通常這些類形成某種模塊或邏輯單元。

您正在努力的是立面背后的結構及其層次結構。 這很難在不了解整體情況的情況下進行分析，但從我掌握的信息中，最好有幾個你的Business類，可以從外觀單獨調用。 在Business對象之間創建交叉調用將有機會對代碼進行分類。

至於最佳實踐和技術，最簡單的方法是繪制一個類的草圖 ，這通常會澄清很多。 而且你已經在基於UML的文檔的一半了。 :-)

順便說一句，避免給你的類名稱，如CA，CB ......這就像命名變量a001，a002一樣......說起名字對可讀性做了很多！

Answer 2

通過使用Facade，您可以調用多個CxBusiness對象並將其操作集成到一個有意義的結果中。 這就是 Facade的目的，通過隱藏簡潔明了的操作后面的5個不同組件的交互來簡化與Business層的交互： methodOne 。

但是對於個人CxBusiness ，您希望避免彼此之間的交叉呼叫; 否則，您將最終得到一個復雜的依賴結構，可能會遇到循環引用。 保持每個CxBusiness作為每個Cx模型的唯一包裝，並且在與它們交互時減少不需要的副作用的數量。 這些之間的任何互動都將在立面上進行。

此外，通過使外觀依賴於接口而不是具體類來強制執行此模式： ICABusiness ， ICCBusiness等。然后，訪問任何模型的唯一方法應該是通過這些接口，顯然，您不應該有一個具體的CxBusiness ICxBusiness成員（沒有交叉依賴）。 一旦你實施了這些限制，實現本身就會流向更模塊化，耦合度更低的設計。