（Reducing interface complexity）

我应用的一个基本的原则，当我想尽办法尝试浇筑需求到最初分割的对象“如果某物是丑陋的，在一个对象中隐藏它”。这就是Façade基本想要的效果。如果你有一个相当令人眼花缭乱的类的集合和交互，客户端并不需要真正的去看到它。那么你能创建一个有用的接口为客户端程序仅仅代表它们的需要。

Façade经常作为单态抽向工厂实现。当然，你能够容易的通过创建一个包含静态工厂方法的类获得这个效果。

//: facade:Facade.java

package facade;

import junit.framework.*;

class A { public A(int x) {} }

class B { public B(long x) {} }

class C { public C(double x) {} }

// Other classes that aren't exposed

// by the facade go here ...

public class Facade extends TestCase {

static A makeA(int x) { return new A(x); }

static B makeB(long x) { return new B(x); }

static C makeC(double x) { return new C(x); }

public void test() {

// The client programmer gets the objects

// by calling the static methods:

A a = Facade.makeA(1);

B b = Facade.makeB(1);

C c = Facade.makeC(1.0);

}

public static void main(String args[]) {

junit.textui.TestRunner.run(Facade.class);

}

} ///:~

《设计模式》中给的例子仅仅是一个使用其他类集的类。税务顾问是一个Façade在你和税码间，也是一个调停者在你和税务系统中。

Façade变量封包

对我来说，Façade有一个相当过程化的（非面向对象）感觉：你刚刚调用一些方法去获得对象。它与抽向工厂有什么实际的不同？在于Façade隐藏部分类库（和它们的交互）从客户端程序中，为那些类弄一个接口是更易于理解的。

然而，这正好是封包的优点在java中：类库以外，你仅仅能够创建和使用public类，所有的非public类仅仅在包中是可访问的。看起来Façade是Java中本身就有的优点。