在软件开发中，为了提高软件系统的可维护性和可复用性，增加软件的可扩展性和灵活性，程序员要尽量根据一些原则来开发程序，从而提高软件开发效率、节约软件开发成本和维护成本。
我们常见有 7 条原则，设计模式之禅这本书中概括为6原则，我们本博客就以7原则来进行说明：
- 开闭原则
- 单一职责原则
- 里氏替换原则
- 依赖倒转原则
- 接口隔离原则
- 迪米特法则
- 合成复用原则
一、开闭原则 OCP
开闭原则（Open Closed Principle，OCP）由勃兰特・梅耶（Bertrand Meyer）提出，他在 1988 年的著作《面向对象软件构造》（Object Oriented Software Construction）中提出：软件实体应当对扩展开放，对修改关闭（Software entities should be open for extension，but closed for modification），这就是开闭原则的经典定义。
开闭原则的意思就是说，你设计的时候，时刻要考虑，尽量让这个类是足够好，写好了就不要去修改了，如果新需求来，我们增加一些类就完事了，原来的代码能不动则不动。
这个原则有两个特性:
- 一个是说对于扩展是开放的
- 一个是说对于更改是封闭的
想要达到这样的效果，我们需要使用接口和抽象类，如示例：设计模式之开闭原则示例
二、里氏替换原则 LSP
里氏替换原则（Liskov Substitution Principle，LSP）由麻省理工学院计算机科学实验室的里斯科夫（Liskov）女士在 1987 年的“面向对象技术的高峰会议”（OOPSLA）上发表的一篇文章《数据抽象和层次》（Data Abstraction and Hierarchy）里提出来的。里氏替换原则主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承。强调的是设计和实现要依赖于抽象而非具体；子类只能去扩展基类，而不是隐藏或者覆盖基类。
里氏替换原则的官方定义
- 如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型
-
所有引用基类的地方必须能透明地使用其子类的对象
核心表达的是：父类出现的地方子类都可以出现并替换且程序运行不会出错，如示例：设计模式之里氏替换原则示例
三、依赖倒置原则 DIP
依赖倒置原则（Dependence Inversion Principle）是面向对象设计原则的一种。依赖倒置原则指的是高层模块(稳定)不应该依赖于低层模块(变化)，二者都应该依赖于抽象(稳定)。抽象(稳定)不应该依赖于实现细节(变化)，实现细节应该依赖于抽象(稳定)。
依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。
依赖、倒置原则的作用
依赖倒置原则的主要作用如下。
- 依赖倒置原则可以降低类间的耦合性。
- 依赖倒置原则可以提高系统的稳定性。
- 依赖倒置原则可以减少并行开发引起的风险。
- 依赖倒置原则可以提高代码的可读性和可维护性。
依赖倒置原则的实现方法
依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性，所以我们在实际编程中只要遵循以下4点，就能在项目中满足这个规则。
- 每个类尽量提供接口或抽象类，或者两者都具备。
- 变量的声明类型尽量是接口或者是抽象类。
- 任何类都不应该从具体类派生。
- 使用继承时尽量遵循里氏替换原则。
依赖倒置原则的核心就是要我们面向接口编程，理解了面向接口编程，也就理解了依赖倒置。如示例：设计模式之依赖倒置原则示例
四、单一职责原则 SRP
单一职责原则(Single Responsibility Principle)是面向对象设计原则的一种。单一职责原则是指不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。
该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：
- 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；
- 当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。
单一职责原则的优点
单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点。
- 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
- 提高类的可读性。复杂性降低，自然其可读性会提高。
- 提高系统的可维护性。可读性提高，那自然更容易维护了。
- 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。
单一职责原则的实现方法
单一职责原则是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中。
五、接口隔离原则 ISP
接口分离原则（Interface Segregation PrincipleISP）是面向对象设计原则的一种，也叫接口隔离原则。接口分离原则指在设计时采用多个与特定客户类有关的接口比采用一个通用的接口要好。即，一个类要给多个客户使用，那么可以为每个客户创建一个接口，然后这个类实现所有的接口；而不要只创建一个接口，其中包含所有客户类需要的方法，然后这个类实现这个接口。
接口分离原则是什么
- 定义一：客户端不应该依赖它不需要的接口
- 定义二：类间的依赖关系应该建立在最小的接口上
也就是说一个类对另一个类的依赖应该建立在最小的接口上,通俗的讲就是需要什么就提供什么，不需要的就不要提供。接口中的方法应该尽量少，不要使接口过于臃肿，不要有很多不相关的逻辑方法。
接口分离原则好处
- 高内聚，低耦合
- 可读性高，易于维护
接口隔离和单一职责区别
很多人会觉的接口隔离原则跟之前的单一职责原则很相似，其实不然。
- 单一职责原则原注重的是职责；而接口隔离原则注重对接口依赖的隔离。
-
单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口隔离原则主要约束接口接口，主要针对抽象，针对程序整体框架的构建。
采用接口隔离原则对接口进行约束时，要注意以下几点：
- 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度
- 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系
- 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情
运用接口隔离原则，一定要适度，接口设计的过大或过小都不好。如示例：设计模式之接口隔离原则示例
六、迪米特法则 LoD
迪米特原则(Law of Demeter, LoD)是面向对象设计原则的一种，也叫最少知道原则。迪米特原则是1987年秋天由lan holland在美国东北大学一个叫做迪米特的项目设计提出的，它要求一个对象应该对其他对象有最少的了解，所以迪米特法则又叫做最少知识原则。
迪米特原则问题由来
迪米特原则目的是尽量降低类与类之间的耦合。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
迪米特原则优点
- 使得软件更好的可维护性与适应性
- 对象较少依赖其它对象的内部结构，可以改变对象容器（container）而不用改变它的调用者（caller）
迪米特原则通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。如示例：设计模式之迪米特法则示例
七、合成复用原则CRP
合成复用原则（Composite Reuse Principle，CRP）又叫组合/聚合复用原则（Composition/Aggregate Reuse Principle，CARP）。它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。
如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。
什么是合成复用
尽量采用组合(contains-a)、聚合(has-a)的方式而不是继承(is-a)的关系来达到软件的复用目的。组合/聚合复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。 原则是尽量首先使用合成 / 聚合的方式，而不是使用继承。
合成和聚合都是关联的特殊种类。合成是值的聚合（Aggregation by Value），而聚合是引用的聚合（Aggregation by Reference）。都知道，类之间有三种基本关系，分别是：关联（聚合和组合）、泛化（与继承同一概念）、依赖。
关联关系包括两种特例：聚合和组合。
- 聚合，用来表示整体与部分的关系或者 “拥有” 关系。其中，代表部分的对象可能会被代表多个整体的对象所拥有，但是并不一定会随着整体对象的销毁而销毁，部分的生命周期可能会超越整体。好比班级和学生，班级销毁或解散后学生还是存在的，学生可以继续存在某个培训机构或步入社会，生命周期不同于班级甚至大于班级。
- 合成，用来表示一种强得多的 “拥有” 关系。其中，部分和整体的生命周期是一致的，一个合成的新的对象完全拥有对其组成部分的支配权，包括创建和泯灭。好比人的各个器官组成人一样，一旦某个器官衰竭，人也不复存在，这是一种 “强” 关联。
组合/聚合复用原则好处
- 可以降低类与类之间的耦合程度
- 提高了系统的灵活性
合成复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。如示例：设计模式之合成复用原则示例
八、常用设计模式分类
1、创建型模式
创建型模式的主要关注点是“怎样创建对象？”，它的主要特点是“将对象的创建与使用分离”。这样可以降低系统的耦合度，使用者不需要关注对象的创建细节，对象的创建由相关的工厂来完成。就像我们去商场购买商品时，不需要知道商品是怎么生产出来一样，因为它们由专门的厂商生产。
创建型模式分为以下几种。
- 单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
- 原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
- 工厂方法（FactoryMethod）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。
- 抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
- 建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。
以上 5 种创建型模式，除了工厂方法模式属于类创建型模式，其他的全部属于对象创建型模式。
2、结构型模式
结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式，前者采用继承机制来组织接口和类，后者釆用组合或聚合来组合对象。
由于组合关系或聚合关系比继承关系耦合度低，满足“合成复用原则”，所以对象结构型模式比类结构型模式具有更大的灵活性。结构型模式分为以下 7 种：
- 代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
- 适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
- 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现的，从而降低了抽象和实现这两个可变维度的耦合度。
- 装饰（Decorator）模式：动态地给对象增加一些职责，即增加其额外的功能。
- 外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
- 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。
- 组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。
以上 7 种结构型模式，除了适配器模式分为类结构型模式和对象结构型模式两种，其他的全部属于对象结构型模式
3、行为型模式
行为型模式用于描述程序在运行时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，它涉及算法与对象间职责的分配。
行为型模式分为类行为模式和对象行为模式，前者采用继承机制来在类间分派行为，后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低，满足“合成复用原则”，所以对象行为模式比类行为模式具有更大的灵活性。
行为型模式是 GoF 设计模式中最为庞大的一类，它包含以下 11 种模式。
- 模板方法（Template Method）模式：定义一个操作中的算法骨架，将算法的一些步骤延迟到子类中，使得子类在可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
- 策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
- 命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
- 职责链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。
- 状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。
- 观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。
- 中介者（Mediator）模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。
- 迭代器（Iterator）模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。
- 访问者（Visitor）模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。
- 备忘录（Memento）模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
- 解释器（Interpreter）模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。
以上 11 种行为型模式，除了模板方法模式和解释器模式是类行为型模式，其他的全部属于对象行为型模式。