JAVA设计模式之外观(Facade)模式

        理想状态下，面向对象系统应该是将其他可复用的工具类中的行为组织在一起的最小的类。工具包或子系统的开发通常会将设计良好的类组织为包，而不是提供应用程序。java类库中的包通常可以当做工具包，以保证我们能够随意的开发各种特定领域的应用程序。

       伴随工具包复用性而来的问题是；面向对象子系统种类的多样性可能导致选择太多，以至于希望使用该工具包的开发人员变得茫然失措，诸如Eclipse这样的集成开发环境，可以将开发人员从包的错综复杂中解脱出来，然而，IDE有时却产生大量的开发人员不需要的代码。

简化工具包的另一种途径是使用外观（facade）模式，只需少量代码，就能够提供典型的、无修饰用法的类库中的类。一个外观就是一个类，它包含的功能介于工具包与完整的应用程序之间，为工具包或子系统的类提供了简单的用法。

外观模式的意图是为子系统提供一个接口，便于它的使用。

外观类、工具类、示例类

外观类可能全是静态方法，示例类用于展示如何使用类或子系统。

javal类库中很少使用外观类。

  1.作为java开发者，通常要求对库中的工具做整体的了解。外观模式可能会限制这种运用系统的方式。他可能会分散开发人员的注意力，并对类库提供的功能产生误解。

2.外观类介于丰富的工具包与特定的应用程序之间。为了创建外观类，需要了解它所支持 的应用程序类型。然而java类库的用户如此之多，这种预先的支持是不可能的。

外观模式常见于一些常规的应用程序的开发。如果根据关注点将代码分解为不同的类，就可以提取一个类，他的主要职责是为子系统提供便捷的访问方式，从而完成对系统的重构。

小结：

整体而言，应该对子系统中的类进行重构，直到每个类都有一个明确的目的。这可以使你的代码更容易维护，但也可能让使用该子系统的用户变得无所适从。为了让调用这些代码的开发人员使用方便，可以为子系统提供实例程序或者外观类。通常，示例程序可以独立运行，却无法重用，仅用于演示子系统的方法。外观类则是可配置、可重用的类，提供了高层次的接口，使得子系统的使用更加方便。