设计模式的基本原则

设计模式

设计模式的世界丰富多彩，比如生产一个个「产品」的工厂模式，衔接两个不相关接口的适配器模式，用不同的方式做同一件事的策略模式，构建步骤稳定、根据构建过程的不同配置构建出不同对象的建造者模式等。

面向对象结合设计模式，才能真正体会到程序变得可维护、可复用、可扩展、灵活性好。设计模式对于程序员而言并不陌生，每个程序员在编程时都会或多或少地接触到设计模式。无论是在大型程序的架构中，亦或是在源码的学习中，设计模式都扮演着非常重要的角色。

设计模式基于六大原则

• 开闭原则：一个软件实体如类、模块和函数应该对修改封闭，对扩展开放。
• 单一职责原则：一个类只做一件事，一个类应该只有一个引起它修改的原因。
• 里氏替换原则：子类应该可以完全替换父类。也就是说在使用继承时，只扩展新功能，而不要破坏父类原有的功能。
• 依赖倒置原则：细节应该依赖于抽象，抽象不应依赖于细节。把抽象层放在程序设计的高层，并保持稳定，程序的细节变化由低层的实现层来完成。
• 迪米特法则：又名「最少知道原则」，一个类不应知道自己操作的类的细节，换言之，只和朋友谈话，不和朋友的朋友谈话。
• 接口隔离原则：客户端不应依赖它不需要的接口。如果一个接口在实现时，部分方法由于冗余被客户端空实现，则应该将接口拆分，让实现类只需依赖自己需要的接口方法。
•  

所有的设计模式都是为了程序能更好的满足这六大原则。设计模式一共有 23 种

创建型模式

创建型模式的主要关注点是“怎样创建对象？”，它的主要特点是“将对象的创建与使用分离”。这样可以降低系统的耦合度，使用者不需要关注对象的创建细节，对象的创建由相关的工厂来完成。就像我们去商场购买商品时，不需要知道商品是怎么生产出来一样，因为它们由专门的厂商生产。

• 简单工厂模式：也叫静态工厂方法，直接new也给对象。
• 工厂方法模式：定义一个用于创建产品的接口，由子类决定生产什么产品。
• 抽象工厂模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
• 单例模式/多例模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
• 建造型模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。
• 对象池模式：使用一组保持随时可用的初始化对象（“池”），而不是按需分配和销毁它们
• 原型模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
   

结构型模式

结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式，前者采用继承机制来组织接口和类，后者釆用组合或聚合来组合对象。

由于组合关系或聚合关系比继承关系耦合度低，满足“合成复用原则”，所以对象结构型模式比类结构型模式具有更大的灵活性。

• 适配器模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
• 装饰器模式：动态地给对象增加一些职责，即增加其额外的功能。
• 组合模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。
• 桥接模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现的，从而降低了抽象和实现这两个可变维度的耦合度。
• 数据映射模式：数据映射器是一种数据访问层，它执行持久性数据存储（通常是关系数据库）和内存数据表示（域层）之间的数据双向传输。
• 门面模式/外观模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
• 注册模式：能够存储在应用程序中经常使用的对象实例
• 依赖注入模式：用松散耦合的方式来更好的实现可测试、可维护和可扩展的代码
• 代理模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
• 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。
• 流接口模式（Fluent Interface）：用来编写易于阅读的代码，就像自然语言一样（如英语

对象池模式、多例模式、享元模式的比较

就设计目的而言，多例模式就如单例一样，纯粹是为了控制实例数量，使用这种模式的类，通常是作为程序某个模块的入口。

享元和对象池的设计目的相近，主要是为了节省系统资源，它们维护和共享的通常是某种资源。

享元模式是结构型模式。这意味着，它的侧重点是对象之间的衔接。它把动态的、会变化的状态剥离，外部化，共享不变的东西。但是这部分外部化的东西和享元模式内部共享的不会变的东西之间存在关联。所以享元对外提供的接口常常会包含一个String类型的参数，表示key、名称之类。

而对象池是构造型模式，侧重于提供对象实例。对调用者而言对象池提供的对象都没有区别，这个可以用，那个也可以用。

行为型模式

行为型模式用于描述程序在运行时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，它涉及算法与对象间职责的分配。

行为型模式分为类行为模式和对象行为模式，前者采用继承机制来在类间分派行为，后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低，满足“合成复用原则”，所以对象行为模式比类行为模式具有更大的灵活性。

• 策略模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
• 观察者模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。
• 迭代器模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。
• 责任链模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。
• 命令行模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
• 依赖注入模式：本来我接受各种参数来构造一个对象，现在只接受一个参数——已经实例化的对象。
• 中介者模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。
• 备忘录模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
• 解释器模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。
• 状态模式：允许一个对象在其内部状态发生改变时改变其行为能力。
• 模板方法模式：定义一个操作中的算法骨架，将算法的一些步骤延迟到子类中，使得子类在可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
• 访问者模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。

总结

设计模式在面试中的考点通常是介绍其原理并说出优缺点。或者对比几个比较相似的模式的异同点。在笔试中可能会出现画出某个设计模式的 UML 图这样的题。虽说面试中占的比重不大，但并不代表它不重要。恰恰相反，设计模式于程序员而言相当重要，它是我们写出优秀程序的保障。设计模式与程序员的架构能力与阅读源码的能力息息相关，非常值得我们深入学习。