一What is design pattern ？模式是在物体或事件上，产生的一种规律变化与自我重复的样式与过程。

在模式之中，某些固定的元素不断以可预测的方式周期性重现。

What is design pattern ？广义讲，软件设计模式是可解决一类软件问题并能重复使用的软件设计方案；狭义讲，设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。

是在类和对象的层次描述的可重复使用的软件设计问题的解决方案；[面向对象]设计模式体现的是程序整体的构思，所以有时候它也会出现在分析或者是概要设计阶段设计模式的核心思想是通过增加抽象层，把变化部分从那些不变部分里分离出来GOF（Gang of Four）的设计模式定义：设计模式是在一个上下文中，对一个问题的解决方案，及其能够达到的效果。

即模式的四要素：名称、上下文与问题、解决方案、效果。

分类：23种设计模式：创建型：5种结构型：7种行为型：11种四要素：1.模式名称(Pattern Name)2.问题(Problem)：描述应该在何时使用模式。

解释了设计问题和问题存在的前因后果,可能还描述模式必须满足的先决条件；3.解决方案(Solution)：描述了设计的组成成分、相互关系及各自的职责和协作方式。

模式就像一个模板，可应用于多种场合，所以解决方案并不描述一个具体的设计或实现，而是提供设计问题的抽象描述和解决问题所采用的元素组合（类和对象）；4.效果(consequences )：描述模式的应用效果及使用模式应权衡的问题都有哪些设计模式？GOF共提出23种设计模式：创建型：5种结构型：7种行为型：11种Creational Patterns用来创建对象的模式，抽象了实例化过程1.Factory Method [ 工厂模式]父类负责定义创建对象的公共接口，而子类则负责生成具体对象，将类的实例化操作延迟到子类中完成；2.Abstract Factory [ 抽象工厂模式]为一个产品族提供统一的创建接口。

当需要这个产品族的某一系列的时候，可以从抽象工厂中选出相应的系列创建一个具体的工厂类；3.Singleton [ 单例模式]保证一个类有且仅有一个实例，提供一个全局访问点；4.Builder [ 建造者模式]将复杂对象创建与表示分离，同样的创建过程可创建不同的表示。

允许用户通过指定复杂对象类型和内容来创建对象，用户不需要知道对象内部的具体构建细节；5.Prototype [ 原型模式]通过“复制”一个已经存在的实例来返回新的实例（不新建实例）。

被复制的实例就是“原型”，这个原型是可定制的。

原型模式多用于创建复杂的或者耗时的实例，因为这种情况下，复制一个已经存在的实例使程序运行更高效；或者创建值相等，只是命名不一样的同类数据；Structural Patterns结构型模式讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者通过组合一些对象来实现新的功能（对象结构型模式）1.Adapter [适配器模式]将一个类的接口适配成用户所期待的接口。

一个适配器允许因为接口不兼容而不能在一起工作的类工作在一起，做法是将类自己的接口包装在一个已存在的类中；2.Bridge [桥接模式]桥接模式的用意是将问题的抽象和实现分离开来实现，通过用聚合代替继承来解决子类爆炸性增长的问题；posite [ 组合模式]定义一个接口，使之用于单一对象，也可以应用于多个单一对象组成的对象组；4.Decorator [ 装饰模式]给对象动态添加额外的职责，就好像给一个物体加上装饰物，完善其功能；5.Façade [ 外观模式]外观模式为子系统提供了一个更高层次、更简单的接口，从而降低了子系统的复杂度，使子系统更易于使用和管理。

外观承担了子系统中类交互的责任6.Flyweight [ 享元模式]Flyweight是一个共享对象，它可以同时在不同上下文（Context）使用；7.Proxy [ 代理模式]在软件系统中，有些对象有时候由于跨越网络或者其他障碍，而不能够或者不想直接访问另一个对象，直接访问会给系统带来不必要的复杂性，这时候可以在客户程序和目标对象之间增加一层中间层，让代理对象来代替目标对象打点一切，这就是代理（Proxy）模式；Behavioral Patterns着力解决的是类实体之间的通讯关系，希望以面向对象的方式描述一个控制流程。

1.Chain of Responsibility [ 责任链模式]很多对象由每一个对象对其下一个对象的引用而连接起来形成一条链。

请求在这个链上传递，直到链上的某一个对象决定处理此请求。

发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使系统可以在不影响客户端的情况下动态的重新组织链和分配责任；mand [ 命令模式]将请求及其参数封装成一个对象，作为命令发起者和接收者的中介，可以对这些请求排队或记录请求日志，以及支持可撤销操作；3.Interpreter [ 解释器模式]给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子；4.Iterator [ 迭代器模式]提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示；5.Mediator [ 中介者模式]用一个中介对象来封装一系列的对象交互；6.Memento [ 备忘录模式]在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。

这样以后就可将该对象恢复到原先保存的状态；7.Observer [ 观察者模式]定义了对象之间一对多的依赖，当这个对象的状态发生改变的时候，多个对象会接受到通知，有机会做出反馈；8.State [ 状态模式]允许一个“对象”在其内部状态改变的时候改变其行为，即不同的状态，不同的行为9.Strategy [ 策略模式]定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。

策略模式使这些算法在客户端调用它们的时候能够互不影响地变化；10.Template [ 模板模式]定义了一个算法步骤，并允许子类为一个或多个步骤提供实现。

子类在不改变算法架构的情况下，可重新定义算法中某些步骤；11.Visitor [ 访问者模式]表示一个作用于某对象结构中的各元素的操作。

可以在不改变各元素的类的前提下定义作用于这些元素的新操作；面向对象方法抽象（Abstraction）封装（Encapsulation）多态（Polymorphism）继承（Inheritance）Object-Oriented Method类的功能要单一，体现了抽象加强内聚，松散耦合好的封装性类的粒度要合理实现类不能依赖使用类应考虑灵活性，也就是可配置，可维护要考虑性能，可伸缩性要考虑后续的变化，也就是可扩展性要考虑合理的复用，这是平衡的艺术要合理的考虑接口和抽象类的使用尽量减少类间的交互次数和交互的信息量访问对象必须通过接口，不能绕过接口直接访问OO design principles开闭原则(OCP)单一职责原则（SRP）里氏替换原则（LSP）依赖倒置原则（DIP）接口隔离原则（ISP）迪米特原则（LoD）单一职责原则（Single Responsibility Principle, SRP）定义：就一个类而言，应该仅有一个引起它变化的原因；每一个引起类变化的原因就是一个职责，当类具有多职责时,应把多余职责分离出去，分别创建一些类来完成每一个职责；每一个职责都是一个变化的轴线，当需求变化时会反映为类的职责的变化；里氏替换原则（Liskov Substitution Principle, LSP）定义：所有引用基类的地方必须能透明地使用其子类的对象里氏替换原则是继承复用的基石，只有当派生类可以替换掉其基类，而软件功能不受影响时，基类才能真正被复用，派生类也才能够在基类的基础上增加新的行为LSP本质：在同一个继承体系中的对象应该有共同的行为特征里氏替换原则包含了两层重要含义：子类必须完全的实现父类的方法；子类可以有自己的个性依赖倒置原则（Dependence Inversion Principle, DIP）定义：高层模块不应依赖低层模块，二者都应该依赖于抽象高层模块只应该包含重要的业务模型和策略选择，低层模块则是不同业务和策略的实现；高层抽象不依赖高层和低层模块的具体实现，最多只依赖于低层的抽象；低层抽象和实现也只依赖于高层抽象；辅助原则任何变量都不应该持有一个指向具体类的引用；任何类都不应该从具体类派生；任何方法都不应覆盖其任何基类中已经实现了的方法；DIP引例—驾驶汽车依赖倒置原则（DIP）另一种理解：客户类和服务类都应该依赖于抽象（接口），并且客户类拥有接口。

依赖是有方向的，客户类依赖于服务类。

DIP引例—驾驶汽车DIP引例—驾驶汽车接口隔离原则（Interface Separate Principle, ISP）定义：类间的依赖关系应该建立在最小的接口上。

多个和客户相关的接口要好于一个通用接口；如果一个类有几个使用者，与其让这个类载入所有使用者需要使用的所有方法，还不如为每个使用者创建一个特定接口，并让该类分别实现这些接口；ISP引例—星探查询ISP引例—星探查询接口隔离原则（ISP）迪米特原则（Law of Demeter，LoD）LoD引例—人数清点LoD引例—人数清点LoD引例—人数清点开闭原则（Open-Closed Principle , OCP）定义：软件对扩展是开放的，对修改是关闭的。

开发一个软件时，应可以对其进行功能扩展(开放)，在进行扩展的时候，不需要对原来的程序进行修改(关闭)好处：在软件可用性上非常灵活。

可以在软件完成后对软件进行扩展，加入新的功能。

这样，软件就可通过不断的增加新模块满足不断变化的新需求由于不修改软件原来的模块，不用担心软件的稳定性实现的主要原则抽象原则：把系统的所有可能的行为抽象成一个底层；由于可从抽象层导出一个或多个具体类来改变系统行为，因此对于可变部分，系统设计对扩展是开放的;可变性封装原则：对系统所有可能发生变化的部分进行评估和分类，每一个可变的因素都单独进行封装;COP引例—书店销售书籍COP引例—书店销售书籍项目投产了，书籍正常销售出去，书店也盈利了。

从2008年开始，全球经济都开始下滑，对零售业影响还是比较大，书店为了生存开始打折销售：所有40元以上的书籍9折销售，其他的8折销售。

对已经投产的项目来说，这就是一个变化，我们来看看这样的一个需求变化，我们该怎么去应对，有三种方法可以解决这个问题：修改接口：在IBook上新增加一个方法getOffPrice()；修改实现类：修改NovelBook类中的方法，直接在getPrice()中实现打折处理；通过扩展实现变化。