服务访问和配置模式
包装器外观（Wrapper Facade）设计模式把现有的非面向对象的API所提供的函数和数据，封装在更加简洁的、健壮的、可移植的、可维护的和内聚的面向对象的类接口里面。常常应用包装器外观“包装”更低层操作系统API来提高应用程序的可移植性。它也能减轻与使用低层API编程有关的偶发的复杂性。
组件配置器（Component Configurator）设计模式允许应用程序在不必修改，重新编译或者静态地重新链接的情况下，在运行时链接和解链它的组件实现。
截取器（Interceptor）体系结构模式允许透明地把服务加入框架中，并且当事件发生时，能自动地触发服务。因此，截取器为它自己的演化准备了一个框架，以适应在框架的最初开发期间未被配置甚至未知的服务。同时截取器也允许其他的应用程序把组件和服务与框架的实例集成起来。
扩展接口（Extension Interface）设计模式在开发人员扩展或修改现有组件的服务功能时，防止引起接口的“膨胀”和客户机代码的破坏。可以把多个扩展接口放在同一组件中。扩展接口既要处理组件和服务演化的难题，又要处理客户机的供应问题，这些客户机具有与角色有关的对组件功能的访问授权。
包装器外观（Wrapper Facade）
1.问题
1）简洁的代码常常比冗长的代码更健壮，因为它更易于开发和维护。
2）软件产品如果可移植或者很容易移植到不同的操作系统、编译器和硬件平台，容易取得较大的市场份额。
3）改进软件可维护性可以减少软件生命期的费用。
4）内聚的组件更容易学习、维护和增强。
2.解决方案
避免直接访问非面向对象的API。对于非面向对象的API中的每组相关函数和数据，为它们创建一个或多个包装器外观类，把这些函数和数据封装在面向对象的包装器外观所提供的更简洁的、健壮的、可移植的和可维护的方法中。
3.结构
函数是现有的非面向对象的API的构件。它们提供一种独立的服务或者机制，并管理作为参数传递或者通过全局变量访问的数据。
包装器外观是一个或多个面向对象的类的集合，这些类封装现有的函数和与它们相关联的数据。这些类导出一个内聚的抽象，由它提供特定类型的功能。每个类代表抽象中一个特定的角色。
4.实现
1）标识内聚的抽象和现有的低层API之间的关系。成熟的低层API包含定义许多内聚的抽象的函数和数据结构，并且清楚地映射到面向对象的类和方法中。
2）把内聚的函数组聚合进包装器外观类和方法。这个活动定义一个或者多个类抽象，把应用程序与低层数据表示。函数语法中的任意变量以及其他的实现细节隔开。可以把它分解为5个子活动。
2.1）创建内聚的类。我们为每组现有的非面向对象的API定义包装器外观，这些API与一个特殊的抽象相关。用于创建内聚的类的常用标准包括下列方面：
·把具有高度内聚性的函数和数据合并到单个类中，同时也最小化类之间不必要的耦合。
·标识出函数和数据底层中的常用和可变方面。函数和数据中可能的变化都应该被分解到类，由这些类把统一接口之隔离变化，从而增强可扩展性。
2.2）把多个函数合并到一种方法之中。除把现有的函数分组到类之外。把多个单独的函数合并到每个包装器外观类中更少的方法中也是有用的。
2.3）如果可能的话，自动化创建和销毁操作。
2.4）选择间接的级别。大多数包装器外观类只是把它们的方法调用转发给低层函数。如果包装器外观方法能被隐式地或者显式地内联，那么比起直接调用低层函数来，它不存在运行时的间接开销。
2.5）确定在哪里封装任何与平台有关的变化。包装器外观模式的一般使用是在应用程序代码中最小化与平台有关的变化。尽管包装器外观方法实现在不同的操作系统平台也许存在不同，但它们应提供一致的，与平台无关的接口。在与平台有关的变化存在的地方，可以通过条件编译或者分离目录来封装它。
3）考虑允许应用程序受控访问实现细节。将一部分的实现细节暴露给开发者，会降低可移植性并增加出错的可能。
4）开发一种错误处理机制，使用异常处理作为包装器外观类的错误处理机制有多个优点：
·它是可扩展的。
·它从正常处理中清楚地分解错误处理。错误处理信息既不被显式地传递给操作，应用程序也不会因未能检查函数返回值而偶然地忽略异常。
·它可以是类型安全的。
但是，用于包装器外观类的异常处理的使用存在几个缺陷：
·并不是所有的语言或者实现都提供异常处理。
·各种语言以不同的方法实现异常。
·当存在多个退出路径，那么资源管理会复杂化。
·甚至当不抛出异常时，低劣的异常处理实现也会增加时间或者空间开锁。
5）定义相关的帮助者类（可选的）
5.结论
优点：
1）具体的、内聚的和健壮的更高级面向对象的编程接口。
2）可移植性和可维护性。
3）模块性、可复用性和可配置性。
不足：
1）功能丧失。
2）性能降低。
3）编程语言和编译器的局限性。
