设计原则

面向对象特性：

• 抽象：对业务的建模，对架构的宏观掌控；
• 封装：维护性，对象功能内聚，模块耦合变低；
• 继承：复用性，子类继承父类的方法；
• 多态：扩展性，指覆盖（override），子类覆写父类的方法；

单一职责原则（SRP）

Single Responsbility Principle：一个类更改的原因不应超过一个。

高内聚

• 事实上，由于一些其他的因素影响，类的单一职责在项目中是很难保证的；
• 通常，接口和方法的单一职责更容易实现。

开放封闭原则（OCP）

Open Close Principle：一个软件实体，如类、模块和函数，对扩展开放，对修改关闭。（只加不改）

• 一个软件实体如类，模块和函数应该对扩展开放（对于提供方来说），对修改关闭（对于使用方来说）;
• 用抽象构建框架，用实现扩展细节；
• 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

里氏替换原则（LSP）

Liskov ubstitution Principle：如果S是T的子类型，对于S类型的任意对象，如果将他们看作是T类型的对象，则对象的行为也理应与期望的行为一致。

所有引用基类的地方必须能透明地使用其子类的对象

• 子类实现父类方法时，不能违反父类对于方法的定义说明，如抛出基类未定义的异常，改变函数语义等；

迪米特法则（Lod）

Law of Demeter：只与你的直接朋友交谈，不跟“陌生人”说话。（最小知识原则）

强调以下两点：

• 从依赖者的角度来说，只依赖应该依赖的对象。
• 从被依赖者的角度说，只暴露应该暴露的方法。

在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。

优点：

• 避免客户端代码将与查找过程中的链条结构紧密耦合，一旦链条间的任何对象发生变化，客户端就不得不做出相应修改这样的话无形中增加了开发成本。

缺点

• 在系统里造出大量的小方法（中介类），这些方法仅仅是传递间接的调用，与系统的业务逻辑无关。

接口隔离原则（ISP）

Interface Segregation Principle：针对接口编程

要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

• 客户端不应该依赖它不需要的接口。
• 类间的依赖关系应该建立在最小的接口上

依赖倒置原则（DIP）

Dependence Inversion Principle：依赖于抽象而不是实现类

• 上层模块不应该依赖底层模块，它们都应该依赖于抽象。
• 抽象不应该依赖于细节，细节应该依赖于抽象