伪代码之设计模式—理解六大原则

前言：为什么需要伪代码？

让不会写代码的同志或不同技术领域的童鞋都能看懂，废话不多说，直接刚实例，直观的学习六大原则吧~~*[]~(￣▽￣)~*

单一职责原则实例

我们先看按照常规逻辑如何写代码,下面是一个图片加载器的伪代码：

定义类：图片加载器
定义下载图片方法：（一百行代码）
定义显示图片方法：（一百行代码）
定义从获取缓存方法：（一百行代码）

照这么看，所有功能是实现了，但是呢，代码三百多行。显得异常臃肿。当未来我们需要扩展，极为不方便，比如说。我们需要从内存缓存中读取图片，磁盘缓存中读取图片。或者网络缓存读取图片。那么我们就需要继续累加代码了。这就导致代码越堆越多。结果呢，未来某天维护的时候，自己都看不懂自己的代码了。

单一职责原则

定义：就一个类而言，就一个引起类变换的原因

继续以图片加载器为例，伪代码如下：

定义图片加载器类

定义图片缓存类实例
定义图片显示类实例
定义图片下载类实例

定义下载图片方法：（图片下载类实例下载图片）
定义显示图片方法：（图片显示类实例加载图片）
定义从获取缓存方法：（图片缓存类实例获取缓存）

我们可以看到，我们把职责统一划分，这样自己做的事情就在自己类中处理，图片加载器类的代码明显变少，且易读。这就是单一职责原则，自己事情自己做~

开闭原则实例

定义：对扩展开放，对修改关闭
我们代码经过单一职责原则划分后将会是如下状态。

定义图片加载器类
定义图片缓存类实例 (内存缓存实现类)
定义图片显示类实例
定义图片下载类实例

定义下载图片方法：（调用图片下载类实例下载图片）
定义显示图片方法：（调用图片显示类实例加载图片）
定义从获取缓存方法：（调用图片缓存类实例获取缓存）

现在图片缓存类是内存缓存，如果这时候需要一个磁盘缓存，那么我们无疑要替换图片缓存类实例了，这时候呢，我们就对图片加载器类修改了。这就违背了我们开闭原则。

开闭原则

只需要把需要替换的实例，使用接口或者抽象类定义，可以通过其他函数进行替换，这样就不需要修改框架类代码，实现扩展！

定义图片加载器类
定义图片缓存类实例 (抽象类、接口)
定义图片显示类实例
定义图片下载类实例

设置缓存类实例方法：（需要外部替换缓存类实例）
定义下载图片方法：（调用图片下载类实例下载图片）
定义显示图片方法：（调用图片显示类实例加载图片）
定义从获取缓存方法：（调用图片缓存类实例获取缓存）

里氏替换原则

定义：父类可以出现的地方，子类一定可以出现。并且不会报错。（必须父子关系，通过里氏替换原则达到对外开放，对修改关闭。）
笔者看法：里氏替换原则和开闭原则相生相依，因为开闭原则若想不修改，则必须以子类代替父类方式存在。而里氏替换原则正好是这样。

依赖倒置原则

高层次模块定义不依赖低层次模块实现细节（依赖抽象，不依赖具体实现）

理解：可以看开闭原则代码，缓存类仅仅是一个接口（父类、高层次对象），而我们使用的时候使用的是实现类（子类、低层次对象）

接口隔离原则

定义：类与类之间的依赖应该建立在最小的接口上，多个接口整合一个完整的系统
我们就以Java的InputStream来举例


可以看到 InputStream 实现了一个叫做Closeable的接口而这个接口就是一个粒度（只有关闭一个方法）的关闭方法，这样我们可以做一个工具类。传入对象是一个Closeable的接口。那么我们就实现了接口隔离了实现。更加容易扩展

最少知识原则（迪米特原则）

定义：一个类应该对其他类有最少的了解。
简单说：自己类的内容应该是相关性很高的属性和方法。不需要了解其他类。
这个应该都是大家常犯的一个错误，最简单的一个例子就是 ： URLUtil
相信很多童鞋都和笔者一样。写一个URLUtil，然后里面写了一大堆的URL，比如这样：

那我们应该如何去做呢？ 案例走起：
定义一个Base模型类：

Base模型类：
获取服务器地址方法：返回服务器地址

产品模型类（继承Base模型类）：
获取产品方法：（获取服务器地址，拼接产品URL路径）

可以看到 上面的伪代码。产品类的URL就在产品类的内部，其他外部类不需要知道。这就是最少知识原则。

好了 本章内容就这些了。给大家抛出一个问题，最少知识原则、开闭原则、里氏替换原则、接口隔离原则他们定义读一遍有什么争议呢？文章有异议的地方欢迎评论区指出！