디자인 패턴

디자인 패턴(Design Pattern)은 대부분의 사람들에게 알려져 있는, 반복적으로 사용되는 코드 디자인 경험을 분류하고 정리한 집합입니다. 디자인 패턴을 사용하는 목적은 코드를 재사용하고, 다른 사람이 코드를 더 쉽게 이해할 수 있도록 하며, 코드 신뢰성을 보장하는 것입니다. 디자인 패턴이 우리 자신과 다른 사람, 그리고 시스템 모두에게 윈윈(win-win)이라는 것은 의심의 여지가 없습니다. 디자인 패턴은 코드 작성을 진정한 엔지니어링으로 만듭니다. 디자인 패턴은 건물의 구조와 마찬가지로 소프트웨어 엔지니어링의 초석입니다.

设计模式(英语 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实例，通过这些例子将帮助您更好地学习理解设计模式。