【设计模式】 3.设计模式基本原则

单一职责原则

对于一个类而言，有且仅有一个引起他变化的原因或者说，一个类只负责一个职责

如果一个类承担的职责过多，那么这些职责放在一起耦合度太高了，一个职责的变化可能会影响这个类其他职责的能力。

所以我们在做软件设计的时候，要发现职责，并且把这些职责互相分开

例子1

对于看书这件事情，用手机看书和直接看纸质书相比，肯定纸质书的效率要高一些。

因为手机的职责太多了，接打电话、听歌、看电视剧等等，我们在看书的时候，可能收别的职责的影响。

而纸质书，只有一个职责，沉浸式读书。

例子2

电脑机箱中，由CPU、内存、硬盘、显卡、主板等等。

假设我们的CPU、内存、应该、显卡是高层模块，电脑中应该叫易插拔，都插到主板中。

对于电脑这个主体而言，就符合单一职责原则，内存条坏了，不会影响CPU、磁盘和主板。

开闭原则

对扩展开发，对修改封闭【多扩展、少修改】

当我们面对新需求的时候，对程序的修改只是通过增加代码的方式，而不用去修改已有的代码。

这样做我们程序变得更加，可扩展、可维护、可服用、灵活性。

例子

假设现在我们由两个模块，一个是高层模块（做业务逻辑模块），一个底层模块（数据库模块）。

数据库的一些常见操作比如：增删改查，但是我们使用的数据库可以是MySQL、SQLServer、Postgresql等等。

那么如果做到开闭原则呐，抽象出一个类，如果新加了数据库去继承这个类，然后自己去实现增删改查接口。

这样就做到了对扩展开发，对修改封闭了。

依赖倒置原则

高层模块不应该依赖于底层模块，他们都应该依赖于抽象

我们要针对接口编程，而不是针对实现编程

例子1

电脑举例，CPU、内存、硬盘、显卡都应该依赖于抽象接口，而不是依赖于具体的主板。

如果依赖于具体的主板，那么主板坏了，这些高层的设备都用不了了，这样设计显然不合理。

例子2

还是上面那个例子，高层模块（业务逻辑层）和底层模块（数据库层）都不应该互相依赖，而是依赖于抽象。

高层模块 => 抽象 => 低层模块

抽象其实就是基类，底层模块是子类。

MySQL、SQLServer、PostgreSQL都有增删改查操作，假设有一天要用到别的数据库

只需要再创建一个类，继承抽象去实现这些接口，对于高层模块而言，不需要任何的改变（或者只需要改变new的对象而已）

里氏替换原则

子类必须能够替代父类

例子

假设鸟是父类，那么鸵鸟和企鹅能继承于鸟类吗？

如果按照初中老师讲的，鸵鸟和企鹅虽然不能飞，但是属于鸟类。

但是再我们编程的世界里面，如果鸵鸟和企鹅可以继承鸟类，这是不合理的，违反了里氏替换原则。

还是举一个例子，他们的高层模块 => 抽象 => 低层模块

如果抽象中要使用的方法就是鸟的会飞的方法，但是我们底层模块是鸵鸟，根本不会飞，这样就会产生严重的错误

所以里氏替换原子是实现依赖倒置原则的基础