Design Patterns

Design pattern (Design pattern) is a set of classified and cataloged summary of code design experience that is used repeatedly, known to most people. The purpose of using design patterns is to reuse code, make the code easier to understand by others, and ensure code reliability. There is no doubt that design patterns are win-win for ourselves, others, and the system; design patterns make code writing truly engineering; design patterns are the cornerstone of software engineering, just like the structure of a building.

设计模式(英语 design pattern)是对面向对象设计中反复出现的问题的解决方案。这个术语是在1990年代由Erich Gamma等人从建筑设计领域引入到计算机科学中来的。这个术语的含义还存有争议。算法不是设计模式，因为算法致力于解决问题而非设计问题。设计模式通常描述了一组相互紧密作用的类与对象。设计模式提供一种讨论软件设计的公共语言，使得熟练设计者的设计经验可以被初学者和其他设计者掌握。设计模式还为软件重构提供了目标。

随着软件开发社群对设计模式的兴趣日益增长，已经出版了一些相关的专著，定期召开相应的研讨会，而且Ward Cunningham为此发明了WikiWiki用来交流设计模式的经验。

提示：本教程将通过 Java 实例，一步一步向您讲解设计模式的概念。所以你需要对Java知识有所了解。

表述格式

表述一个软件设计模式的格式根据作者的不同，划分和名称等都会有所不同。常用的GoF描述模式的格式大致分为以下这些部分：

• 模式名：每一个模式都有自己的名字，模式的名字使得我们可以讨论我们的设计。

• 问题：在面向对象的系统设计过程中反复出现的特定场合，它导致我们采用某个模式。

• 解决方案：上述问题的解决方案，其内容给出了设计的各个组成部分，它们之间的关系、职责划分和协作方式。

• 别名：一个模式可以有超过一个以上的名称。这些名称应该要在这一节注明。

• 动机：在哪种情况使用该模式，是本节提供的方案（包括问题与来龙去脉）的责任。

• 适用性：模式适用于哪些情况、模式的背景等等。

• 结构：这部分常用类图与交互图阐述此模式。

• 参与者：这部分提供一份本模式用到的类与对象清单，与它们在设计下扮演的角色。

• 合作：描述在此模式下，类与对象间的交互。

• 影响：采用该模式对软件系统其他部分的影响，比如对系统的扩充性、可移植性的影响。影响也包括负面的影响。这部分应描述使用本模式后的结果、副作用、与权衡(trade-off)

• 实现：这部分应描述实现该模式、该模式的部分方案、实现该模式的可能技术、或者建议实现模式的方法。

• 示例：简略描绘出如何以编程语言来使用模式。

• 已知应用：业界已知的实现示例。

• 相关模式：这部分包括其他相关模式，以及与其他类似模式的不同。

提示：我们的《设计模式》教程将帮助您学习所有设计模式知识。如果你有任何疑问，请前往PHP中文网社区提出你的问题，会有热心网友为你解答。

模式原则

大家都开始注意设计模式。那么，到底我们为什么要用设计模式呢？这么多设计模式为什么要怎么设计呢？

说实话，以前我还真没搞清楚。就是看大家一口一个"Design pattern"，心就有点发虚。于是就买了本"四人帮"的设计模式，结果看得似懂非懂:看得时候好像是懂了，过一会就忘了。可能是本人比较"愚钝"吧:))最近，有了点感悟。"独乐不如众乐"，与大家分享一下，还望指教! 

为什么要提倡"Design Pattern"呢？根本原因是为了代码复用，增加可维护性。

那么怎么才能实现代码复用呢？OO界有前辈的几个原则："开－闭"原则(Open Closed Principal)、里氏代换原则、合成复用原则。设计模式就是实现了这些原则，从而达到了代码复用、增加可维护性的目的。

• 开－闭原则

此原则是由"Bertrand Meyer"提出的。原文是："Software entities should be open for extension,but closed for modification"。就是说模块应对扩展开放，而对修改关闭。模块应尽量在不修改原(是"原"，指原来的代码)代码的情况下进行扩展。那么怎么扩展呢？我们看工厂模式"factory pattern":假设中关村有一个卖盗版盘和毛片的小子，我们给他设计一"光盘销售管理软件"。我们应该先设计一"光盘"接口。如图：【pre】______________|<>|| 光盘 ||_____________||+卖() || ||_____________|【/pre】而盗版盘和毛片是其子类。小子通过"DiscFactory"来管理这些光盘。代码为：

publicclassDiscFactory{
publicstatic光盘
getDisc(Stringname){
return(光盘)Class.forName(name).getInstance();
}
}

有人要买盗版盘，怎么实现呢？

public class 小子{ public static void main(String【】 args){ 光盘 d=DiscFactory.getDisc("盗版盘"); 光盘.卖(); } }

如果有一天，这小子良心发现了，开始卖正版软件。没关系，我们只要再创建一个"光盘"的子类"正版软件"就可以了。不需要修改原结构和代码。怎么样？对扩展开放，对修改关闭。"开-闭原则" 工厂模式是对具体产品进行扩展，有的项目可能需要更多的扩展性，要对这个"工厂"也进行扩展，那就成了"抽象工厂模式"。

• 里氏代换原则

里氏代换原则是由"Barbara Liskov"提出的。如果调用的是父类的话，那么换成子类也完全可以运行。比如： 光盘 d=new 盗版盘(); d.卖(); 要将"盗版盘"类改为"毛片"类，没问题，完全可以运行。Java编译程序会检查程序是否符合里氏代换原则。还记得java继承的一个原则吗？子类override方法的访问权限不能小于父类对应方法的访问权限。比如"光盘"中的方法"卖"访问权限是"public"，那么"盗版盘"和"毛片"中的"卖"方法就不能是protected或private，编译不能通过。为什么要这样呢？你想啊：如果"盗版盘"的"卖"方法是private。那么下面这段代码就不能执行了： 光盘 d=new 盗版盘(); d.卖();可以说：里氏代换原则是继承复用的一个基础。

• 合成复用原则

就是说要少用继承，多用合成关系来实现。我曾经这样写过程序：有几个类要与数据库打交道，就写了一个数据库操作的类，然后别的跟数据库打交道的类都继承这个。结果后来，我修改了数据库操作类的一个方法，各个类都需要改动。"牵一发而动全身"!面向对象是要把波动限制在尽量小的范围。

在Java中，应尽量针对Interface编程，而非实现类。这样，更换子类不会影响调用它方法的代码。要让各个类尽可能少的跟别人联系，"不要与陌生人说话"。这样，城门失火，才不至于殃及池鱼。扩展性和维护性才能提高

理解了这些原则，再看设计模式，只是在具体问题上怎么实现这些原则而已。张无忌学太极拳，忘记了所有招式，打倒了"玄幂二老"，所谓"心中无招"。设计模式可谓招数，如果先学通了各种模式，又忘掉了所有模式而随心所欲，可谓OO之最高境界。呵呵，搞笑，搞笑！（JR）

依赖倒转原则抽象不应该依赖与细节，细节应当依

• 依赖倒转原则

要针对接口编程，而不是针对实现编程。传递参数，或者在组合聚合关系中，尽量引用层次高的类。主要是在构造对象时可以动态的创建各种具体对象，当然如果一些具体类比较稳定，就不必在弄一个抽象类做它的父类，这样有画舌添足的感觉接口隔离原则定制服务的例子，每一

• 接口隔离原则

一种角色，不多不少，不干不该干的事，该干的事都要干 抽象类抽象类不会有实例

• 抽象类

类为子类继承，一般包含这个系的共同属性和方法。注意：好的继承关系中，只有叶节点是具体类，其他节点应该都是抽象类，也就是说具体类是不被继承的。将尽可能多的共同代码放到抽象类中。 7 迪米特法则最少知识原则。不要和陌生人说话。

本设计模式教程手册涵盖的内容

本设计模式教程涵盖所有设计模式介绍，包含了工厂模式（Factory Pattern）、抽象工厂模式（Abstract Factory Pattern）、单例模式（Singleton Pattern）、建造者模式（Builder Pattern）、原型模式（Prototype Pattern）等等。

提示：本教程的每一章都包含了很多Java实例，通过这些例子将帮助您更好地学习理解设计模式。