每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。
-- Christopher Alexander

设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相互通信的对象之间常见的组织关系。

GoF23 种设计模式

历史性著作《设计模式：可复用面向对象软件的基础》一书中描述了23种经典面向对象设计模式，创立了模式在软件设计中的地位。该书
四位作者被人们并称为Gang of Four （GoF），“四人组”，该书描述的23种经典设计模式又被人们称为GoF23 种设计模式。

由于《设计模式：可复用面向对象软件的基础》一书确定了设计模式的地位，人们通常所说的设计模式隐含地表示“面向对象设计模式”。
但这并不意味“设计模式”就等于“面向对象设计模式”，也不意味着GoF23种模式就表示了所有的“面向对象设计模式”。除了“面向对象设计模式”外，还有其他设计模式。除了GoF23 种设计模式外，还有更多的面向对象设计模式。

GoF23 种设计模式是学习面向对象设计模式的起点，而非终点；本培训课程的目标是让学员在建立在有效方法的基础上，掌握GoF23种设计模式。

设计模式与面向对象

面向对象设计模式解决的是“类与相互通信的对象之间的组织关系，包括它们的角色、职责、协作方式几个方面。

面向对象设计模式是“好的面向对象设计”，所谓“好的面向对象设计”是那些可以满足“应对变化，提高复用”的设计。

面向对象设计模式描述的是软件设计，因此它是独立于编程语言的，但是面向对象设计模式的最终实现仍然要使用面向对象编程语言来表达，本课程基于C#语言，但实际上它适用于支持.NET框架的所有.NET语言，如Visual Basic.NET、C++/CLI等。

面向对象设计模式不像算法技巧，可以照搬照用，它是建立在对“面向对象”纯熟、深入的理解的基础上的经验性认识。掌握面向对象设计模式的前提是首先掌握“面向对象”！

从编程语言直观了解面向对象

各种面向对象编程语言相互有别，但都能看到它们对面向对象三大机制的支持，即： “封装、继承、多态”

– 封装，隐藏内部实现
– 继承，复用现有代码
– 多态，改写对象行为

使用面向对象编程语言（如C#），可以推动程序员以面向对象的思维来思考软件设计结构，从而强化面向对象的编程范式。

C#是一门支持面向对象编程的优秀语言，包括：各种级别的封装支持；单实现继承+多接口实现；抽象方法与虚方法重写。

但OOPL并非面向对象的全部

通过面向对象编程语言（OOPL）认识到的面向对象，并不是面向对象的全部，甚至只是浅陋的面向对象。

OOPL的三大机制“封装、继承、多态” 可以表达面向对象的所有概念，但这三大机制本身并没有刻画出面向对象的核心精神。换言之，既可以用这三大机制做出“好的面向对象设计”，也可以用这三大机制 做出“差的面向对象设计”。不是使用了面向对象的语言（例如C#），就实现了面向对象的设计与开发！因此我们不能依赖编程语言的面向对象机制，来掌握面向对象。

OOPL没有回答面向对象的根本性问题——我们为什么要使用面向对象？我们应该怎样使用三大机制来实现“好的面向对象”？ 我们应该遵循什么样的面向对象原则？

任何一个严肃的面向对象程序员（例如C#程序员），都需要系统地学习面向对象的知识，单纯从编程语言上获得的面向对象知识，不能够胜任面向对象设计与开发。

从一个示例谈起

示例场景：

我们需要设计一个人事管理系统，其中的一个功能是对各种不同类型的员工，计算其当月的工资——不同类型的员工，拥有不同的薪金计算制度。

结构化做法

1.获得人事系统中所有可能的员工类型
2.根据不同的员工类型所对应的不同的薪金制度，计算其工资
enumEmployeeType
{
Engineer;
Sales;
Manager;
…
}
// 计算工资程序
if ( type == EmployeeType.Engineer)
{
……
}
else if (type == Employeetype.Sales)
{
……
}

面向对象设计

1.根据不同的员工类型设计不同的类，并使这些类继承自一个Employee抽象类，其中有一个抽象方法GetSalary。
2.在各个不同的员工类中，根据自己的薪金制度，重写（override）GetSalary方法。
abstract class Employee
{
…
public abstract int GetSalary();
}
class Engineer: Employee
{
…
public override int GetSalary()
{
…
}
}
class Sales: Employee
{
…
public override int GetSalary()
{
…
}
}
// 显示工资程序
Employee e = emFactory.GetEmployee(id);
MessageBox.Show( e.GetSalary());

示例场景：

现在需求改变了……随着客户公司业务规模的拓展，又出现了更多类型的员工，比如钟点工、计件工……等等，这对人事管理系统提出了挑战——原有的程序必须改变。

结构化做法

几乎所有涉及到员工类型的地方（当然包括“计算工资程序”）都需要做改变……这些代码都需要重新编译，重新部署…….

面向对象做法

只需要在新的文件里增添新的员工类，让其继承自Employee抽象类，并重写GetSalary()方法，然后在EmployeeFactory.GetEmployee方法中根据相关条件，产生新的员工类型就可以了。其他地方（显示工资程序、Engineer类、Sales类等）则不需要做任何改变。

重新认识面向对象

对于前面的例子，从宏观层面来看，面向对象的构建方式更能适应软件的变化，能将变化所带来的影响减为最小

从微观层面来看，面向对象的方式更强调各个类的“责任”，新增员工类型不会影响原来员工类型的实现代码——这更符合真实的世界，也
更能控制变化所影响的范围，毕竟Engineer类不应该为新增的“钟点工”来买单……

对象是什么？

– 从概念层面讲，对象是某种拥有责任的抽象。
– 从规格层面讲，对象是一系列可以被其他对象使用的公共接口。
– 从语言实现层面来看，对象封装了代码和数据。

有了这些认识之后，怎样才能设计“好的面向对象”？

– 遵循一定的面向对象设计原则
– 熟悉一些典型的面向对象设计模式

从设计原则到设计模式

针对接口编程，而不是针对实现编程

– 客户无需知道所使用对象的特定类型，只需要知道对象拥有客户所期望的接口。

优先使用对象组合，而不是类继承

– 类继承通常为“白箱复用”，对象组合通常为“黑箱复用”。继承在某种程度上破坏了封装性，子类父类耦合度高；而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。

封装变化点

– 使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合。

使用重构得到模式——设计模式的应用不宜先入为主，一上来就使用设计模式是对设计模式的最大误用。没有一步到位的设计模式。敏捷软件开发实践提倡的“Refactoring to Patterns ”是目前普遍公认的最好的使用设计模式的方法。

几条更具体的设计原则

单一职责原则（SRP）：

– 一个类应该仅有一个引起它变化的原因。

开放封闭原则（OCP）：

– 类模块应该是可扩展的，但是不可修改（对扩展开放，对更改封闭）

Liskov 替换原则（LSP）:
– 子类必须能够替换它们的基类

. 依赖倒置原则（DIP）：

– 高层模块不应该依赖于低层模块，二者都应该依赖于抽象。

– 抽象不应该依赖于实现细节，实现细节应该依赖于抽象。

接口隔离原则（ISP）：

– 不应该强迫客户程序依赖于它们不用的方法。

总结

设计模式描述了软件设计过程中某一类常见问题的一般性的解决方 案。面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相互通信的对象之间常见的组织关系。

深刻理解面向对象是学好设计模式的基础，掌握一定的面向对象设计原则才能把握面向对象设计模式的精髓，从而实现灵活运用设计模
式。

三大基本面向对象设计原则

– 针对接口编程，而不是针对实现编程
– 优先使用对象组合，而不是类继承
– 封装变化点

　　作为对象的创建模式[GOF95]， 单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。这个类称为单例类。

　　注：本文乃阎宏博士的《Java与模式》一书的第十五章。

　　引言

　　单例模式的要点

　　单例单例

　　显然单例模式的要点有三个；一是某各类只能有一个实例；二是它必须自行创建这个事例；三是它必须自行向整个系统提供这个实例。在下面的对象图中，有一个"单例对象"，而"客户甲"、"客户乙" 和"客户丙"是单例对象的三个客户对象。可以看到，所有的客户对象共享一个单例对象。而且从单例对象到自身的连接线可以看出，单例对象持有对自己的引用。



　　资源管理

　　一些资源管理器常常设计成单例模式。

　　在计算机系统中，需要管理的资源包括软件外部资源，譬如每台计算机可以有若干个打印机，但只能有一个Printer Spooler， 以避免两个打印作业同时输出到打印机中。每台计算机可以有若干传真卡，但是只应该有一个软件负责管理传真卡，以避免出现两份传真作业同时传到传真卡中的情况。每台计算机可以有若干通信端口，系统应当集中管理这些通信端口，以避免一个通信端口同时被两个请求同时调用。

　　需要管理的资源包括软件内部资源，譬如，大多数的软件都有一个（甚至多个）属性（properties）文件存放系统配置。这样的系统应当由一个对象来管理一个属性文件。

　　需要管理的软件内部资源也包括譬如负责记录网站来访人数的部件，记录软件系统内部事件、出错信息的部件，或是对系统的表现进行检查的部件等。这些部件都必须集中管理，不可政出多头。

　　这些资源管理器构件必须只有一个实例，这是其一；它们必须自行初始化，这是其二；允许整个系统访问自己这是其三。因此，它们都满足单例模式的条件，是单例模式的应用。

　　一个例子：Windows 回收站

　　Windows 9x 以后的视窗系统中都有一个回收站，下图就显示了Windows 2000 的回收站。



　　在整个视窗系统中，回收站只能有一个实例，整个系统都使用这个惟一的实例，而且回收站自行提供自己的实例。因此，回收站是单例模式的应用。

　　双重检查成例

　　在本章最后的附录里研究了双重检查成例。双重检查成例与单例模式并无直接的关系，但是由于很多C 语言设计师在单例模式里面使用双重检查成例，所以这一做法也被很多Java 设计师所模仿。因此，本书在附录里提醒读者，双重检查成例在Java 语言里并不能成立，详情请见本章的附录。

单例模式的结构

　　单例模式有以下的特点：

　　　.. 单例类只可有一个实例。

　　　.. 单例类必须自己创建自己这惟一的实例。

　　　.. 单例类必须给所有其他对象提供这一实例。

　　虽然单例模式中的单例类被限定只能有一个实例，但是单例模式和单例类可以很容易被推广到任意且有限多个实例的情况，这时候称它为多例模式（Multiton Pattern） 和多例类（Multiton Class），请见"专题：多例（Multiton ）模式与多语言支持"一章。单例类的简略类图如下所示。



　　由于Java 语言的特点，使得单例模式在Java 语言的实现上有自己的特点。这些特点主要表现在单例类如何将自己实例化上。

　　饿汉式单例类饿汉式单例类是在Java 语言里实现得最为简便的单例类，下面所示的类图描述了一个饿汉式单例类的典型实现。



　　从图中可以看出，此类已经自已将自己实例化。

　　代码清单1：饿汉式单例类

public class EagerSingleton 
{ 
private static final EagerSingleton m_instance = 
new EagerSingleton(); 
/** 
* 私有的默认构造子 
*/ 
private EagerSingleton() { } 
/** 
* 静态工厂方法 
*/ 
public static EagerSingleton getInstance() 
{

·224·Java 与模式 
return m_instance; 
}
} 

　　读者可以看出，在这个类被加载时，静态变量m_instance 会被初始化，此时类的私有构造子会被调用。这时候，单例类的惟一实例就被创建出来了。

　　Java 语言中单例类的一个最重要的特点是类的构造子是私有的，从而避免外界利用构造子直接创建出任意多的实例。值得指出的是，由于构造子是私有的，因此，此类不能被继承。

　　懒汉式单例类

　　与饿汉式单例类相同之处是，类的构造子是私有的。与饿汉式单例类不同的是，懒汉式单例类在第一次被引用时将自己实例化。如果加载器是静态的，那么在懒汉式单例类被加载时不会将自己实例化。如下图所示，类图中给出了一个典型的饿汉式单例类实现。



　　代码清单2：懒汉式单例类

package com.javapatterns.singleton.demos;
public class LazySingleton
{
private static LazySingleton
m_instance = null;
/**
* 私有的默认构造子，保证外界无法直接实例化
*/
private LazySingleton() { }
/**
* 静态工厂方法，返还此类的惟一实例
*/
synchronized public static LazySingleton
getInstance()
{
if (m_instance == null)
{
m_instance = new LazySingleton();
}
return m_instance;
}
}

　　读者可能会注意到，在上面给出懒汉式单例类实现里对静态工厂方法使用了同步化，以处理多线程环境。有些设计师在这里建议使用所谓的"双重检查成例"。必须指出的是，"双重检查成例"不可以在Java 语言中使用。不十分熟悉的读者，可以看看后面给出的小节。

　　同样，由于构造子是私有的，因此，此类不能被继承。饿汉式单例类在自己被加载时就将自己实例化。即便加载器是静态的，在饿汉式单例类被加载时仍会将自己实例化。单从资源利用效率角度来讲，这个比懒汉式单例类稍差些。

　　从速度和反应时间角度来讲，则比懒汉式单例类稍好些。然而，懒汉式单例类在实例化时， 必须处理好在多个线程同时首次引用此类时的访问限制问题，特别是当单例类作为资源控制器，在实例化时必然涉及资源初始化，而资源初始化很有可能耗费时间。这意味着出现多线程同时首次引用此类的机率变得较大。

　　饿汉式单例类可以在Java 语言内实现， 但不易在C++ 内实现，因为静态初始化在C++ 里没有固定的顺序，因而静态的m_instance 变量的初始化与类的加载顺序没有保证，可能会出问题。这就是为什么GoF 在提出单例类的概念时，举的例子是懒汉式的。他们的书影响之大，以致Java 语言中单例类的例子也大多是懒汉式的。实际上，本书认为饿汉式单例类更符合Java 语言本身的特点。

　　登记式单例类

　　登记式单例类是GoF 为了克服饿汉式单例类及懒汉式单例类均不可继承的缺点而设计的。本书把他们的例子翻译为Java 语言，并将它自己实例化的方式从懒汉式改为饿汉式。只是它的子类实例化的方式只能是懒汉式的， 这是无法改变的。如下图所示是登记式单例类的一个例子，图中的关系线表明，此类已将自己实例化。



　　代码清单3：登记式单例类

import java.util.HashMap;
public class RegSingleton
{
static private HashMap m_registry = new HashMap();
static
{
RegSingleton x = new RegSingleton();
m_registry.put( x.getClass().getName() ， x);
}
/**
* 保护的默认构造子
*/
protected RegSingleton() {}
/**
* 静态工厂方法，返还此类惟一的实例
*/
static public RegSingleton getInstance(String name)
{
if (name == null)
{
name = "com.javapatterns.singleton.demos.RegSingleton";
}
if (m_registry.get(name) == null)
{
try
{
m_registry.put( name，
Class.forName(name).newInstance() ) ;
}
catch(Exception e)
{
System.out.println("Error happened.");
}
}
return (RegSingleton) (m_registry.get(name) );
}
/**
* 一个示意性的商业方法
*/
public String about()
{
return "Hello， I am RegSingleton.";
}
}
　　它的子类RegSingletonChild 需要父类的帮助才能实例化。下图所示是登记式单例类子类的一个例子。图中的关系表明，此类是由父类将子类实例化的。



　　下面是子类的源代码。

　　代码清单4：登记式单例类的子类

import java.util.HashMap;
public class RegSingletonChild extends RegSingleton
{
public RegSingletonChild() {}
/**
* 静态工厂方法
*/
static public RegSingletonChild getInstance()
{
return (RegSingletonChild)
RegSingleton.getInstance(
"com.javapatterns.singleton.demos.RegSingletonChild" );
}
/**
* 一个示意性的商业方法
*/
public String about()
{
return "Hello， I am RegSingletonChild.";
}
}

　　在GoF 原始的例子中，并没有getInstance() 方法，这样得到子类必须调用的getInstance(String name)方法并传入子类的名字，因此很不方便。本章在登记式单例类子类的例子里，加入了getInstance() 方法，这样做的好处是RegSingletonChild 可以通过这个方法，返还自已的实例。而这样做的缺点是，由于数据类型不同，无法在RegSingleton 提供这样一个方法。由于子类必须允许父类以构造子调用产生实例，因此，它的构造子必须是公开的。这样一来，就等于允许了以这样方式产生实例而不在父类的登记中。这是登记式单例类的一个缺点。

　　GoF 曾指出，由于父类的实例必须存在才可能有子类的实例，这在有些情况下是一个浪费。这是登记式单例类的另一个缺点。