1、软件设计模式的概念及意义

软件设计模式是对软件设计经验的总结，是对软件设计中反复出现的设计问题的成功解决方案的描述。为了记录这些成功的设计经验并方便以后使用，软件设计模式通常包含 4 个基本要素：模式名称、问题、解决方案以及效果。

模式名称实际上就是一个帮助记忆的名称，是用于软件设计的技术术语，有助于设计者之间的交流。

问题描述了设计者所面临的设计场景，用于告诉设计者在什么情况下使用该模式。

解决方案描述了设计的细节，通常会给出方案的原理图示（例如 UML 的类图，序列图等，也可能是一些示意图）及相关文字说明，如果可能，还会给出一些代码示例，以便对解决方案的深入理解。

效果描述了设计方案的优势和劣势，这些效果通常面向软件的质量属性，例如，可扩展性、可复用性等。

软件设计模式的重要意义在于设计复用。设计模式可以使设计者更加方便地借鉴或直接使用已经过证实的成功设计方案，而不必花费时间进行重复设计。一些设计模式甚至提供了显示的类图设计及代码实例，为设计的文档化及软件的开发提供了直接的支持。总之，设计模式可以帮助设计者更快更好的完成软件系统的设计工作。

 



 

2、软件设计模式的分类

不同领域总结出的软件设计模式其分类也各不相同，下表给出了常见的软件设计模式的分类。

不同领域的软件设计模式的分类

面向对象 分布式计算 企业应用软件 面向服务的体系结构 创建型模式 从混沌到结构 领域逻辑模式 服务设计模式 结构型模式 分布式基础设施 数据源架构模式 服务库设计模式 行为型模式 事件分离与分发 对象-关系行为模式 服务组合设计模式   接口划分 对象-关系结构模式     组件划分 对象-关系元数据映射模式     应用控制 Web 表现模式     并发 分布模式     同步 离线并发模式     对象交互 会话状态模式     适配与扩展 基本模式     模态行为       资源管理       数据库访问    

下面我主要介绍较为基本的面向对象设计模式，如上表所示，面向对象设计模式可分为三类，分别为创建型模式，结构型模式和行为型模式。

对于创建型模式，主要介绍简单工厂方法模式、工厂方法模式、抽象工厂模式、生成器模式和单例模式；对于结构型模式，主要介绍组合模式、适配器模式、外观模式和桥接模式；对于行为型模式，主要介绍迭代器模式、访问者模式、命令模式、中介者模式、策略模式和状态模式。

此外，还经常会使用开闭原则一词，遵循开闭原则设计出的程序模块应该具有以下两个特征：


	
对于扩展是开放的（Open for extension）。这意味着模块的行为是可以扩展的，即当需求改变时，软件开发者可以对模块进行扩展，增加新的功能。
	
	

	
对于修改是封闭的（Close for modification）。在对模块行为进行扩展时，不允许改动模块中已经存在的类的源代码。
	
                      

3、 我对软件设计模式的理解

（1）简单工厂方法模式：一个工厂生产多个产品，只有一个工厂。Python设计模式（1）：简单工厂方法模式

（2）工厂方法模式：一个工厂生产一个产品，有多个工厂。Python设计模式（2）：工厂方法模式

（3）抽象工厂模式：一个工厂生产一类产品，有多个工厂。Python设计模式（3）：抽象工厂模式

（4）生成器模式：一步一步创建一个复杂的对象，只需指定对象的类型和内容，不必知道内部具体的细节。Python 设计模式（4）：生成器模式

（5）单例模式：在软件运行期间只有一个实例。Python 设计模式（5）：单例模式

（6）组合模式：一个或多个相似的对象构成的对象，各个对象有相似的功能。Python设计模式（6）：组合模式

（7）适配器模式：为了解决接口不一致的问题，两个软件模块需要一个适配器类进行适配。Python设计模式（7）：适配器模式

（8）外观模式：隐藏一个软件系统的内部实现细节。只提供一个接口，客户程序直接调用这个接口就行了。Python设计模式（8）：外观模式

（9）桥接模式：抽象与实现分离。Python设计模式（9）：桥接模式

（10）迭代器模式：用于遍历复杂的数据结构。Python设计模式（10）：迭代器模式

（11）访问者模式：作用于一个对象结构体上的元素的操作。可以在不改变结构体中的类的基础上定义新的操作。Python设计模式（11）：访问者模式

（12）命令模式：解除调用者与接收者之间的耦合。为响应客户请求的行动创建一个抽象。Python设计模式（12）：命令模式

（13）中介者模式：将所有对象之间的交互细节抽象到一个独立的类中。Python设计模式（13）：中介者模式

（14）策略模式：定义了一系列算法，将每个算法封装起来，并且使它们之间可以相互替换。Python设计模式（14）：策略模式

（15）状态模式：将不同状态下的行为封装在一个层次类的不同子类中。Python设计模式（15）：状态模式

软件设计模式（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之最高境界。



依赖倒转原则

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



接口隔离原则

一种角色，不多不少，不干不该干的事，该干的事都要干 。



抽象类

抽象类抽象类不会有实例，类为子类继承，一般包含这个类的共同属性和方法。注意：好的继承关系中，只有叶节点是具体类，其他节点应该都是抽象类，也就是说具体类是不被继承的。将尽可能多的共同代码放到抽象类中。 

软件设计模式的个人理解
前提
软件设计模式的简单分类
面向对象的设计的7项原则简介
1. 开闭原则
2. 里氏替换原则
3. 依赖倒置原则
4. 单一职责原则
5. 接口隔离原则
6. 迪米特法则
7. 合成复用原则
7种设计原则的要点
创建型模式
单例模式
原型模式
工厂方法模式
抽象工厂模式
建造者模式
结构型模式
代理模式
适配器模式
桥接模式
装饰模式
外观模式
享元模式
组合模式
行为型模式
模板方法模式
策略模式
命令模式
职责链模式
状态模式
观察者模式
中介者模式
迭代器模式
访问者模式
备忘录模式
解释器模式

前提
如果你不太明白抽象和接口，可以先来参考一下:抽象和接口
软件设计模式的简单分类
GoF（Gang of Four）的 23 种设计模式：


创建型模式：单原工抽建


结构型模式：代适桥装，外享组


行为型模式：模策命，取状观，中迭访备解


面向对象的设计的7项原则简介
软件开发中，程序员要尽量根据以下7条原则来开发程序，从而提高软件的开发效率、节约软件开发成本和维护成本。

开闭原则
里氏替换原则
依赖倒置原则
单一职责原则
接口隔离原则
迪米特法则
合成复用原则

1. 开闭原则


定义：软件实体应当对扩展开放，对修改关闭。


作用：

在软件测试时，只需要测试扩展的代码
提高代码的复用性（粒度越小，被复用的可能性越大）
提高软件的可维护性



实现：通过接口或抽象类为软件实体定义一个相对稳定的抽象层，将相同的可变因素封装在相同的具体实现类中。


2. 里氏替换原则

定义：子类可以扩展父类的功能，但不能改变父类原有的功能。
作用：

里氏替换原则是实现开闭原则的重要方式之一   （扩展了子类而不能修改父类）
克服了继承中重写父类造成的可用性变差的缺点 （不能修改父类）
是动作正确性的保证  （扩展的类不会给已有的系统引入错误，如开闭原则中只测试扩展的代码）


实现：子类继承父类时，除了添加新方法外，尽量不要重写父类的方法。

3. 依赖倒置原则


定义：高层，底层，细节都依赖于抽象。


核心思想：要面向接口编程，而不是面向实现编程：





作用：

降低类间的耦合性
提高系统的稳定性
减少并行开发引起的风险
提高代码的可读性和可维护性



实现：

每个类尽量提供接口或抽象类，或两者都提供
变量的声明类型尽量使接口或者是抽象类
任何类都不应该从具体类派生
使用继承时尽量遵循里氏替换原则



4. 单一职责原则

定义：一个类有且仅有一个引起它变化的原因，否则应该被拆
理解：一个人应该只有一个引起他心动的原因，否则应该拆分。
作用（优点）：

降低类的复杂性
提高类的可读性
提高系统的可维护性
变更引起的风险降低


实现：设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中。

5. 接口隔离原则


定义：将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户喜欢的方法。


理解：卖车的时候根据客户的经济能力为客户分配合适的车辆销售，而不是客户只有10W的预支却提供5W~200W的销售。


优点：

提高系统的灵活性和可维护性。
提高了系统的内聚性。
接口的粒度大小定义合理，保证系统的稳定性。
使用多个专门的接口体现对象的层次。
减少项目工程中的代码冗余。



实现：

接口尽量小，但应有限度。（不能细分到轮胎，方向盘，发动机，而应是整车销售）
为依赖接口的类定制服务。
了解环境，拒绝盲从。
提高内聚，减少对外交互。



6. 迪米特法则

定义：只与朋友说话，不与陌生人说话。
理解：Demeter is a famous star in the world , and you can just get in touch with him by his assistant.
优点：

降低了类之间的耦合度，提高模块的相对独立性。
提高了类的可复用率和系统的扩展性。


缺点：增加系统的复杂性，减低通讯效率。
强调：

从依赖者的角度说，只依赖应该依赖的对象。
从被依赖者的角度说，只暴露应该暴露的方法。


运用时注意：

创建弱耦合的类
降低类成员的访问权限
优先考虑将一个类设置成不变类
将引用其他对象的次数降到最低
不暴露类的属性成员，提供set和get方法
谨慎使用序列化(Serializable)功能



7. 合成复用原则

定义：在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次考虑使用继承关系来实现。
理解：复用时的优先级定义。
实现：将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而实现复用。

7种设计原则的要点
对修改关闭：开闭原则
不破坏继承：里氏替换原则
面向接口编程：依赖倒置原则
类的职责单一：单一职责原则
设计接口精简：接口隔离原则
降低耦合度：迪米特法则
优先使用组合或聚合关系复用，少用继承关系复用：合成复用原则
总而言之，7种设计原则就是考试范围，如果不用就等于盲目复习，在整个过程中效率低下。
创建型模式
概述：怎样创建模型，将对象的创建和使用分离。
单例模式


定义：一个类只有一个实例，且该类能自行创建这个实例。


特点：

只有一个实例对象
该单例对象必须由单例类自行创建
对外提供一个访问该单例的全局访问点



角色：

单例类
访问类



实现：

懒汉式：在类加载时没有生成单例，第一次调用getInstance方法时才创建。
饿汉式：类一旦加载就创建一个单例，保证在第一次调用getInstance方法前单例存在。



应用：

如果一个类频繁实例化，创建的对象又频繁销毁。
只生成一个对象
对象需要被共享的场合



举例：班长，身份证号。


原型模式


定义：用一个已经创建的实例作为原型，通过赋值该原型对象来创建一个和原型相同或相似的新对象。


角色：

抽象原型类
具体原型类
访问类



实现：原型模式的克隆分为浅克隆和深克隆。
Java中的Object类提供了浅克隆的clone()方法。


应用场景：

对象间相同或相似（个别属性不同）
对象创建过程比较麻烦，但是复制方便



工厂方法模式

定义：定义一个创建产品对象的工厂接口，将产品对象的实际创建工作推迟到具体子工厂中
理解：电视机，电冰箱工厂
优点：

用户只需要知道工厂的名字就可以得到所要的产品
系统新家新的产品只需要添加具体产品类和具体工厂类


角色：

抽象工厂
具体工厂
抽象产品
具体产品


应用场景：

客户只知道创建产品的工厂名，而不知道具体的产品名
创建对象得到任务有多个具体子工厂中的某一个完成，而抽象工厂只提供创建产品的接口
客户不关心创建产品的细节，只关心品牌



抽象工厂模式

定义：为访问类提供一个创建一组相关或相互依赖对象的接口，且访问类无须指定所要产品的具体类就能得到同族的不同等级的产品模式结构
理解：电器工厂
优点：

在类的内部对产品族中相关联的多等级产品共同管理
增加一个新的产品族不需要修改代码


角色：同工厂模式一样
应用场景：

创建的对象是一系列相互关联或相互依赖的产品族（电器工厂中电视机，洗衣机）
系统中有多个产品族，但每次只使用某一族产品
系统中提供了产品的类库，且所有产品的接口相同，客户端不依赖产品实例的创建细节和内部结构



建造者模式

定义：将一个复杂对象的构造与它的表示分离，使同样的构建过程可以创建不同的表示
理解：装修客厅时，客户告诉负责人需求，负责人分配工人干活
优点：

各个具体的建造者相互独立，有利于系统的扩展
客户端不必知道产品内部组成的细节，便于控制细节风险


缺点：

产品的组成部分必须相同，限制了使用范围
如果产品的内部变化复杂，会增加很多的建造者类


角色：

产品角色
抽象建造者
具体建造者
指挥者


应用场景：

创建的对象较复杂，由多个部件构成，各部件面临复杂的变化，但构件间的建造方式是稳定的
产品的构建过程和最终的表示是独立的



结构型模式
概述：描述如何将类或对象按某种布局组成更大的结构。
代理模式


定义：由于某些原因需要给某对象提供一个代理以控制对该对象的访问。


举例：微信上的某些鞋厂代理商（各种鞋都卖）


优点：

在客户端和目标对象之间起到一个中介作用和保护目标对象的作用
代理对象可以扩展目标对象的功能
分离客户端和目标对象，降低系统的耦合度



缺点：

请求处理速度变慢
增加系统的复杂性



角色：


抽象主题类


真实主题类


代理类




En：agency，proxy


适配器模式


定义：使原来的接口转换成用户希望的接口，使原来因为接口不兼容而不能工作的类而正常工作


举例：Type-c接口耳机转换器，读卡器（年代久远）


优点：

客户端通过适配器可以透明的调用接口
复用现存的类
将目标类和适配者类解耦，解决目标类和适配者类接口不一致的问题



缺点：更换适配器的过程比较复杂


角色：

目标接口
适配器类
适配者类



En： Adapter


桥接模式

定义：将抽象和实现分离，使它们可以独立变化
举例：按分类调用某款背包（颜色，类型，大小）
优点：

扩展能力强
实现细节对客户透明


缺点： 聚合关系建立在抽象层，增加了系统的理解和设计难度。
角色：

抽象化角色
扩展化角色
实现化角色
具体实现化角色


En：bridge，concrete , refine

装饰模式

定义：不改变现有对象结构的情况下，动态地给该对象增加一些职责的模式。
举例：巴啦啦小魔仙全身变
优点：

比采用父类继承更灵活
可以设计出多个不同的具体装饰类，创造出多个不同行为的组合


缺点：装饰模式增加了许多子类
角色：

抽象构件
具体构件
抽象装饰
具体装饰


En：concrete,decorator,component

外观模式

定义：通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。
举例：市民之家提供一个统一的接口办理许多业务
优点：

降低了子系统与客户端之间的耦合度
对客户屏蔽了子系统组件
降低了大型软件系统中的编译依赖性


缺点：

不能很好的限制客户使用子系统类
增加新的子系统可能会修改客户类或客户端的源代码（开闭原则）


角色：

外观角色
子系统角色
客户角色


En：facade,sub,client

享元模式


定义：运用共享技术有效支持大量细粒度对象的复用。


举例：五子棋的棋子生成，从享元工厂中取出。


优点：相同对象只保存一份，降低了系统中对象的数量。


缺点：

一些不能共享的状态外部化，增加程序的复杂性。
读取享元模式的外部状态会使得运行时间变长。



角色：

抽象享元角色
具体享元角色
非享元角色
享元工厂角色



En：flyweight,concrete


组合模式


定义：将对象组合成树状的层次结构模式。


举例：网店购物车的实现。


优点：

客户端代码可以一致地处理单个对象和组合对象，简化了客户端代码
容易在组合体内加入新的对象



缺点：

设计较为复杂。
不容易限制容器中的构件。
不容易用继承的方法来增加构件的新功能。



角色：

抽象构件角色
树叶构件角色
树枝构件角色



分类：透明方式，安全方式。


En：component , leaf , composite


行为型模式
概述：用于描述程序在运行时复杂的流程控制，满足合成复用原则。
模板方法模式


定义：定义了操作中的算法骨架，将算法的一些步骤（每个子类中都会用到的）延迟到子类中。


举例：点单——吃饭（父类的抽象方法）——结账


优点：

封装了不变部分，扩展可变部分。
在父类中提取了公共的部分代码，便于代码的复用。
部分方法是由子类实现。



缺点：


每个不同的实现都需要重新定义一个子类。


父类中的抽象方法由子类实现，子类执行的结果会影响父类的结果（代码的阅读难度增加）。




角色：


抽象类：

抽象方法：父类声明，子类实现。
具体方法：父类已实现，子类继承或重写。
钩子方法：父类已实现，用于判断的逻辑方法和需要子类重写的空方法。



具体子类：
实现抽象和钩子方法。




策略模式


定义：将定义的每个算法封装起来，使他们可以相互替换，且算法的变换不影响用户的使用。


举例：客户点单大闸蟹，厨房做大闸蟹时两种算法：清蒸 和 红烧


优点：

可以避免使用多重条件语句。
提供可重用的算法族，避免重复的代码。
可以提供相同行为的不同实现，客户可以根据不同时间/空间选择不同的策略。
提供了对开闭原则的完美支持。
把算法的使用放到环境类中，而算法的实现移到具体策略类中，实现分离。



缺点：

客户端必须理解所有策略算法的区别，适当时选择恰当的算法类。
策略模式造成很多的策略类。



角色：


抽象策略类


具体策略类


环境类




命令模式


定义：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。


举例：饭店将点餐信息（命令）告诉服务员(调用者)，服务员将命令传递给厨师（执行者）。


优点：

降低系统的耦合度（厨师与服务员解耦）。
增加或删除命令非常方便。
可以实现宏命令（多个命令装配成一个组合命令）。
方便实现Undo和Redo操作。



缺点：可能产生大量具体命令类，增加系统的复杂性。


角色：

抽象命令类角色
具体命令角色
实现者/接受者角色
调用者/请求者角色



职责链模式


定义：避免请求发送者与多个请求处理着耦合在一起，将所有请求的处理者通过前一对象记住其下一对象的引用而形成一条链。


举例： 请假的过程 ：学生→班主任 → 辅导员 →院主任→ 教务处  有一个对象处理即可，对象无权限处理传递到下一级


优点：

降低对象间的耦合度
增强了系统的扩展性
增强了给对象指派职责的灵活性
简化了对象间的链接
责任分担



缺点：

不能保证每个请求一定被处理
对于较长的链，请求的处理可能涉及多个处理对象，系统性能受一定的影响。
职责链建立的合理性要靠客户端来保证，增加了客户端的复杂性，导致系统出错，循环调用。



角色：

抽象处理者
具体处理者
客户类



状态模式


定义：对有状态的对象，把复杂的”判断逻辑“提取到不同的状态对象中，允许状态对象在其内部状态发生改变时改变其行为。


举例：由风扇的转速把风扇的档位进行划分。


优点：

将与特定状态相关的行为局部化到一个状态，并且将不同状态的行为分割开。
减少对象间的相互依赖。
有利于程序的扩展。



缺点：

会增加系统的类和对象的个数。
结构和实现比较复杂，使用不当会造成程序结构和代码的混乱。



角色：

环境角色（维持当前状态）
抽象状态角色
具体状态角色



En: Context,state,concrete,enviroment


观察者模式


定义：多个对象间存在一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。


举例：上课程序检测到上课时间到，打铃通知上课。


优点：

降低了目标与观察者之间的耦合关系。
目标与观察者之间建立了一套触发机制。



缺点：

目标与观察者之间的依赖问题并没有完全解除，可能出现循环引用。
观察者对象很多时，通知的发布会花费很多时间，降低效率。



角色：

抽象主题角色
具体主题角色
抽象观察者角色
具体观察者角色



En：subject,concrete,observer


中介者模式

定义：用一个中介对象来封装一系列对象之间的交互，使原有对象之间的耦合松散，并可以独立的改变他们之间的交互。
举例：Like Demeter
优点：

降低耦合度
将对象间一对多关联变成一对一


缺点：同事类太多时，难以维护
角色：

抽象中介者角色
具体中介者角色
抽象同事类角色
具体同事类角色


En：concrete ,mediator ，colluage

迭代器模式


定义：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。


举例：旅行软件展示一个地区的所有旅游景点（java中提供的iterator）。


优点：

访问一个聚合对象的内部无需暴露它的内部表示。
遍历任务交由迭代器完成。
支持以不同的方式遍历一个集合，可以自定义。
增加新的聚合类无须修改原有的代码。
封装性良好，为聚合结构提供了一个统一的接口。



缺点：增加了类的个数，增加了系统的复杂性。


角色：

抽象聚合角色
具体聚合角色
抽象迭代器角色
具体迭代器角色



En：aggregate (聚合),iterator


访问者模式

定义：将数据结构中的各元素的操作分离出来封装成独立的类，在不改变集合元素的前提下，为数据结构中每个元素提供多种访问方式。
举例：不同的访问着对类的处理不同，生成的产品也不同（比如自己和厨师同样拿一条鱼做饭）
优点：

扩展性好。
复用性好。
灵活性好。
符合单一职责原则。


缺点：

增加新的元素类很困难。
破坏了封装。对访问者公布了具体元素细节。
违反了依赖倒置原则，依赖了具体类而没有依赖抽象类。


角色：

抽象访问者角色
具体访问者角色
抽象元素角色
具体元素角色
对象结构


En：Visitor，element

备忘录模式

定义：不破坏封装性的前提下，获取保存一个对象的内部状态，以便以后需要的时候恢复。
举例：书中提供了一个相亲游戏，从四大美女中选择来做自己的爱人（我觉得行，你觉得呢）
优点：

提供了一种可以恢复状态的机制。
实现了内部状态的封装。
简化了发起人类。


缺点：资源消耗大。
角色：

发起人角色。
备忘录角色。
管理者角色。


En：Originator，memento，caretaker

解释器模式


定义：给分析对象定义一个语言，并定义该语言的文法表示，设计一个解析器来解释语言中的句子。


举例：我觉得这个可以用 java—语法—API来表示，或者 English—Grammar—dictionary


优点：

扩展性好
容易实现



缺点：

执行效率较低（通过例子就很容易理解了）
引起类膨胀，每条规则都应至少定义一个类，导致系统难以管理和维护



角色：

抽象表达式角色
终结符表达式
非终结符表达式
环境角色
客户端



En：Expression, terminal, noterminal , context , client

     所谓“软件设计模式”，即从众多优秀软件系统中总结出的成功的可复用的设计方案。使用设计模式是为了可重用代码，让代码更容易被他人理解，保证代码的可靠性。软件领域的设计模式起源于建筑学，后来受其影响，软件设计领域也产生了软件设计模式。
     公认的在设计模式领域最具影响力的著作是由Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides在1994年合作出版的《Design Patterns:Elements of Reuseable Object-Oriented Software》，现通常被称为GOF（Gang Of Four）之书。其中总结了23个模式，该书也被公认为是设计模式领域的奠基之作。
一个软件设计模式主要包含四个基本要素，即名称、问题、方案和效果。
名称：一个模式的名称高度概括了这个模式的本质，一般需要利于行业交流；
问题：描述了该模式所解决的问题，也就是该模式的使用环境；
方案：即对问题的具体解决方法；
效果：即使用该模式解决问题的效果，包括模式对系统的灵活性、扩充性和复用性的影响、模式的优缺点等。


软件设计模式的六大原则：
1、开闭原则：对扩展开放，对修改关闭；
2、里氏代换原则：任何基类可以出现的地方，其子类一定也可以出现；
3、依赖倒转原则：针对接口编程，依赖于抽象而不依赖于具体；
4、接口隔离原则：使用多个隔离的接口要优于使用单个接口；
5、迪米特法则（最少知道原则）：一个实体应尽量少的与其他实体之间发生相互作用，使系统的功能模块相对独立；
6、合成复用原则：尽量使用合成/聚合的方式，而不是使用继承。


类（对象）之间的关系
关联关系（association）：表示一类对象与另一类对象之间有关联，在UML中用带箭头的实线连接，在程序中通常将一个类的对象作为另一个类的属性。
如下图：


关联可以是双向的，用不带箭头的实线连接，如：


还可以有自关联，即一个类的属性对象类型为该类本身，如：


聚合关系（aggregation）：是一种强的关联关系，是整体和个体之间的关系，在UML中用带空心菱形的实线连接，如:


组合关系（composition）：一种比聚合关系还要强的关联关系，是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在，部分对象也将不存在，部分对象与整体对象之间具有同生共死的关系。在UML中，组合关系用带实心菱形的直线表示。如：


泛化关系（Generalization）：即继承关系，泛化关系用于描述父类与子类之间的关系，在UML中，泛化关系用带空心三角形的直线来表示。如：


接口与实现关系（Realization）:表示了类与接口的关系，类实现的接口，在UML中用带空心三角形的虚线表示，如：


依赖关系（Dependency）:依赖关系表示一个类依赖于另一个类的定义，总是单向的，是一种使用关系，在UML中用带箭头的虚线表示，有依赖的一方指向被依赖的一方，在程序中，通常为某个类的方法使用另一个类的对象作为参数，如：




模式的分类：创建型、行为型、结构型
       创建型模式设计对象的实例化，其特点是不让用户代码依赖与对象的创建或排列方式，避免用户直接使用new运算符创建对象。
创建型模式包括：工厂方法模式、抽象工厂模式、生成器模式、原型模式和单件模式。
       行为型模式涉及怎样合理的设计对象之间的交互通信，以及怎样合理的为对象分配职责，让设计富有弹性，易于维护、扩展和复用。
行为型模式包括：责任链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模版方法模式和访问者模式。
       结构型模式涉及如何组合类和对象来形成更大的结构，和类有关的主要是如何合理使用继承机制，和对象有关的主要是如何使用对象的组合机制。
结构型模式包括：适配器模式、组合模式、代理模式、享元模式、外观模式、桥接模式和装饰模式。