设计模式总结

1 简述设计模式七大原则

• 开放封闭原则：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。
• 单一职责原则：一个类、接口或方法只负责一个职责，降低代码复杂度以及变更引起的风险。
• 依赖倒置原则：高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。抽象不应该依赖于具体实现，具体实现应该依赖于抽象。
• 接口隔离原则：将不同功能定义在不同接口中实现接口隔离。
• 里氏替换原则：任何基类可以出现的地方，子类一定可以出现。
• 迪米特原则：每个模块对其他模块都要尽可能少地了解和依赖，降低代码耦合度。
• 合成复用原则：尽量使用组合(has-a) / 聚合(contains-a)而不是继承(is-a)达到软件复用的目的。

2 简述设计模式的分类

创建型模式：在创建对象的同时隐藏创建逻辑，不使用 new 直接实例化对象。

• 单例模式
• 工厂模式
• 抽象工厂模式
• 建造者模式
• 原型模式

结构型模式：通过类和接口间的继承和引用实现创建复杂结构的对象。

• 适配器模式
• 桥接模式
• 装饰模式
• 组合模式
• 外观模式
• 享元模式
• 代理模式

行为型模式：通过类之间不同通信方式实现不同行为。

• 模板方法模式
• 命令模式
• 迭代器模式
• 观察者模式
• 中介者模式
• 备忘录模式
• 接解释器模式
• 状态模式
• 策略模式
• 职责链模式
• 访问者模式

3 常用的设计模式

单例模式：单例模式便是创建型设计模式的一种，它确保某一个类在系统中只有一个实例，并自行实例化，同时向外部提供获取这个唯一实例的接口。

• 单例类只有一个实例。
• 单例类必须自己实例化自己。
• 单例类需要向外提供实例。

工厂模式： 定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类，实现了创建者和调用者的分离。

使用场景：

• jdbc连接数据库，硬件访问，降低对象的产生和销毁

抽象工厂模式：为创建一组相关或相互依赖的对象提供一个接口，而且无须指定它们的具体类。

使用场景：

• 客户端不依赖于产品类实例如何被创建、实现等细节。
• 强调一系列相关的产品对象（属于同一产品族）一起使用创建对象需要大量的重复代码。
• 提供一个产品类的库，所有的产品以同样的接口出现，从而使得客户端不依赖于具体的实现。

优点：

• 具体产品在应用层的代码隔离，无需关心创建的细节。
• 将一个系列的产品统一到一起创建。

建造者模式：建造者模式也属于创建型模式，他提供了一种创建对象的最佳方式。将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

• 在用户不知道对象的建造过程和细节的情况下就可以直接创建复杂的对象。用户只需要给出指定复杂对象的类型和内容，建造者模式负责按顺序创建复杂对象（把内部的创建过程和细节隐藏起来）。

优点：

• 产品的建造和表示分离，实现了解耦。
• 将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰。
• 具体的建造者类之间是相互独立的，这有利于系统的扩展。增加新的具体建造者无需修改原有类库的代码，符合开闭原则。

缺点：

• 创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间差异性很大，不适用于建造者模式。

应用场景：

• 需要生成的产品对象有复杂的内部结构，这些产品对象具备共性。

• 隔离复杂对象的创建和使用，并使得相同的创建过程可以创建不同的产品。

• 适合于一个具有较多的零件(属性)的产品(对象)的创建过程。

建造者与抽象工厂模式的比较：

• 与抽象工厂模式相比，建造者模式返回一个组装好的完整产品，而抽象工厂模式返回一系列相关的产品，这些产品位于不同的产品等级结构，构成了一个产品族。
• 在抽象工厂模式中，客户端实例化工厂类,然后调用工厂方法获取所需产品对象，而在建造者模式中，客户端可以不直接调用建造者的相关方法，而是通过指挥者类来指导如何生成对象，包括对象的组装过程和建造步骤，它侧重于一步步构造一个复杂对象，返回一个完整的对象。
• 如果将抽象工厂模式看成汽车配件生产工厂，生产一个产品族的产品，那么建造者模式就是一个汽车组装工厂，通过对部件的组装可以返回一辆完整的汽车。

原型模式：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。原型模式实际上就是实现Cloneable接口，重写clone（）方法。

优点：

• 性能优良
• 逃避构造函数的约束

使用场景：

• 性能和安全要求的场景，通过new产生一个对象需要非常繁琐的数据准备或访问权限，则可以使用原型模式。
• 一个对象多个修改者的场景 一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式拷贝多个对象供调用者使用。

适配器模式： 将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。

主要可分为 3 种：

• 类适配：创建新类，继承源类，并实现新接口，例如 class adapter extends oldClass implements newFunc{}
• 对象适配：创建新类持源类的实例，并实现新接口，例如 class adapter implements newFunc { private oldClass oldInstance ;}
• 接口适配：创建新的抽象类实现旧接口方法。例如 abstract class adapter implements oldClassFunc { void newFunc();}

使用场景：

• 你有动机修改一个已经投产中的接口时，适配器模式可能是适合你的模式。比如系统扩展了，需要使用一个已有或新建立的类，但这个类又不符合系统的接口，怎么办？使用适配器模式。

装饰器模式：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活 。

使用场景：

• 1. 需要扩展一个类的功能，或给一个类增加附加功能。
• 2. 需要动态地给一个对象增加功能，这些功能可以再动态地撤销。
• 3. 需要为一批的兄弟类进行改装或加装功能，当然是首选装饰模式。

代理模式：为其他对象提供一种代理以控制对这个对象的访问。

角色分析：

• 抽象角色：一般使用接口或者抽象类来解决。
• 真实角色：被代理的角色。
• 代理角色：代理真实角色，代理真实角色后，我们一般会做一些附属操作。
• 客户：访问代理对象的人。

中介者模式：用一个中介对象封装一系列的对象交互，中介者使各对象不需要 显示地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

使用场景：

• 中介者模式适用于多个对象之间紧密耦合的情况，紧密耦合的标准是：在类图中出现了蜘蛛网状结构，即每个类都与其他的类有直接的联系。

命令模式：将一个请求封装成一个对象，从而让你使用不同的请求把客户端 参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。

• Receiver接受者角色：该角色就是干活的角色，命令传递到这里是应该被执行的。
• Command命令角色：需要执行的所有命令都在这里声明。
• Invoker调用者角色：接收到命令，并执行命令。

使用场景：

• 认为是命令的地方就可以采用命令模式，例如，在GUI开发中，一个按钮的点击是一个命令，可以采用命令模式；模拟DOS命令的时候，当然也要采用命令模式；触发－反馈机制的处理等。

责任链模式：使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。

策略模式 ： 定义一组算法，将每个算法都封装起来，并且使它们之间可以互换替换。

使用场景：

• 1. 多个类只有在算法或行为上稍有不同的场景。
• 2. 算法需要自由切换的场景。
• 3. 需要屏蔽算法规则的场景。

迭代器模式：它提供一种方法访问一个容器对象中各个元素，而又不需暴露该对象的内部细节。迭代器模式已经被淘汰，java中已经把迭代器运用到各个聚集类（collection）中了，使用java自带的迭代器就已经满足我们的需求了。

组合模式：将对象组合成树形结构以表示 “ 部分 - 整体 ” 的层次结构，使得用户对单个对象和组合对象的使用具有一致性。

使用场景：

• 1. 维护和展示部分-整体关系的场景，如树形菜单、文件和文件夹管理。
• 2. 从一个整体中能够独立出部分模块或功能的场景。

观察者 模式：定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。

使用场景：

• 1. 关联行为场景。需要注意的是，关联行为是可拆分的，而不是“组合”关系。
• 2. 事件多级触发场景。
• 3. 跨系统的消息交换场景，如消息队列的处理机制。

门面模式：要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。

使用场景：

• 1. 为一个复杂的模块或子系统提供一个供外界访问的接口。
• 2. 子系统相对独立——外界对子系统的访问只要黑箱操作即可。
• 3. 预防低水平人员带来的风险扩散。

备忘录模式：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。

使用场景：

• 1. 需要保存和恢复数据的相关状态场景。
• 2. 提供一个可回滚（rollback）的操作。
• 3. 需要监控的副本场景中。
• 4. 数据库连接的事务管理就是用的备忘录模式。

访问者模式：封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。

使用场景：

• 1. 一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作，也就说是用迭代器模式已经不能胜任的情景。
• 2. 需要对一个对象结构中的对象进行很多不同并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。

状态模式：当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类。

使用场景：

• 1. 行为随状态改变而改变的场景这也是状态模式的根本出发点，例如权限设计，人员的状态不同即使执行相同的行为结果也会不同，在这种情况下需要考虑使用状态模式。
• 2. 条件、分支判断语句的替代者。

解释器模式：给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。

使用场景：

• 1. 重复发生的问题可以使用解释器模式。
• 2. 一个简单语法需要解释的场景。

享元模式：使用共享对象的方法，用来尽可能减少内存使用量以及分享资讯。

使用场景：

• 1. 系统中存在大量的相似对象。
• 2. 细粒度的对象都具备较接近的外部状态，而且内部状态与环境无关，也就是说对象没有特定身份。
• 3. 需要缓冲池的场景。

桥梁模式：将抽象和实现解耦，使得两者可以独立地变化。

使用场景：

• 1. 不希望或不适用使用继承的场景。
• 2. 接口或抽象类不稳定的场景。
• 3. 重用性要求较高的场景。

模板方法模式：定义一个操作中的算法的框架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

使用场景：

• 1. 多个子类有公有的方法，并且逻辑基本相同时。
• 2. 重要、复杂的算法，可以把核心算法设计为模板方法，周边的相关细节功能则由各个子类实现。
• 3. 重构时，模板方法模式是一个经常使用的模式，把相同的代码抽取到父类中，然后通过钩子函数（见“模板方法模式的扩展”）约束其行为。