软件设计的5项基本原则

为什么要学习软件设计原则？

学习软件设计的基本原则，一方面可以让我们写出更高质量的代码，另一方面也可以让我们更容易去理解其他人的一些优秀设计。（这些优秀的设计思想在Java设计模式中随处可见）

什么样是糟糕的软件设计？

僵硬：不易改变

脆弱：只想改变A，结果B被破坏

牢固：无法进行快速拆分

粘滞：对现有软件做变更

晦涩：代码难以理解

过度设计、Copy-paste代码

设计原则的目的，就是提供一种设计规范，让我们的代码不再是一种糟糕的代码，而是经得起需求变更，坚固，灵活的代码。

开/闭原则（OCP）

对于功能是开放的，对于更改是关闭的。

实现这种开闭原则的关键是抽象，比如我们通过一个按钮去拨号，如果我们直接去设计，可能会写出这样的代码：

但是这其实是违背开/闭原则的，如果我们要新增加一个类，通过按钮去拨打电话，那么就需要去对Button类进行修改，所以正确的写法是不让Button直接指向一个具体类，而是指向一个接口，需要新增类的时候，只需要让它去实现接口即可：

一个优秀的设计，是对一个类文件开发或者测试完成后，就不再打开

依赖倒转原则（DIP）：

高层模块不能依赖底层模块，而是大家都依赖于抽象。

这句话的的意思是高层模块去定义一个接口，底层模块去实现这个接口，这个接口就是高层模块与底层模块沟通的桥梁。

LisKov替换原则（LSP）

若对每个类型T1的对象o1，都存在一个类型T2的对象o2，使得在所有针对T2编写的程序P中，用o1替换o2后，程序P的行为功能不变，则T1是T2的子类型

简而言之：子类型必须能替换掉它们的基类型

单一职责原则（SRP）

一个类只能有一个引起它变化的原因，这个其实也比较好理解，一个类的设计，最好不要让他去承载多个功能，这样这个类就会变得很重，不够灵活，也不易更改

接口分离原则（ISP）

不应该强迫客户程序依赖它们不需要的方法

比如一个类，有多个方法，但是是两组不同的使用场景，这个个时候可以让这个类去实现2个接口，在这2个接口中，将方法进行分组，使用时根据不同场景，去委托接口实现功能。