软件架构的设计模式

软件架构设计模式

随着面向对象技术的发展和广泛应用，设计模式不再是一个新兴的名词，它已逐步成为系统架构人员、设计人员、分析人员以及程序开发人员所需掌握的基本技能之一。设计模式已广泛应用于面向对象的设计和开发，成为面向对象领域的一个重要组成部分。设计模式通常可分为三类：创建型模式、结构型模式和行为型模式。

1.创建型模式概述

创建型模式(Creational Pattern)对类的实例化过程及对象的创建过程进行了抽象，能够使软件模块做到与对象的创建和组织无关。创建型模式隐藏了对象的创建细节，通过隐藏对象如何被创建和组合在一起达到使整个系统独立的目的。在掌握创建型模式时，需要回答以下三个问题：创建什么(What)、由谁创建(Who)和何时创建(When)。创建型模式主要包括简单工厂模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式、单例模式。以下介绍其中使用频率较高的几种模式，包括简单工厂模式、工厂方法模式、抽象工厂模式、单例模式。 1.1 简单工厂模式

简单工厂模式(Simple Fatory Pattern)，又称静态工厂方法模式(Static Factoty Method Pattern)，属于类创建型模式。在简单工厂模式中，定义一个类，可以根据参数的不同返回不同的类的实例，这些类具有公共的父类和一些公共的方法。简单工厂模式不属于GoF设计模式，它是最简单的工厂模式。简单工厂模式专门定义一个类来负责创建其他类的实例，这个类称为工厂类，被创建的实例通常都具有共同的父类。

在简单工厂模式中，工厂类包含必要的判断逻辑，决定在什么时候创建哪一个产品类实例，客户端可以免除直接创建产品对象的责任，而仅仅“消费”产品，简单工厂模式通过这种方式实现了对责任的划分。但是由于工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响；同时系统扩展较为困难，一旦添加新产品就不得不修改工厂逻辑，违反了开闭原则，并造成工厂逻辑过于复杂。

正因为简单工厂模式存在种种问题，一般只将它作为学习其他工厂模式的入门，当然在一些并不复杂的环境下也可以直接使用简单工厂模式。 1.2 工厂方法模式

工厂方法模式(Factory Method Pattern)也称为工厂模式，又称为虚拟构造器(Virtual Constructor)模式或多态模式，属于类创建型模式。在工厂方法模式中，父类负责定义创建对象的公共接口，而子类则负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成，即由子类来决定究竟应该实例化(创建)哪一个类。

在工厂方法模式中，工厂方法用来创建客户所需要的产品，同时还向客户隐藏了哪种具体产品将被实例化这一细节。工厂方法模式的核心是抽象工厂类，各种具体工厂类继承抽象工厂类并实现在抽象工厂类中定义的工厂方法，从而使得客户只需要关心抽象产品和抽象工厂，完全不用理会返回的是哪一种具体产品，也不用关心它是如何被具体工厂创建的。在系统加入新产品时，无须修改抽象工厂和抽象产品提供的接口，无须修改客户端，也无须修改其他具体工厂和具体产品，而只要添加一个具体工厂和具体产品即可，这样，系统的可扩展性也就变得非常好，符合开闭原则。但是在添加新产品时，需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，难免会增加系统类的个数，增加系统的开销。

在以下情况中可以考虑使用工厂方法模式：1) 当客户程序不需要知道使用对象的创建过程；2) 客户程序使用的对象存在变动的可能，或者根本就不知道使用哪一个具体的对象。 1.3 抽象工厂模式

抽象工厂模式(Abstract Factory Pattern)是所有形式的工厂模式中最为抽象和最具一般性的一种形态。抽象工厂模式提供了一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，属于对象创建型模式。抽象工厂模式包含如下角色：抽象工厂、具体工厂、抽象产品、具体产品。

抽象工厂模式隔离了具体类的生成，使得客户并不需要知道什么被创建。由于这种隔离，更换一个具体工厂就变得相对容易。所有的具体工厂都实现了抽象工厂中定义的那些公共接口，因此只需改变具体工厂的实例，就可以在某种程度上改变整个软件系统的行为。另外，应用抽象工厂模式可以实现高内聚低耦合的设计目的，因此抽象工厂模式得到了广泛的应用；当一个产品族中的多个对象被设计成一起工作时，它能够保证客户端始终只使用同一个产品族中的对象。这对一些需要根据当前环境来决定其行为的软件系统来说，是一种非常实用的设计模式；增加新的具体工厂和产品族很方便，无须修改已有系统，符合开闭原则。但是抽象工厂模式也存在一些缺点，在添加新的产品对象时，难以扩展抽象工厂来生产新种类的产品，这是因为在抽象工厂角色中规定了所有可能被创建的产品集合，要支持新种类的产品就意味着要对该接口进行扩展，而这将涉及到对抽象工厂角色及其所有子类的修改，显然会带来较大的不便；开闭原则的倾斜性(增加新的工厂和产品族容易，增加新的产品等级结构麻烦)。

以下情况可以考虑使用抽象工厂模式：1) 一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节；2) 系统中有多于一个的产品族，而每次只使用其中某一个产品族；3)属于同一个产品族的产品将在一起使用，这一约束必须在系统的设计中体现出来。4)系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于具体实现。例如在Java语言的AWT(抽象窗口工具包)中就使用了抽象工厂模式来实现在不同的操作系统中应用程序呈现与所在操作系统一致的外观界面。 1.4 单例模式

单例模式(Singleton Pattern)确保某一个类只有一个实例，而且向这个系统提供这个实例。单例模式的三个要点：某个类只能有一个实例；它必须自行创建这个实例；必须自行向这个系统提供这个实例。单例模式依据实例化时机的不同，分为两种模型：饿汉式单例和懒汉式单例。

单例模式也是一种比较常见的设计模式，它有三个方面的作用：1）控制资源的使用，通过线程同步来控制资源的并发访问；2）控制实例产生的数量，达到节约资

源的目的。3）作为通信媒介使用，也就是数据共享，它可以在不建立直接关联的条件下，让多个不相关的两个线程或者进程之间实现通信。

当系统要求一个类只有一个实例时可使用单例模式，单例模式为系统提供了唯一实例的访问，并且可以对单例模式进行扩展获得可变数目的实例，即多例模式。

2.结构型模式概述

结构型模式(Structural Pattern)描述如何将类或者对象结合在一起形成更大

的结构。结构型模式可以描述两种不同的东西：类与类的实例(即对象)。结构型模式可以分为类结构型模式和对象结构型模式。结构型模式包括适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和代理模式7种，以下只介绍适配器模式、组合模式、外观模式和代理模式。 2.1适配器模式

适配器模式(Adapter Pattern)将一个接口转换成客户希望的另一个接口，从而使接口不兼容的那些类可以一起工作，其别名为包装器(Wrapper)。适配器模式可以作为类结构型模式，也可以作为对象结构型模式。

适配器模式具有如下优点：1) 将目标类和适配者类解耦，通过引入一个适配器类来重用现有的适配者类，而无须修改原有代码;2) 增加了类的透明性和复用性，将具体的实现封装在适配者类中，对于客户端类来说是透明的，而且提高了适配者的复用性; 3) 灵活性和扩展性都非常好，通过使用配置文件，可以很方便地更换适配器，也可以在不修改原有代码的基础上增加新的适配器类，完全符合开闭原则。同时适配器也有如下缺点：1) 对于Java、C#等不支持多重继承的语言，一次最多只能适配一个适配者类，而且目标抽象类只能为抽象类，不能为具体类，其使用有一定的局限性，不能将一个适配者类和它的子类都适配到目标接口; 2)与类适配器模式相比，要想置换适配者类的方法就不容易。如果一定要置换掉适配者类的一个或多个方法，就只好先做一个适配者类的子类，将适配者类的方法置换掉，然后再把适配者类的子类当做真正的适配者进行适配，实现过程较为复杂。

适配器模式适用环境：1) 系统需要使用现有的类，而这些类的接口不符合系统的需要; 2) 想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的