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（没有交叉依赖）。一旦你实施了这些限制，实现本身就会流向更模块化，耦合度更低的设计。

Facade模式的最佳实践是什么？

2 个答案: