这一部分描述了所选的模式是如何帮助解决问题的（请参阅表 1 中的简要介绍），并对每种决定因素的解决方法进行了总结。

某个产品线策略中对软件组件的未来重用

分层模式提供了支持某一产品线策略所必需的整个体系结构的结构，它将可重用和特定于平台的软件要素分离成不同的层。

使用包装外观模式封装操作系统代码、遗留代码和第三方代码，这提供了一条途径，可以利用适当的抽象将现有代码和新代码分离开来，抽象支持两组代码的重用。

使用组件配置器模式管理服务生命周期，利用中介支持位置透明性，这提供了一个在多种不同场景中部署服务的方法，并可支持重用。

客户机-服务器模式可在系统内建立多种清晰的角色，并支持创建各项服务，这些服务的角色和职责均经过清晰定义。它对服务的清晰性和内聚性，乃至总体的可重用性都有所贡献。

利用组件配置器模式可对服务生命周期进行抽象；利用中介、代理和调用程序，可对通信进行抽象；而使用独立模式，则可对横切关注点进行抽象。所有启用的服务均将重点放在业务逻辑上，这有助于创建可重用的资产。

经过良好定义的可发现接口（由显式接口模式提供支持）、封装上下文对象和查询功能使服务能专注于业务逻辑，因为关注的重点被放在接口公开的功能而不是实现的细节上。

封装上下文对象提供了一个将服务执行上下文和框架要素封装起来的方法。分离的上下文接口将上下文实现和上下文用户分离开来。这些模式的组合可以提供一致、分离的方法，用来访问执行上下文细节。

使用观察器以创建能为多个订阅者生成事件的可重用服务，而无需（或很少）依赖于其他服务，从而带来更多的重用机会。

在服务总线内准备的通用拦截器提供了一个有用的扩展点。使用模板方法实现中介模式的桥接角色，这种做法提供了一种可以在将来添加外部通信备用类型的机制。

在运行时对服务进行无缝（重新）部署

组件配置器提供了一套动态机制，用来管理服务生命周期和部署。它提供的方法可以用来随意分配服务，使它们在不同的进程中运行，并可快速移除导致崩溃或死锁的服务。在某些情况下，只需重新排列服务配置文件就能修复缺陷。它还允许创建特殊的配置文件以运行测试。

 

独立于部署模型的服务调用透明性

中介能提供位置透明性。由显式接口和查询提供的服务透明性，可以在服务和服务间的接口之间进行分离。

使用纯粹的抽象 C++ 显式接口类与真正的服务调用透明性是矛盾的，因为非 C++ 系统中的服务客户机需要备用的接口定义。

一个用来管理、测试和处理服务的通用方法

经过良好定义的分离接口是由显式接口引入的，它能创建用来管理和测试的通用接口，服务可以按照要求提供支持。

独立模式支持横切关注点，使之可以利用新代码和遗留代码，以不同的抽象级别跨越各种软件组件。

重用和保护现有软件组件

使用包装外观模式，将遗留代码模块间复杂的交互关系包装起来，提供更多的重用机会。它还在新代码和遗留代码之间提供一个保护层，以确保这两种类型的代码不致于对彼此造成不利影响。

显式接口还可以允许服务包含现有的软件组件，从而使软件组件的重用和保护成为可能。

通过提供独立对象以支持遗留组件所需的接口，可以更有效地使用遗留组件。

在资源有限的环境中的可接受性能

对代理和调用程序对象进行缓存，配合执行程序中的线程池，可以提高资源的使用效率。异步完成令牌支持线程池，它允许服务在等待异步响应时释放线程，并将其放回到池中。

利用显式接口引入经过良好定义的接口，虽然会付出打破执行封装的代价，但它提供的本地解析能确保实现快速有效的访问。

不幸的是，显式接口、代理、调用程序和组件配置器模式之间的交互，由于要依赖于 C++ RTTI，它们可能会对内存消耗和运行时性能造成不利影响。

延迟获取模式提供了一套快速有效的启动机制，它使服务得以延迟，直到必要时才启动服务。

独立于特定的计算平台

分层模式提供了支持平台独立性必需的基础体系结构的结构，它将可重用的代码和特定于平台的代码分离到不同的层。

使用包装外观模式可以定义纯粹的操作系统抽象，后者可针对特殊的操作系统加以实现，从而使服务和与服务相关的代码具有平台独立性。

使用纯粹的抽象 C++ 显式接口类与平台独立性是矛盾的，因为非 C++ 服务客户机需要备用的接口定义。