软件设计模式（Design pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。
 
 
简介
 
设计模式(英语 design pattern)是对面向对象设计中反复出现的问题的解决方案。这个术语是在1990年代由Erich Gamma等人从建筑设计领域引入到计算机科学中来的。这个术语的含义还存有争议。算法不是设计模式，因为算法致力于解决问题而非设计问题。设计模式通常描述了一组相互紧密作用的类与对象。设计模式提供一种讨论软件设计的公共语言，使得熟练设计者的设计经验可以被初学者和其他设计者掌握。设计模式还为软件重构提供了目标。
 
随着软件开发社群对设计模式的兴趣日益增长，已经出版了一些相关的专著，定期召开相应的研讨会，而且Ward Cunningham为此发明了WikiWiki用来交流设计模式的经验。
 
 
历史
 
肯特·贝克和沃德·坎宁安在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）：每一个模式都有自己的名字，模式的名字使得我们可以讨论我们的设计。
 
问题（Problem）：在面向对象的系统设计过程中反复出现的特定场合，它导致我们采用某个模式。
 
解决方案（Solution）：上述问题的解决方案，其内容给出了设计的各个组成部分，它们之间的关系、职责划分和协作方式。
 
效果（Consequence）：采用该模式对软件系统其他部分的影响，比如对系统的扩充性、可移植性的影响。影响也包括负面的影响。
 
别名（Also Known As）：一个模式可以有超过一个以上的名称。这些名称应该要在这一节注明。
 
动机（Motivation）：该模式应该利用在哪种情况下是本节提供的方案（包括问题与来龙去脉）的责任。
 
应用（Applicability）
 
结构（Structure）：这部分常用类图与互动图阐述此模式。
 
参与者（Participants）：这部分提供一份本模式用到的类与物件清单，与它们在设计下扮演的角色。
 
合作（Collaboration）：描述在此模式下，类与物件间的互动。
 
结果（Consequences）：这部分应描述使用本模式後的结果、副作用、与交换(trade-off)
 
实现（Implementaion）：这部分应描述实现该模式、该模式的部分方案、实现该模式的可能技术、或者建议实现模式的方法。
 
例程（Sample Code）：示范程式。
 
已知应用（Known Uses）：业界已知的实做范例。
 
相关模式（Related Patterns）：这部分包括其他相关模式，以及与其他类似模式的不同。
 
 
 
模式列表
 
       设计模式分为三大类：创建型、结构型、行为型。创建型模式处理的是对象的创建过程（通过各种方式创建对象，使对象创建和管理变得简单），结构型模式处理的是对象/类的组合，行为型模式处理类和对象间的交互方式和任务分布。（只有类可以创建对象，接口只能被实现）
 
 
创建型
 
抽象工厂模式(Abstract Factory) 
 
       抽象工厂模式是提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。区别于工厂方法模式的地方，工厂方法模式是创建一个工厂，可以实现多种对象；而抽象工厂模式是提供一个抽象工厂接口，里面定义多种工厂，每个工厂可以生产多种对象。前者的重点在于"怎么生产"，后者的重点在于"生产哪些"；前者是一个抽象产品类，可以派生出多个具体产品类，后者是多个抽象产品类，每个抽象产品类可以派生出多个具体产品类；前者的每个具体工厂类只能创建一个具体产品类的实例，后者的每个具体工厂类可以创建多个具体产品类的实例。
 
工厂方法模式(Factory Method) 
 
       工厂方法模式的创建是因为简单工厂模式有一个问题，在简单工厂模式中类的创建依赖工厂类，如果想要拓展程序，必须对工厂类进行修改，这违背了开闭原则，所以就出现了工厂方法模式，只需要创建一个工厂接口和多个工厂实现类，子类可以自己决定实例化哪一个工厂类，client类针对抽象接口进行编程，如果需要增加新的功能，继承工厂接口，直接增加新的工厂类就可以了，创建过程延迟到子类中进行，不需要修改之前的代码，满足了开闭原则，达到灵活地生产多种对象。。
 
原型模式 (Prototype) 
 
       原型模式是用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。其实就是将对象复制了一份并返还给调用者，对象需继承Cloneable并重写clone()方法。原型模式的思想就是将一个对象作为原型，对其进行复制、克隆，产生一个和原对象类似的新对象。分为浅复制和深复制，前者是将一个对象复制后，基本数据类型的变量都会重新创建，而引用类型，指向的还是原对象所指向的；后者是将一个对象复制后，不论是基本数据类型还有引用类型，都是重新创建的。
 
单例模式(Singleton)
 
       单例模式能保证一个类仅有一个实例，并提供一个访问它的全局访问点，同时在类内部创造单一对象，通过设置权限，使类外部无法再创造对象。单例对象能保证在一个JVM中，该对象只有一个实例存在，这样做的好处就在于如果某些类创建比较频繁，特别是对于一些大型的对象，这是一笔很大的系统开销。在创建的时候，省去了new操作符，降低了系统内存的使用频率，减轻了系统的压力。同时单例模式保证在一个jvm中仅存在一个实例的好处就在于好比一个军队当中只会存在一个最高级别的军官来指挥整个军队，这样才能保证独立控制整个过程，否则如果出现多个，肯定会杂乱无序。
 
建造者模式（Builder）
 
       建造者模式是将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示，就好比是每个饭店或者每家都会做西红柿炒鸡蛋，最后虽然都是西红柿炒鸡蛋的外观，但是由于当中的做饭过程存在差别，所以味道会不同。在程序当中就是将一些不会变的基本组件，通过builder来进行组合，构建复杂对象，实现分离。这样做的好处就在于客户端不必知道产品内部组成的细节；同时具体的建造者类之间是相互独立的，对系统的扩展非常有利，满足开闭原则；由于具体的建造者类是独立的，因此可以对建造过程逐步细化，而不对其他的模块产生任何影响。
 
 
结构型
 
适配器模式 (Adapter)
 
       将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
 
桥接模式(Bridge) 
 
       桥接模式是将抽象部分与实现部分分离，使它们都可以独立的变化。桥接模式就是把事物和其具体实现分开，使他们可以各自独立的变化（突然联想到了mvc模式）。将抽象化与实现化解耦，使得二者可以独立变化，就好比现在常说的mvc模式，view和model之间通过control来控制，达到高内聚低耦合来解耦的目的。
 
组合模式(Composite)
 
       组合模式是将对象组合成树形结构以表示"部分-整体"的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性。创建了一个包含自己对象组的类，并提供修改对象组的方法。在系统的文件和文件夹的问题上就使用了组合模式，文件下不可以有对象，而文件夹下可以有文件对象或者文件夹对象。
 
修饰模式 (Decorator) 
 
       装饰器模式是动态地给一个对象添加一些额外的职责，给一个对象增加一些新的功能，要求装饰对象和被装饰对象实现同一个接口，装饰对象持有被装饰对象的实例。除了动态的增加，也可以动态的撤销，要做到动态的形式，不可以用继承实现，因为继承是静态的。
 
外观模式
 
       外观模式是为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。在客户端和复杂系统之间再加一层，提供一个容易使用的外观层。外观模式是为了解决类与类之间的依赖关系的，外观模式就是将他们的关系放在一个Facade类中，降低了类类之间的耦合度，比如搜狐门户网站，就利用了外观模式。
 
享元模式
 
       享元模式是运用共享技术有效地支持大量细粒度的对象。享元模式的主要目的是实现对象的共享，即共享池，当系统中对象多的时候可以减少内存的开销，重用现有的同类对象，若未找到匹配的对象，则创建新对象，这样可以减少对象的创建，降低系统内存，提高效率。
 
代理模式(Proxy) 
 
        代理模式是为其他对象提供一种代理以控制对这个对象的访问，也就是创建类的代理类，间接访问被代理类的过程中，对其功能加以控制。它和装饰器模式的区别在于，装饰器模式为了增强功能，而代理模式是为了加以控制。代理模式就是多一个代理类出来，替原对象进行一些操作，例如买火车票不一定在火车站买，也可以去代售点。再比如打官司需要请律师，因为律师在法律方面有专长，可以替我们进行操作。
 
 
行为模式
 
责任链模式 (Chain of Responsibility) 
 
       责任链模式是避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。有多个对象，每个对象持有对下一个对象的引用，这样就会形成一条链，请求在这条链上传递，直到某一对象决定处理该请求。但是发出者并不清楚到底最终那个对象会处理该请求。在生活中学生进行请假的过程中，会涉及到，学生请假会一级一级往上批，最终处理，具体由谁批准可能不清楚。在程序当中，现在使用的struts拦截器即用到了责任链模式。
 
命令模式 (Command) 
 
       命令模式是将一个请求封装成一个对象，从而使发出者可以用不同的请求对客户进行参数化。模式当中存在调用者、接收者、命令三个对象，实现请求和执行分开；调用者选择命令发布，命令指定接收者。举个例子，司令员下令让士兵去干件事情，司令员的作用是发出口令，口令经过传递，传到了士兵耳朵里，士兵去执行。司令士兵命令三者相互解耦，任何一方都不用去依赖其他人。其实struts框架也涉及到命令模式的思想。
 
解释器模式（Interpreter）
 
       解释器模式是给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子，基本也就用在这个范围内，适用面较窄，例如：正则表达式的解释等。
 
迭代器模式（Iterator）
 
       迭代器模式是提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示。在Java当中，将聚合类中遍历各个元素的行为分离出来，封装成迭代器，让迭代器来处理遍历的任务；使简化聚合类，同时又不暴露聚合类的内部，在我们经常使用的JDK中各个类也都是这些基本的东西。
 
中介者模式（Mediator）
 
       中介者模式是用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。例如，MVC模式中control就是model和view的中介者。与适配器区别在于，适配器是为了兼容不同的接口，而中介者是为了将显示和操作分离。
 
备忘录模式 (Memento) 
 
       备忘录模式是在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。创建一个备忘录类，用来存储原始类的信息；同时创建备忘录仓库类，用来存储备忘录类，主要目的是保存一个对象的某个状态，以便在适当的时候恢复对象，也就是做个备份。在系统当中使用的撤销操作，即是使用了备忘录模式，系统可以保存有限次数的文件状态，用户可以进行上几个状态的恢复，也就是用到了备忘录模式。
 
观察者模式(Observer) 
 
       观察者模式是定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。也就是当被观察者状态变化时，通知所有观察者，这种依赖方式具有双向性，在QQ邮箱中的邮件订阅和RSS订阅，当我们浏览一些博客时，经常会看到RSS图标，意思就是，当你订阅了该文章，如果后续有更新，会及时通知你。这种现象即是典型的观察者模式。
 
状态模式 (State) 
 
       状态模式是允许对象在内部状态发生改变时改变它的行为。对象具有多种状态，且每种状态具有特定的行为。在网站的积分系统中，用户具有不同的积分，也就对应了不同的状态；还有QQ的用户状态有几种状态，在线、隐身、忙碌等，每个状态对应不同的操作，而且你的好友也能看到你的状态。
 
策略模式 (Strategy) 
 
       策略模式是定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换，且算法的变化不会影响到使用算法的客户。是为了统一接口下的一系列算法类（也就是多种策略），用一个类将其封装起来，使这些策略可动态切换。策略模式属于行为型模式，是为了使这些策略可以相互切换，是为了选择不同的行为。
 
模板方法模式（Template Method）
 
       模板方法模式是定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。该模式就是在一个抽象类中，有一个主方法，再定义1...n个方法，可以是抽象的，也可以是实际的方法，定义一个类，继承该抽象类，重写抽象方法，通过调用抽象类，实现对子类的调用。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤，将一些固定步骤、固定逻辑的方法封装成模板方法。调用模板方法即可完成那些特定的步骤。
 
访问者模式 (Visitor)
 
       访问者模式主要是将数据结构与数据操作分离。在被访问的类里面加一个对外提供接待访问者的接口，访问者封装了对被访问者结构的一些杂乱操作，解耦结构与算法，同时具有优秀的扩展性。通俗来讲就是一种分离对象数据结构与行为的方法，通过这种分离，可达到为一个被访问者动态添加新的操作而无需做其它的修改的效果。访问者模式的优点是增加操作很容易，因为增加操作意味着增加新的访问者。访问者模式将有关行为集中到一个访问者对象中，其改变不影响系统数据结构。
 
 
模式原则
 
大家都开始注意设计模式。那么，到底我们为什么要用设计模式呢？这么多设计模式为什么要怎么设计呢？说实话，以前我还真没搞清楚。就是看大家一口一个"Design pattern"，心就有点发虚。于是就买了本"四人帮"的设计模式，结果看得似懂非懂:看得时候好像是懂了，过一会就忘了。可能是本人比较"愚钝"吧:))最近，有了点感悟。"独乐不如众乐"，与大家分享一下，还望指教! 为什么要提倡"Design Pattern"呢？根本原因是为了代码复用，增加可维护性。那么怎么才能实现代码复用呢？OO界有前辈的几个原则："开－闭"原则(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(String name){
        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之最高境界。
 
 
依赖倒转原则
 
要针对接口编程，而不是针对实现编程。传递参数，或者在组合聚合关系中，尽量引用层次高的类。主要是在构造对象时可以动态的创建各种具体对象，当然如果一些具体类比较稳定，就不必在弄一个抽象类做它的父类，这样有画舌添足的感觉。
 
 
接口隔离原则
 
一种角色，不多不少，不干不该干的事，该干的事都要干 。
 
 
抽象类
 
抽象类抽象类不会有实例，类为子类继承，一般包含这个类的共同属性和方法。注意：好的继承关系中，只有叶节点是具体类，其他节点应该都是抽象类，也就是说具体类是不被继承的。将尽可能多的共同代码放到抽象类中。 

迭代器模式
 
迭代器模式的关键思想是将对列表的访问和遍历从列表对象中分离出来，放入一个独立的迭代器当中。迭代器类定义了一个访问该列表元素的接口。迭代器类所提供的方法负责跟踪当前的元素，即它知道哪些元素已经遍历过了，哪些元素还没有被遍历。 
 迭代器模式能够提供一种方法按照顺序访问一个聚合对象中的所有元素，而又不需要暴露该对象的内部表示。 
 
 
（1）aggregate：聚合接口，其实现子类将创建并且维持一个一种数据类型的聚合体，另外，他还定义了创建相应迭代器对象的接口。 
 （2）ConcreteAggregate：封装了一个数据存储结构，实现了一个具体的聚合，如列表，ArrayList等。一个聚合对象包含一些其他的对象，目的是将这些对象组成一个新的整体对象，该对象也叫做容器对象或者聚合对象。另外，该类提供了创建相应迭代器对象的方法createIterator(),该方法返回类型为ConcreteIterator的一个对象。 
 （3）Iterator：迭代器定义访问和遍历元素的接口。 
 （4）ConcreteIterator（controller）：具体迭代器实现迭代器接口，对该聚合遍历时跟踪当前位置。
 
示例
 
public interface Aggregate
{
    public abstract EvenNumIterator createEvenNumIterator();
    public abstract OddNumIterator createOddNumIterator();
    public abstract CircularIterator createCircularIterator();
}

public class Matrix implements Aggregate
{
    private int length = 7;
    private in[][] matrix = new int[length][length];
    public Matrix()
    {
        ...
    }
    public getMatrixData(){return matrix;}
    public EvenNumIterator createEvenNumIterator()
    {
        return new EvenNumIterator(this);
    }
    public OddNumIterator createOddNumIterator()
    {
        return new OddNumIterator (this);
    }

    public CircularIterator createCircularIterator()
    {
        return new CircularIterator(this);
    }
    public int getLength(){return length;}
}
迭代器
public interface NumberIterator
{
    public abstract boolean hasNext();
    public abstract int next();
    public abstract void remove();
    public abstract int getNumOfItems();
}

public class OddNumIterator implements NumberIterator
{
    private ArrayList<Integer>numList = new ArrayList<Integer>();
    private int lowBound = 0;
    private int numOfEvens = 0;
    int nextNum;
    public OddNumIterator(Matrix mx)
    {
        ....
    }
    public boolean hasNext()
    {
        ...
    }
    public int next()
    {...}
    public void remove()
    {...}
    public int getNumOfItems()
    {...}
}
 
优点
 
（1）迭代器模式支持以不同的方式遍历同一个聚合，复杂的聚合可用多种方式进行遍历。如二叉树的前序遍历，中序遍历以及后序遍历等。 
 （2）当修改某一个遍历算法时，不会影响其他的遍历算法。 
 （3）当修改被遍历的聚合结构代码时，如果该聚合结构没有改变，则相应的遍历算法代码也不需要改变。 
 （4）迭代器简化了聚合的接口。有了迭代器的遍历接口，聚合本身就不需要类似的遍历接口了，这样就简化了聚合的接口。

软件设计模式
 
一、设计目标：
 
⑴、软件设计目标：正确性、健壮性、灵活性、可重用性、高效性
 
1、正确性：也就是满足应用程序的需求。
 
2、健壮性：是指软件对于规范要求以外的输入情况的处理能力。也就是说，在异常情况下，软件能够正常运行的能力。
 
3、灵活性：就是可以允许代码修改平稳地发生，而不会波及到很多其他的模块。
 
4、可重用性：也就是重复使用的意思。
 
5、高效性：一般指两个方面，一是执行效率，二是存储效率。
 
⑵、良好设计的特征：可扩展性、灵活性、可插入性
 
1、可扩展性：新功能容易加入，而且不会影响已有功能，即不“僵硬”
 
2、灵活性：修改一个地方，不会影响其他，即不“脆弱”
 
3、可插入性：用一个容易替换另一个类，只要它们实现相同接口即可，即低“黏度”
 
⑶、面向对象的三大特征：继承性、封装性、多态性
 
1、继承性：特殊类的对象具有其一般类的对象的全部属性和行为，即称特殊类对一般类的继承。
 
2、封装性：把对象的属性和行为组合成为一个独立的单位或部件，并尽可能隐蔽对象的内
 
部细节，而只保留必要的对外接口，使之与外部发生联系。
 
3、多态性：是指不同类型的对象接收相同的消息时，产生不同的行为
 
二、设计原则：
 
⑴、软件设计原则：单一职责原则、开闭原则、里氏替换原则、接口
 
分离原则、依赖倒置原则
 
1、单一职责原则（SRP）：一个类应该有且只有一个改变的理由，它要求“一个设计元素只做一件事”。
 
2、开闭原则（OCP）：不修改原有类就能扩展一个类的行为。也就是说，一个软件实体应当对扩展开放，对修改关闭。
 
3、里氏替换原则（LSP）：子类能替换其超类（is-a 关系），也就是说子类型（subtype）必须能替换其基类型（base type）。
 
4、接口分离原则（ISP）：使用多个专门的接口比使用单一的总接口更好；换言之，从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小的接口之上的；不应该强迫客户程序依赖于它们不用的接口
 
5、依赖倒置原则（DIP）：要依赖于抽象，不要依赖于具体：也就是说，抽象不应当依赖
 
于细节，细节应当依赖于抽象；要针对接口编程，不要针对实现编程。
 
三、设计模式：
 
⑴、软件设计模式的定义：
 
1、模式：是做事的一种方法，也即是实现某个目标的途径，或者技术。
 
2、设计模式：描述了软件设计过程中某一类常见问题的一般性的解决方案
 
3、设计模式：是类的联合体以及与之相伴的算法，这些算法能够实现共同的设计目标。设计模式表达了一种思想而不仅仅是固定的类联合体，相伴的算法表示模式的基本操作。
 
⑵、面向对象设计模式的定义：
 
1、面向对象设计模式：描述了面向对象设计过程中，特定场景下，类与相互通信的对象之间常见的组织关系。
 
2、面向对象设计模式描述的是软件设计，因此它是独立于编程语言的，但是面向对象设计模式的最终实现仍然要使用面向对象编程语言来表达
 
⑶、设计模式的分类：
 
①、依据设计模式的行为方式，也即其目的，将设计模式分为三种类型：创建型
 
模式、结构型模式、行为型模式：
 
a、创建型模式：以灵活的方式创建对象的集合，如：工厂模式、抽象工厂模式、建造者模式、单件模式、原型模式等。
 
B、结构型模式：代表相关对象的集合，如：适配器模式、装饰模式、桥接模式、享元模式、外观模式、代理模式、组合模式。
 
C、行为型模式：在对象集合中捕获行为，如：模板方法模式、观察者模式、迭代子模式、
 
责任链模式、备忘录模式、命令模式、状态模式、访问者模式、中介者模式、策略模式。
 
②、根据设计意图可分为五类：接口型设计模式、责任型设计模式、构造型设计
 
模式、操作型设计模式、扩展型设计模式。
 
⑷、设计模式的主要职责（意图）：
 
1、简单工厂设计模式：一个工厂类处于对产品类实例化的中心位置上，它知道每一个产品，它决定哪一个产品类应当被实例化。这个模式的优点是允许客户端相对独立于产品创建
 
的过程，并且在系统引入新产品的时候无需修改客户端，也就是说，它在某种程度上支
 
持“开-闭”原则。
 
2、工厂方法设计模式：是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中。在软件系统中，经常面临着“某个对象”的创建工作；由于需求的变化，这个对象
 
经常面临着剧烈的变化，但是它却拥有比较稳定的接口。
 
3抽象工厂设计模式：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们
 
具体的泪。抽象工厂模式主要是用于创建一个产品族，而不是一个一个具体的产品。
 
4建造者模式：将产品的内部表象与产品的生成过程分割开来，从而可以使一个建造过程
 
生成具有不同的内部表象的产品对象。也就是说，它将一个复杂的构建与其表示相分离，
 
使得同样的构建过程可以创建不同的表示。
 
5单件模式：一个类仅有一个实例，并提供一个访问它的全局访问点。也就是说，单件模
 
式的要点是：某个类只能有一个实例；它必须自行创建这个实例；它必须自行向整个系
 
统提供这个实例。
 
6原型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型
 
对象的办法创建出更多类型的对象。
 
7适配器设计模式：将接口不同而功能相同或相近的两个接口加以转换。
 
8装饰模式：装饰模式以对客户透明的方式动态地给一个对象附加上更多的责任。换言之，
 
客户端并不会觉得对象在装饰前和装饰后有什么不同。装饰模式可以在不使用创造更多
 
子类的情况下，将对象的功能加以扩展。
 
9桥接模式：将抽象化与实现化脱耦，使得二者可以独立地变化。实现系统可能有多角度
 
分类，每一种分类都有可能变化，那么就把这种多角度分离出来让它们独立变化，减少
 
它们之间的耦合。
 
10组合模式：当需求中是体现部分与整体层次的结构时，以及你希望用户可以忽略组合对
 
象与单个对象的不同，统一地使用组合结构中的所有对象时，就应该考虑到组合模式了。
 
11模板方法模式：当我们要完成某一细节层次一致的一个过程或一系列步骤，但其个别步
 
骤在更详细的层次上的实现可能不同时，我们通常考虑用模板方法模式来处理。
 
12观察者模式：定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对
 
象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使它们能够自动更新
 
自己。
 
13迭代子模式：通过设计一个迭代器，这个迭代器提供一种方法，可以顺序访问聚合对象
 
中的各个元素，但又不暴露该对象的内部表示。
 
14责任链模式：为解除请求者和接受者之间的耦合，而使多个对象都有机会处理这个请求。
 
将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。
 
15备忘录模式：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保
 
存这个状态。这样以后就可以将该对象恢复到原先保存的状态。
 
16命令模式：目的是解除命令发出者和接收者之间的耦合关系，是二者相对独立，有利于
 
程序的并行开发和代码的维护。命令模式的核心思想是将请求封装一个对象，将其作为
 
命令发起者和接受者的中介，而抽象出来的命令对象又使我们能够对一些列请求进行某
 
些操作。
 
17状态模式：核心思想是允许一个对象在它的内部状态改变时改变它的行为，即不同的状
 
态对应不同的行为，这需要将状态单独抽象为一个对象。
 
⑸、设计模式结构图：
 
这里不详细叙述，参见帮助手册----Java设计模式-类图大全(.chm)精解、UML类图解析
 
http://download.csdn.net/detail/ljheee/9473393
 
 
 
推荐文档：
 
http://download.csdn.net/detail/ljheee/9473392
 
http://download.csdn.net/detail/ljheee/9473388
 

设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的；设计模式使代码编制真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。
 

一 、设计模式分为三种类型：
 

 
1.创建型模式：单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式。 

 
2.结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。 

 
3.行为型模式：模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式（Interpreter模式）、状态模式、策略模式、职责链模式(责任链模式)、访问者模式。
 

二、设计模式的六大原则
 

 
1、开闭原则（Open Close Principle） 

 开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。 

 
2、里氏代换原则（Liskov Substitution Principle） 

 里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科 

 
3、依赖倒转原则（Dependence Inversion Principle） 

 这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。 

 
4、接口隔离原则（Interface Segregation Principle） 

 这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。 

 
5、迪米特法则（最少知道原则）（Demeter Principle） 

 为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。 

 
6、合成复用原则（Composite Reuse Principle） 

 原则是尽量使用合成/聚合的方式，而不是使用继承。
 
推荐资料： 
 http://www.runoob.com/design-pattern/prototype-pattern.html 
 http://blog.jobbole.com/74393/