SunnyRivers

观察者模式（Observer Pattern）又叫作发布-订阅（Publish/Subscribe）模式、模型-视图（Model/View）模式、源-监听器（Source/Listener）模式或从属者（Dependent）模式。定义一种一对多的依赖关系，一个主题对象可被多个观察者对象同时监听，使得每当主题对象状态变化时，所有依赖它的对象都会得到通知并被自动更新，属于行为型设计模式。

备忘录模式（Memento Pattern）又叫作快照模式（Snapshot Pattern）或令牌模式（Token Pattern），指在不破坏封装的前提下，捕获一个对象的内部状态，并在对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态，属于行为型设计模式。备忘录模式的本质是从发起人实体类（Originator）隔离存储功能，降低实体类的职责。

状态模式（State Pattern）也叫作状态机模式（State Machine Pattern），允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类，属于行为型设计模式。状态模式中类的行为是由状态决定的，在不同的状态下有不同的行为。其意图是让一个对象在其内部改变的时候，行为也随之改变。状态模式的核心是状态与行为绑定，不同的状态对应不同的行为。

命令模式（Command Pattern）是对命令的封装，每一个命令都是一个操作：请求方发出请求要求执行一个操作；接收方收到请求，并执行操作。命令模式解耦了请求方和接收方，请求方只需请求执行命令，不用关心命令怎样被接收、怎样被操作及是否被执行等。命令模式属于行为型设计模式。在软件系统中，行为请求者与行为实现者通常是一种紧耦合关系，因为这样的实现简单明了。但紧耦合关系缺乏扩展性，在某些场合中，当需要对行为进行记录、撤销或重做等处理时，只能修改源码。

迭代器模式（Iterator Pattern）又叫作游标模式（Cursor Pattern），它提供一种按顺序访问集合/容器对象元素的方法，而又无须暴露集合内部表示。迭代器模式可以为不同的容器提供一致的遍历行为，而不用关心容器内元素的组成结构，属于行为型设计模式。迭代器模式的本质是把集合对象的迭代行为抽离到迭代器中，提供一致的访问接口。通俗来讲就是提供一种方法顺序访问一个聚合对象中的各个元素，而又不需要暴露该对象的内部表示。

责任链模式（Chain of Responsibility Pattern）将链中每一个节点都看作一个对象，每个节点处理的请求均不同，且内部自动维护下一个节点对象。当一个请求从链式的首端发出时，会沿着责任链预设的路径依次传递到每一个节点对象，直至被链中的某个对象处理为止，属于行为型设计模式。责任链模式（Chain of Responsibility）是一种处理请求的模式，它让多个处理器都有机会处理该请求，直到其中某个处理成功为止。

策略模式（Strategy Pattern）又叫作政策模式（Policy Pattern），它将定义的算法家族分别封装起来，让它们之间可以互相替换，从而让算法的变化不会影响到使用算法的用户，属于行为型设计模式。策略是指，定义一组算法，并把其封装到一个对象中。然后在运行时，可以灵活的使用其中的一个算法。这种模式非常适合那些需要根据不同情况选择不同行为的场景。

模板方法模式（Template Method Pattern）又叫作模板模式，指定义一个操作中的算法的框架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤，属于行为型设计模式。模板方法模式实际上封装了一个固定流程，该流程由几个步骤组成，具体步骤可以由子类进行不同的实现，从而让固定的流程产生不同的结果。它非常简单，其实就是类的继承机制，但它却是一个应用非常广泛的模式。模板方法模式的本质是抽象封装流程，具体进行实现。

委派模式（Delegate Pattern）又叫作委托模式，是一种面向对象的设计模式，允许对象组合实现与继承相同的代码重用。它的基本作用就是负责任务的调用和分配，是一种特殊的静态代理模式，可以理解为全权代理模式，但是代理模式注重过程，而委派模式注重结果。委派模式属于行为型设计模式，不属于GoF的23种设计模式。委派模式是一种设计模式，其中一个对象（委派人）将任务委托给另一个对象（受托人）来执行。委派人和受托人之间通常是通过接口或抽象类联系起来的，委派人通过持有受托人的引用，将任务交给受托人处理。特点。

桥接模式（Bridge Pattern）又叫作桥梁模式、接口（Interface）模式或柄体（Handle and Body）模式，指将抽象部分与具体实现部分分离，使它们都可以独立地变化，属于结构型设计模式。常用用于替换继成使用桥接模式的好处在于，如果要增加一种引擎，只需要针对Engine派生一个新的子类，如果要增加一个品牌，只需要针对RefinedCar派生一个子类，任何RefinedCar的子类都可以和任何一种Engine自由组合，即一辆汽车的两个维度：品牌和引擎都可以独立地变化。

适配器模式（Adapter Pattern）又叫作变压器模式，它的功能是将一个类的接口变成客户端所期望的另一种接口，从而使原本因接口不匹配而导致无法在一起工作的两个类能够一起工作，属于结构型设计模式。适配器模式就是说，当前系统存在两种接口A和B，客户端只支持访问A接口，但是当前系统没有A接口对象，有B接口对象，而客户端无法识别B接口，因此需要通过一个适配器C，将B接口内容转换成A接口，从而使得客户端能够从A接口获取B接口的内容。在软件开发中，基本上任何问题都可以通过增加一个中间层来解决。

组合模式（Composite Pattern）又叫作整体-部分（Part-Whole）模式，它的宗旨是通过将单个对象（叶子节点）和组合对象（树枝节点）用相同的接口进行表示，使得客户对单个对象和组合对象的使用具有一致性，属于结构型设计模式。组合模式一般用来描述整体与部分的关系，它将对象组织到树形结构中，顶层的节点被称为根节点，根节点下面可以包含树枝节点和叶子节点，树枝节点下面又可以包含树枝节点和叶子节点。。

享元模式（Flyweight Pattern）又叫作轻量级模式，是对象池的一种实现。类似线程池，线程池可以避免不停地创建和销毁多个对象，消耗性能。享元模式提供了减少对象数量从而改善应用所需的对象结构的方式。其宗旨是共享细粒度对象，将多个对同一对象的访问集中起来，不必为每个访问者都创建一个单独的对象，以此来降低内存的消耗，属于结构型设计模式。

装饰器模式（Decorator Pattern）也叫作包装器模式（Wrapper Pattern），指在不改变原有对象的基础上，动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活，属于结构型设计模式。装饰器模式提供了比继承更有弹性的替代方案（扩展原有对象的功能）将功能附加到对象上。因此，装饰器模式的核心是功能扩展。使用装饰器模式可以透明且动态地扩展类的功能。

门面模式（Facade Pattern）又叫作外观模式，提供了一个统一的接口，用来访问子系统中的一群接口。其主要特征是定义了一个高层接口，让子系统更容易使用，属于结构型设计模式。在日常编码工作中，我们都在有意无意地大量使用门面模式。但凡只要高层模块需要调度多个子系统（2个以上类对象），我们都会自觉地创建一个新类封装这些子系统，提供精简的接口，让高层模块可以更加容易地间接调用这些子系统的功能。尤其是现阶段各种第三方SDK、开源类库，很大概率都会使用门面模式。大家觉得调用方便的，一般门面模式使用得更多。

代理模式（Proxy Pattern）指为其他对象提供一种代理，以控制对这个对象的访问，属于结构型设计模式。在某些情况下，一个对象不适合或者不能直接引用另一个对象，而代理对象可以在客户端与目标对象之间起到中介的作用。

建造者模式（Builder Pattern）将一个复杂对象的构建过程与它的表示分离，使得同样的构建过程可以创建不同的表示，属于创建型设计模式。对于用户而言，使用建造者模式只需指定需要创建的类型就可以获得对象，创建过程及细节不需要了解。根据建造者模式的定义，可以简单地理解为两层含义。（1）构建与表示分离：构建代表对象创建，表示代表对象行为、方法，也就是将对象的创建与行为进行分离（对应到Java代码，其实就是使用接口规定行为，然后由具体的实现类进行构建）。

原型模式（Prototype Pattern）指原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象，属于创建型设计模式。原型模式的核心在于复制原型对象。以系统中已存在的一个对象为原型，直接基于内存二进制流进行复制，不需要再经历耗时的对象初始化过程（不调用构造函数），性能提升许多。当对象的构建过程比较耗时时，可以把当前系统中已存在的对象作为原型，对其进行复制（一般是基于二进制流的复制），躲避初始化过程，使得新对象的创建时间大大缩短。

单例模式（Singleton Pattern）指确保一个类在任何情况下都绝对只有一个实例，并提供一个全局访问点，属于创建型设计模式。单例模式在现实生活中的应用非常广泛，例如公司CEO、部门经理等都属于单例模型。J2EE标准中的ServletContext和ServletContextConfig、Spring框架应用中的ApplicationContext、数据库中的连接池等也都是单例模式。对于Java来说，单例模式可以保证在一个JVM中只存在单一实例。单例模式的应用场景主要有以下几个方面。

抽象工厂模式（Abstract Factory Pattern）指提供一个创建一系列相关或相互依赖对象的接口，无须指定它们具体的类。意思是客户端不必指定产品的具体类型，创建多个产品族中的产品对象。与工厂方法模式相比，抽象工厂模式可以创建一组相关的对象，而不是单一的对象。在抽象工厂模式中，客户端（应用层）不依赖产品类实例如何被创建、实现等细节，强调一系列相关的产品对象（属于同一产品族）一起创建对象，需要大量重复的代码。需要提供一个产品类的库，所有产品以同样的接口出现，从而使客户端不依赖具体实现。

工厂方法模式（Factory Method Pattern）又叫作多态性工厂模式，指定义一个创建对象的接口，但由实现这个接口的类来决定实例化哪个类，工厂方法把类的实例化推迟到子类中进行。工厂方法模式主要适用于以下应用场景。（1）创建对象需要大量重复的代码。（2）客户端（应用层）不依赖产品类实例如何被创建、实现等细节。（3）一个类通过其子类来指定创建哪个对象。

简单工厂模式（Simple Factory Pattern）又叫作静态工厂方法模式（Static Factory Method Pattern），简单来说，简单工厂模式有一个具体的工厂类，可以生成多个不同的产品，属于创建型设计模式。简单工厂模式不在GoF 23种设计模式之列。对于产品种类相对较少的情况，考虑使用简单工厂模式可以很方便地创建所需产品。使用简单工厂模式的客户端只需要传入工厂类的参数，不需要关心如何创建对象的逻辑。

设计模式，即Design Patterns，是指在软件设计中，被反复使用的一种代码设计经验。使用设计模式的目的是为了可重用代码，提高代码的可扩展性和可维护性。设计模式这个术语是上个世纪90年代由Erich Gamma、Richard Helm、Raplh Johnson和Jonhn Vlissides四个人总结提炼出来的，并且写了一本Design Patterns的书。这四人也被称为四人帮（GoF）。为什么要使用设计模式？

本来很不想总结这几大原则，担心初学者一看就想放弃，但是这些所谓的原则又是设计模式设计的理论支撑，我们在学习设计模式之前，只需要“走马观花”的了解一下这部分内容。等我们熟练了设计模式的套路之后，再反过来仔细阅读这几大原则，这样就会有的确是这样的感悟。设计原则一句话归纳目的开闭原则对扩展开放，对修改关闭降低维护带来的新风险依赖倒置原则高层不应该依赖低层更利于代码结构的升级扩展单一责任原则一个类只干一件事便于理解，提高代码的可读性接口隔离原则一个接口只干一件事功能解耦，高内聚，低耦合。