外观模式的最佳实践是什么？

Question

我的代码可以工作，但我不知道我实现它的方式是否合适。基本上，我想在不违反模式的情况下保持这种模式。

代码如下所示：

包模型(省略了setters/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()
}

真正的代码更复杂，但为了解释我的怀疑，我认为这应该是可行的。

在一个外观中，我调用了几个业务对象，但是一个业务(在本例中是CC类的业务)可以修改来自其他类的属性(在本例中是CC内部的类)，这是合适的吗？我应该创建CABusiness和CBBusiness吗？

因为，据我所知，一个业务不能调用另一个业务，所以第二个业务需要参数化才能从FacadeOne接收对象(如果我创建了CABusiness和CBBusiness)？

Answer 1

通过拥有一个外观，您可以调用多个CxBusiness对象并将它们的操作集成到有意义的结果中。这就是外观的目的，通过隐藏5个不同组件的交互，简化与业务层的交互：methodOne。

但是，对于单个CxBusiness，您希望避免彼此之间的交叉调用；否则，您将得到一个可能会遇到循环引用的复杂依赖结构。将每个CxBusiness作为每个Cx模型的唯一包装器，在与它们交互时，您将减少不必要的副作用。它们之间的任何交互都将发生在正面。

此外，通过让外观依赖于接口而不是具体的类来强制执行此模式：ICABusiness、ICCBusiness等。那么，访问任何模型的唯一方法应该是通过这些接口，而且很明显，您不应该有一个带有ICxBusiness成员的具体CxBusiness (没有交叉依赖关系)。一旦您设置了这些限制，实现本身就会流向一个更模块化和更少耦合的设计。

Answer 2

我认为一些澄清可能会对您有所帮助: facade模式可以帮助您对几个类()拥有一个单独的访问点，这些类是外观后面的隐藏，因此隐藏在外部世界。通常，这些类形成某种模块或逻辑单元。

您正在努力解决的是正面及其层次结构后面的结构。在不了解整个情况下很难对此进行分析，但从我所掌握的信息来看，最好有几个您是您的业务类，这些类可以从外观单独调用。在Business之间创建交叉调用将有机会对您的代码进行修改。

至于最佳实践和技术，最简单的方法是绘制类的草图，这通常会澄清很多内容。而且您已经是基于UML文档的一半了。:-)

顺便说一句，不要给你的类起名字，比如CA，CB.就像命名变量a001，a002.说名字对可读性有很大帮助！