设计模式

来源：菜鸟教程

创建型——创建对象的同时隐藏创建逻辑的方式。程序在判断针对某个给定实力需要创建哪些对象更加灵活。

• 单例：Singleton：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
  • 解决：当您想控制实例数目，节省系统资源，一个全局使用的类频繁地创建与销毁。
  • 优点：1、在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例（比如管理学院首页页面缓存）。2、避免对资源的多重占用（比如写文件操作）。
  • 缺点：没有接口，不能继承，与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化。
• 工厂：Factory：定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行
  • 解决：明确地计划不同条件下创建不同实例，接口选择的问题。
  • 优点：1、一个调用者想创建一个对象，只要知道其名称就可以了。 2、扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。 3、屏蔽产品的具体实现，调用者只关心产品的接口。
  • 缺点：每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。
• 抽象工厂：Abstract Factory：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。创建对应工厂，工厂依据工厂模式创建对象
  • 解决：系统的产品有多于一个的产品族，而系统只消费其中某一族的产品。接口选择的问题。
  • 优点：当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。
  • 缺点：产品族扩展非常困难，要增加一个系列的某一产品，既要在抽象的 Creator 里加代码，又要在具体的里面加代码。
• 建造者: Builder：将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。
  • 解决：在软件系统中，有时候面临着"一个复杂对象"的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。一些基本部件不会变，而其组合经常变化的时候。
  • 优点：1、建造者独立，易扩展。 2、便于控制细节风险。
  • 缺点：、产品必须有共同点，范围有限制。 2、如内部变化复杂，会有很多的建造类。
• 原型：Prototype：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
  • 解决：在运行期建立和删除原型。利用已有的一个原型对象，快速地生成和原型对象一样的实例。
  • 优点：1、性能提高。 2、逃避构造函数的约束。
  • 缺点：1、配备克隆方法需要对类的功能进行通盘考虑，这对于全新的类不是很难，但对于已有的类不一定很容易，特别当一个类引用不支持串行化的间接对象，或者引用含有循环结构的时候。 2、必须实现 Cloneable 接口。

结构型——关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式

• 适配器：Adapter：将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
  • 解决：主要解决在软件系统中，常常要将一些"现存的对象"放到新的环境中，而新环境要求的接口是现对象不能满足的。
  • 优点：1、可以让任何两个没有关联的类一起运行。 2、提高了类的复用。 3、增加了类的透明度。 4、灵活性好。
  • 缺点：1、过多地使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。 2.由于 JAVA 至多继承一个类，所以至多只能适配一个适配者类，而且目标类必须是抽象类。
• 桥接：Bridge：将抽象部分与实现部分分离，使它们都可以独立的变化。
  • 解决：有多种可能会变化的情况下，用继承会造成类爆炸问题，扩展起来不灵活。实现系统可能有多个角度分类，每一种角度都可能变化
  • 优点： 1、抽象和实现的分离。 2、优秀的扩展能力。 3、实现细节对客户透明。
  • 缺点：桥接模式的引入会增加系统的理解与设计难度，由于聚合关联关系建立在抽象层，要求开发者针对抽象进行设计与编程。
• 过滤器：Filter：使用不同的标准来过滤一组对象，通过逻辑运算以解耦的方式把它们连接起来。它结合多个标准来获得单一标准。
• 组合：Composite：将对象组合成树形结构以表示"部分-整体"的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
  • 解决：它在我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以像处理简单元素一样来处理复杂元素，从而使得客户程序与复杂元素的内部结构解耦。1、您想表示对象的部分-整体层次结构（树形结构）2、您希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。
  • 优点：1、高层模块调用简单。 2、节点自由增加。
  • 缺点：在使用组合模式时，其叶子和树枝的声明都是实现类，而不是接口，违反了依赖倒置原则。
• 装饰器：Decorator：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。
  • 解决：一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。在不想增加很多子类的情况下扩展类。
  • 优点：装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。
  • 缺点：多层装饰比较复杂。
• 外观：Facade：为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
  • 解决：降低访问复杂系统的内部子系统时的复杂度，简化客户端之间的接口。1、客户端不需要知道系统内部的复杂联系，整个系统只需提供一个"接待员"即可。 2、定义系统的入口。
  • 优点：1、减少系统相互依赖。 2、提高灵活性。 3、提高了安全性。
  • 缺点：不符合开闭原则，如果要改东西很麻烦，继承重写都不合适。
• 享元：Flyweight：运用共享技术有效地支持大量细粒度的对象。在有大量对象时，有可能会造成内存溢出，我们把其中共同的部分抽象出来，如果有相同的业务请求，直接返回在内存中已有的对象，避免重新创建。
  • 解决：1、系统中有大量对象。 2、这些对象消耗大量内存。 3、这些对象的状态大部分可以外部化。 4、这些对象可以按照内蕴状态分为很多组，当把外蕴对象从对象中剔除出来时，每一组对象都可以用一个对象来代替。 5、系统不依赖于这些对象身份，这些对象是不可分辨的。
  • 优点：大大减少对象的创建，降低系统的内存，使效率提高。
  • 缺点：提高了系统的复杂度，需要分离出外部状态和内部状态，而且外部状态具有固有化的性质，不应该随着内部状态的变化而变化，否则会造成系统的混乱。
• 代理：Proxy：为其他对象提供一种代理以控制对这个对象的访问。
  • 解决：在直接访问对象时带来的问题，比如说：要访问的对象在远程的机器上。在面向对象系统中，有些对象由于某些原因（比如对象创建开销很大，或者某些操作需要安全控制，或者需要进程外的访问），直接访问会给使用者或者系统结构带来很多麻烦，我们可以在访问此对象时加上一个对此对象的访问层。
  • 优点：1、职责清晰。 2、高扩展性。 3、智能化。
  • 缺点：1、由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢。 2、实现代理模式需要额外的工作，有些代理模式的实现非常复杂。

行为型——关注对象间通信

• 责任链：Chain of Responsibility：避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。
  • 解决：职责链上的处理者负责处理请求，客户只需要将请求发送到职责链上即可，无须关心请求的处理细节和请求的传递，所以职责链将请求的发送者和请求的处理者解耦了。在处理消息的时候以过滤很多道。
  • 优点：1、降低耦合度。它将请求的发送者和接收者解耦。 2、简化了对象。使得对象不需要知道链的结构。 3、增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。 4、增加新的请求处理类很方便。
  • 缺点：1、不能保证请求一定被接收。 2、系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。 3、可能不容易观察运行时的特征，有碍于除错。
• 命令：Command：将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化。
  • 解决：在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。
  • 优点： 1、降低了系统耦合度。 2、新的命令可以很容易添加到系统中去。
  • 缺点：使用命令模式可能会导致某些系统有过多的具体命令类。
• 解释器：Interpreter：给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子。
  • 解决：如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。
  • 优点：1、可扩展性比较好，灵活。 2、增加了新的解释表达式的方式。 3、易于实现简单文法。
  • 缺点：1、可利用场景比较少。 2、对于复杂的文法比较难维护。 3、解释器模式会引起类膨胀。 4、解释器模式采用递归调用方法。
• 迭代：Iterator：提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示。
  • 解决：不同的方式来遍历整个整合对象。
  • 优点：1、它支持以不同的方式遍历一个聚合对象。 2、迭代器简化了聚合类。 3、在同一个聚合上可以有多个遍历。 4、在迭代器模式中，增加新的聚合类和迭代器类都很方便，无须修改原有代码。
  • 缺点：由于迭代器模式将存储数据和遍历数据的职责分离，增加新的聚合类需要对应增加新的迭代器类，类的个数成对增加，这在一定程度上增加了系统的复杂性。
• 中介者：Mediator：用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
  • 解决：对象与对象之间存在大量的关联关系，这样势必会导致系统的结构变得很复杂，同时若一个对象发生改变，我们也需要跟踪与之相关联的对象，同时做出相应的处理。
  • 优点： 1、降低了类的复杂度，将一对多转化成了一对一。 2、各个类之间的解耦。 3、符合迪米特原则。
  • 缺点：中介者会庞大，变得复杂难以维护。
• 备忘录：Memento：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
  • 解决：在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。
  • 优点： 1、给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态。 2、实现了信息的封装，使得用户不需要关心状态的保存细节。
  • 缺点：消耗资源。如果类的成员变量过多，势必会占用比较大的资源，而且每一次保存都会消耗一定的内存。
• 观察者：Observer：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
  • 解决：一个对象状态改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。
  • 优点：1、观察者和被观察者是抽象耦合的。 2、建立一套触发机制。
  • 缺点： 1、如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。 2、如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。 3、观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。
• 状态：State：允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。
  • 解决：对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。
  • 优点：1、封装了转换规则。 2、枚举可能的状态，在枚举状态之前需要确定状态种类。 3、将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。 4、允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。 5、可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。
  • 缺点： 1、状态模式的使用必然会增加系统类和对象的个数。 2、状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。 3、状态模式对"开闭原则"的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需修改对应类的源代码。
• 空对象：Null：Object创建一个指定各种要执行的操作的抽象类和扩展该类的实体类，还创建一个未对该类做任何实现的空对象类，该空对象类将无缝地使用在需要检查空值的地方
• 策略：Strategy：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。
  • 解决：在有多种算法相似的情况下，使用 if...else 所带来的复杂和难以维护。
  • 优点： 1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。
  • 缺点：1、策略类会增多。 2、所有策略类都需要对外暴露。
• 模板：Template：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤
  • 解决：一些方法通用，却在每一个子类都重新写了这一方法。
  • 优点：1、封装不变部分，扩展可变部分。 2、提取公共代码，便于维护。 3、行为由父类控制，子类实现。
  • 缺点：每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。
• 访问者：Visitor：主要将数据结构与数据操作分离。
  • 解决：需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作"污染"这些对象的类，使用访问者模式将这些封装到类中。
  • 优点： 1、符合单一职责原则。 2、优秀的扩展性。 3、灵活性。
  • 缺点：1、具体元素对访问者公布细节，违反了迪米特原则。 2、具体元素变更比较困难。 3、违反了依赖倒置原则，依赖了具体类，没有依赖抽象

j2EE——

• MVC：Model（模型）模型代表一个存取数据的对象或 JAVA POJO。它也可以带有逻辑，在数据变化时更新控制器。View（视图）视图代表模型包含的数据的可视化。Controller（控制器）控制器作用于模型和视图上。它控制数据流向模型对象，并在数据变化时更新视图。它使视图与模型分离开。

• 业务代表：Business Delegate：用来减少通信或对表示层代码中的业务层代码的远程查询功能。在业务层中我们有以下实体。

  • 客户端（Client）表示层代码可以是 JSP、servlet 或 UI java 代码。
  • 业务代表（Business Delegate）一个为客户端实体提供的入口类，它提供了对业务服务方法的访问。
  • 查询服务（LookUp Service）查找服务对象负责获取相关的业务实现，并提供业务对象对业务代表对象的访问。
  • 业务服务（Business Service）业务服务接口。实现了该业务服务的实体类，提供了实际的业务实现逻辑。

• 组合实体：Composite Entity

  • 组合实体（Composite Entity）它是主要的实体 bean。它可以是粗粒的，或者可以包含一个粗粒度对象，用于持续生命周期。
  • 粗粒度对象（Coarse-Grained Object）该对象包含依赖对象。它有自己的生命周期，也能管理依赖对象的生命周期。
  • 依赖对象（Dependent Object）依赖对象是一个持续生命周期依赖于粗粒度对象的对象。
  • 策略（Strategies）策略表示如何实现组合实体。

• 数据访问对象：Data Access Object

  • 数据访问对象接口（Data Access Object Interface）该接口定义了在一个模型对象上要执行的标准操作。
  • 数据访问对象实体类（Data Access Object concrete class）该类实现了上述的接口。该类负责从数据源获取数据，数据源可以是数据库，也可以是 xml，或者是其他的存储机制。
  • 模型对象/数值对象（Model Object/Value Object）该对象是简单的 POJO，包含了 get/set 方法来存储通过使用 DAO 类检索到的数据。

• 前端控制器：Front Controller

  • 前端控制器（Front Controller）处理应用程序所有类型请求的单个处理程序，应用程序可以是基于 web 的应用程序，也可以是基于桌面的应用程序。
  • 调度器（Dispatcher）前端控制器可能使用一个调度器对象来调度请求到相应的具体处理程序。
  • 视图（View）视图是为请求而创建的对象。

• 拦截过滤器：Intercepting Filter

  • 过滤器（Filter）过滤器在请求处理程序执行请求之前或之后，执行某些任务。
  • 过滤器链（Filter Chain）过滤器链带有多个过滤器，并在 Target 上按照定义的顺序执行这些过滤器。
  • Target Target 对象是请求处理程序。
  • 过滤管理器（Filter Manager）过滤管理器管理过滤器和过滤器链。
  • 客户端（Client）Client 是向 Target 对象发送请求的对象。

• 服务定位器：Service Locator

  • 服务（Service）实际处理请求的服务。对这种服务的引用可以在 JNDI 服务器中查找到。
  • Context / 初始的 Context JNDI Context 带有对要查找的服务的引用。
  • 服务定位器（Service Locator）服务定位器是通过 JNDI 查找和缓存服务来获取服务的单点接触。
  • 缓存（Cache）缓存存储服务的引用，以便复用它们。
  • 客户端（Client）Client 是通过 ServiceLocator 调用服务的对象。

• 传输对象：Transfer Object

  • 业务对象（Business Object）为传输对象填充数据的业务服务。
  • 传输对象（Transfer Object）简单的 POJO，只有设置/获取属性的方法。
  • 客户端（Client）客户端可以发送请求或者发送传输对象到业务对象。

六大原则：

• 开闭原则：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。【需要使用接口和抽象类】
• 里氏代换原则：任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充
• 依赖倒转原则：针对接口编程，依赖于抽象而不依赖于具体
• 接口隔离原则：使用多个隔离的接口，比使用单个接口要好。【调降低依赖，降低耦合】
• 狄米特原则（最少知道）：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立
• 合成复用原则：尽量使用合成/聚合的方式，而不是使用继承