设计模式-经典的设计原则介绍

1.单一职责原则（Single Responsibility Principle，SRP）

一个类只负责完成一个职责或者功能。

2.开闭原则（Open Closed Principle，OCP）

添加一个新的功能应该是，在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）。

3.里式替换原则（Liskov Substitution Principle，LSP）

理解里式替换原则，最核心的就是理解“design by contract，按照协议来设计”这几个字。父类定义了函数的“约定”（或者叫协议），那子类可以改变函数的内部实现逻辑，但不能改变函数原有的“约定”。这里的约定包括：函数声明要实现的功能；对输入、输出、异常的约定；甚至包括注释中所罗列的任何特殊说明。

里氏替换就是说父亲能干的事儿子也别挑，该怎么干就怎么干，儿子可以比父亲更有能力，但传统不能变

4.接口隔离原则（Interface Segregation Principle，ISP）

客户端不应该被强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者。

5.依赖反转原则（Dependency Inversion Principle，DIP）

6.KISS 原则

尽量保持简单（Keep It Simple and Stupid.Keep It Short and Simple.Keep It Simple and Straightforward.）
如何写出满足KISS原则的代码：
● 不要使用同事可能不懂的技术来实现代码。比如前面例子中的正则表达式，还有一些编程语言中过于高级的语法等。
● 不要重复造轮子，要善于使用已经有的工具类库。经验证明，自己去实现这些类库，出 bug 的概率会更高，维护的成本也比较高。
● 不要过度优化。不要过度使用一些奇技淫巧（比如，位运算代替算术运算、复杂的条件语句代替 if-else、使用一些过于底层的函数等）来优化代码，牺牲代码的可读性。

7.YAGNI原则（You Ain’t Gonna Need It）

不要去设计当前用不到的功能；不要去编写当前用不到的代码。实际上，这条原则的核心思想就是：不要做过度设计。

8.DRY 原则（Don’t Repeat Yourself）

不要写重复的代码。

9.迪米特法则（Law of Demeter，LOD）

目的都是实现高内聚低耦合，但是出发的角度不一样，单一职责是从自身提供的功能出发，迪米特法则是从关系出发，针对接口而非实现编程是使用者的角度，殊途同归。