同义词设计模式（设计模式概念）一般指软件设计模式
软件设计模式（Design pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。
- 中文名
- 软件设计模式
- 外文名
- Design pattern
- 别 名
- 设计模式
- 特 点
- 每个模式都有各自的名字
- 分 类
- 基础模式，委托模式，接口模式等
设计模式(英语 design pattern)是对面向对象设计中反复出现的问题的解决方案。这个术语是在1990年代由Erich Gamma等人从建筑设计领域引入到计算机科学中来的。这个术语的含义还存有争议。算法不是设计模式，因为算法致力于解决问题而非设计问题。设计模式通常描述了一组相互紧密作用的类与对象。设计模式提供一种讨论软件设计的公共语言，使得熟练设计者的设计经验可以被初学者和其他设计者掌握。设计模式还为软件重构提供了目标。
肯特·贝克和沃德·坎宁安在1987年利用克里斯托佛·亚历山大在建筑设计领域里的思想开发了设计模式并把此思想应用在Smalltalk中的图形用户接口的生成中。一年后Erich Gamma在他的苏黎世大学博士毕业论文中开始尝试把这种思想改写为适用于软件开发。与此同时James Coplien 在1989年至1991 年也在利用相同的思想致力于C++的开发，而后于1991年发表了他的著作Advanced C++ Idioms。就在这一年Erich Gamma 得到了博士学位，然后去了美国，在那与Richard Helm, Ralph Johnson ,John Vlissides合作出版了Design Patterns - Elements of Reusable Object-Oriented Software 一书，在此书中共收录了23个设计模式。这四位作者在软件开发领域里也以他们的匿名著称Gang of Four(四人帮，简称GoF),并且是他们在此书中的协作导致了软件设计模式的突破。有时这个匿名GoF也会用于指代前面提到的那本书。
尽管名称和顺序在不同的资料中各有不同，描述模式的格式大致分为以下四个主要部分：
模式名称（Pattern Name）：每一个模式都有自己的名字，模式的名字使得我们可以讨论我们的设计。
解决方案（Solution）：上述问题的解决方案，其内容给出了设计的各个组成部分，它们之间的关系、职责划分和协作方式。
别名（Also Known As）：一个模式可以有超过一个以上的名称。这些名称应该要在这一节注明。
动机（Motivation）：该模式应该利用在哪种情况下是本节提供的方案（包括问题与来龙去脉）的责任。
应用（Applicability）
参与者（Participants）：这部分提供一份本模式用到的类与物件清单，与它们在设计下扮演的角色。
合作（Collaboration）：描述在此模式下，类与物件间的互动。
结果（Consequences）：这部分应描述使用本模式後的结果、副作用、与交换(trade-off)
实现（Implementaion）：这部分应描述实现该模式、该模式的部分方案、实现该模式的可能技术、或者建议实现模式的方法。
例程（Sample Code）：示范程式。
已知应用（Known Uses）：业界已知的实做范例。
相关模式（Related Patterns）：这部分包括其他相关模式，以及与其他类似模式的不同。
基础模式
抽象工厂模式(Abstract Factory) ,提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
原型模式 (Prototype) ，用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。
适配器模式 (Adapter) ，将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
桥接模式(Bridge) ，将抽象部分与它的实现部分分离，使它们都可以独立地变化。
容器模式
修饰模式 (Decorator) ，动态地给一个对象添加一些额外的职责。就扩展功能而言， 它比生成子类方式更为灵活。
扩展性模式
管道与过滤器模式
代理模式(Proxy) ，为其他对象提供一个代理以控制对这个对象的访问。
责任链模式 (Chain of Responsibility) ，为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。
命令模式 (Command) ，将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。
柯里化模式
事件监听器模式
备忘录模式 (Memento) ，在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。
状态模式 (State) ，允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。
策略模式 (Strategy) ，定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。
层次访问者模式
模式 Action at a distance
模式 Balking
模式 Guarded suspension
模式 Scheduler
模式 Read write lock
模式 Double checked locking
模式 Disable job requests while running job
模式 Scheduled task
模式 User interface
模式 Disable job requests while running job
模型—视图—控制器模式
大家都开始注意设计模式。那么，到底我们为什么要用设计模式呢。这么多设计模式为什么要这么设计呢?说实话，以前我还真没搞清楚。就是看大家一口一个"Design pattern"，心就有点发虚。于是就买了本"四人帮"的设计模式，结果看得似懂非懂:看得时候好像是懂了，过一会就忘了。可能是本人比较"愚钝"吧。最近，有了点感悟。"独乐不如众乐"，与大家分享一下，还望指教。 为什么要提倡"Design Pattern"呢?根本原因是为了代码复用，增加可维护性。那么怎么才能实现代码复用呢?界有前辈的几个原则："开－闭"原则(Open Closed Principal)、里氏代换原则、合成复用原则。设计模式就是实现了这些原则，从而达到了代码复用、增加可维护性的目的。
此原则是由"Bertrand Meyer"提出的。原文是："Software entities should be open for extension,but closed for modification"。就是说模块应对扩展开放，而对修改关闭。模块应尽量在不修改原(是"原"，指原来的代码)代码的情况下进行扩展。那么怎么扩展呢?我们看工厂模式"factory pattern":假设中关村有一个卖盗版盘和毛片的小子，我们给他设计一"光盘销售管理软件"。我们应该先设计一"光盘"接口。而盗版盘和毛片是其子类。小子通过"DiscFactory"来管理这些光盘。代码为：
public class DiscFactory{
public static 光盘 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之最高境界。呵呵，搞笑，搞笑
依赖倒转原则抽象不应该依赖与细节，细节应当依
要针对接口编程，而不是针对实现编程。传递参数，或者在组合聚合关系中，尽量引用层次高的类。主要是在构造对象时可以动态的创建各种具体对象，当然如果一些具体类比较稳定，就不必在弄一个抽象类做它的父类，这样有画舌添足的感觉接口隔离原则定制服务的例子，每一
一种角色，不多不少，不干不该干的事，该干的事都要干 抽象类抽象类不会有实例
概念：就一个类而言，应该仅有一个引起它变化的原因。
做编程的时候，如果讲每一个类加上各种各样的功能就意味着，无论任何需求要来，你都需要更改这个类，这样会让维护非常麻烦，复用不可能，也缺乏灵活性。如果一个类承担的职责过多，就等于把这些职责耦合起来，一个职责变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭到很多意想不到的破坏。
(也称为最小知识原则)
概念：一个软件实体应当尽可能的少与其他实体发生相互作用。每一个软件单位对其他软件单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。迪米特法则不希望类之间建立直接的联系。如果有真的需要建立联系的，也希望能通过他的友元类来转达。因此，应用迪米特法则有可能造成一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互关系，这在一定程度上增加了系统的复杂度。
模式名称
一个助记名，它用一两个词来描述模式的问题、解决方案和效果。命名一个新的模式增加了我们的设计词汇。设计模式允许我们在较高的抽象层次上进行设计。基于一个模式词汇表，我们自己以及同事之间就可以讨论模式并在编写文档时使用它们。模式名可以帮助我们思考，便于我们与其他人交流设计思想及设计结果。找到恰当的模式名也是我们设计模式编目工作的难点之一。
问题
解决方案
描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象组合）来解决这个问题。
效果
