图1：简化的Singleton模式
通过将图1中简化的模式示例与QuoteManager源代码进行比较，阐明了模式（通用问题-解决方案对）和模式应用程序（针对非常具体的问题的具体解决方案）之间的区别。模式级别的解决方案是多个类之间简单但极其顺畅的协作。模式中的通用协作专门适用于QuoteManager类，提供了用来控制报价应用程序中实例化的机制。显然，您可以稍微修改一下某种模式以满足局部的特定要求，所以同一种模式可以应用于无数个应用程序。
所编写的模式提供了一种记录简单且经过证实的机制的有效方法。模式是以特定格式编写的，这一点对于装载复杂思想的容器非常有用。这些模式在被记载和起名之前，就早已存在于开发人员的大脑及其代码中。
位于不同级别的模式
模式存在于多个不同的抽象级别中。考虑另一个示例（这次所处的抽象级别比源代码要高一级）：
您要设计一个基于Web的报价应用程序，其中包含大量业务和表示逻辑，这些逻辑反过来依赖大量平台软件组件来提供适当的执行环境。如何在高级别组织系统以使其在具有灵活、松耦合性的同时仍具有高内聚性？
此问题的解决方案之一涉及到按一系列层来组织系统，每层包含大致位于同一抽象级别的元素。随后，确定每一层中的依赖性，并确定采用严格还是宽松的分层策略。接着，决定是打算创建自定义的分层方案，还是采用以前由其他人记录的分层方案。在本例中，假设您决定使用众所周知的分层策略：表示、业务逻辑和数据访问各占一层。图2显示了分层方案的可能外观。
如果您总是按这种方式设计系统，说明您已经在不依赖于任何广义模式的情况下使用该模式。即便如此，您还可能因多种原因而希望了解支撑这种设计方法的模式。您可能迫切想知道为何经常以这种方式构建系统，或者可能在寻找更理想的方法来解决此模式不能完全解决的问题。使用层作为高级别组织方法是Layers（层）模式[Buschmann96][3]中描述的完善模式。图3显示了该模式的简化版本。
图3：简化的Layers模式 这个简单的应用程序组织策略有助于解决软件开发中面临的两个挑战：依存关系的管理和对可交换组件的需求。如果在构建应用程序时没有一个考虑周全的依存关系管理策略，会导致组件易损坏且不牢靠，从而导致对它们进行维护、扩展和替代时存在较大的困难，而且成本较高。Layers模式中的工作机制比Singleton中的工作机制更精细。对于Layers，首次协作是在设计时发生在类之间，这是由于分层组织将对更改源代码所带来的影响局部化，从而防止所做的更改贯穿到整个系统。第二次协作发生在运行时：某层中相对独立的组件变得可与其他组件交换，再一次使系统其余部分不受影响。
文章来源于领测软件测试网 https://www.ltesting.net/
