设计模式六大原则学习总结2
作者：互联网
设计模式：面向对象语言开发过程中，遇到种种的场景和问题，提出的解决问题的思路。设计模式是解决具体问题的套路。
设计模式六大原则：面向对象语言开发过程中，推荐的一些指导性原则，没有明确招数，而且经常会被忽视或者违背。
目录
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.开闭原则
定义：对扩展开放，对修改关闭。
开闭原则是面向对象编程中最基础和最重要的设计原则之一，在设计程序中使用一些设计模式和遵守相关的设计原则，都是为了可以使程序实现开闭。
对扩展开放：系统中的模块、类、方法对提供者（开发者）应该是开放的，提供者可以对系统进行扩展（新增）新的功能。
对修改关闭：系统中的模块、类、方法对使用者（调用者）应该是关闭的，使用者使用这些功能时，不会因为提供方新增了功能而导致使用者也要进行修改。
标签：总结,六大,依赖,定义,原则,接口,美女,倒置,设计模式 来源： https://blog.csdn.net/liangmengbk/article/details/113066606