设计模式六大原则学习总结2

设计模式：面向对象语言开发过程中，遇到种种的场景和问题，提出的解决问题的思路。设计模式是解决具体问题的套路。

设计模式六大原则：面向对象语言开发过程中，推荐的一些指导性原则，没有明确招数，而且经常会被忽视或者违背。

 

目录

1.依赖倒置原则

2.接口隔离原则

3.开闭原则

---

1.依赖倒置原则

定义：

1.高层模块不应该依赖低层模块，二者应通过抽象依赖。

2.抽象不应该依赖细节。

3.细节应该依赖抽象。

还可以总结为：面向抽象编程。

 

从一个实例中感受下依赖倒置原则带来的好处：

张三是公司的司机，某天开着领导的奔驰车在马路上行驶。这个场景用代码实现可以表现为：

司机类：

奔驰类：

 

执行程序：

 

执行结果：

 

上面的这种实现思路是最直接能想到的，某天领导让张三开宝马车，程序需要改动了：

首先要声明一个宝马类：

只声明了宝马类还不够，这时候司机类是没有驾驶宝马的方法。

这时候会发现，程序设计上是有问题的，张三有了驾驶证，还只能开奔驰车，从实际角度出发考虑这个也不合理。

如果张三硬要驾驶宝马车，需要修改司机类（张三需要重新考一个驾驶宝马车的证），增加驾驶宝马的方法：

 

只有这样司机张三才能驾驶上宝马车。

这种设计思想就违背了依赖倒置原则，下面应用上依赖倒置原则对程序进行改动：

建立两个接口：IDriver和ICar，分别定义了司机和汽车的各个职能，司机就是驾驶汽车，必须实现drive()方法。

IDriver接口定义了一个驾驶方法

ICar接口定义了一个行驶方法 

 

 原来的司机类需要去实现IDriver接口：

 原来的奔驰和宝马也分别实现ICar接口：

 

程序调用： 

 执行结果：

 

这时候有一辆特斯拉需要张三驾驶，只用加一个特斯拉的类实现ICar接口，就可以直接调用，不用再修改Driver类。

在新增加低层模块时，只修改了业务场景类。Driver类不需要做任何修改，业务就可以运行，把“变更”引起的风险扩散降低到最小。

根据以上实例，如果不使用依赖倒置原则就会加重类间的耦合性，降低系统的稳定性，增加并行开发引起的风险，降低代码的可读性和维护性。

总结：

依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。

程序尽量使用抽象。

参考链接：https://www.cnblogs.com/cbf4life/archive/2009/12/15/1624435.html

 

2.接口隔离原则

定义：客户端不应该依赖它不需要的接口，一个类对另一个类的依赖应该建立在最小的接口上。

个人理解就是把一类的方法，放到一个接口中。可以看下面实例：

美女可以认为是：长相甜美、身材苗条、气质出众。定义一个美女的接口：

定义一个美女类实现该接口：

 

这时候如果对美女的定义有了新的变化，1.外貌好看的算作美女（长相好、身材好）  2.气质有内涵的算作美女（气质出众） 3.既有好的外貌又有气质

这时候就不能有上面定义的接口来表示了，因为上面的接口规定了美女就必须要满足三个条件，接下来对美女的接口进行一个拆分：

 

下面就可以灵活地定义美女的类： 

 

这三种情况都符合美女的标准。

这种实现逻辑也符合了接口隔离原则，一个接口定义一个功能模块。这样一来程序的扩展性、灵活性就高很多。

 

总结：

接口隔离原则指导的是接口该如何定义，其实这个没有标准的答案，原则也只是一个指导，个人总结下面几点接口定义的建议：

1.接口不能大而全，强迫实现没有的东西，比如一个电视的接口，里面定义一个打电话的方法，这是不合适的。

2.不能一个方法一个接口，这样面向抽象也没有意义，应该按照功能的密不可分来定义接口。

3.把同一类或同一个业务的方法放到一个接口中。

 

3.开闭原则

定义：对扩展开放，对修改关闭。

开闭原则是面向对象编程中最基础和最重要的设计原则之一，在设计程序中使用一些设计模式和遵守相关的设计原则，都是为了可以使程序实现开闭。

对扩展开放：系统中的模块、类、方法对提供者（开发者）应该是开放的，提供者可以对系统进行扩展（新增）新的功能。

对修改关闭：系统中的模块、类、方法对使用者（调用者）应该是关闭的，使用者使用这些功能时，不会因为提供方新增了功能而导致使用者也要进行修改。