设计模式的六大原则（待完成）

设计模式的六大原则

单一职责原则

里氏替换原则

依赖倒置原则

接口隔离原则

迪米特原则

开闭原则

 

单一职责

概念：对功能进行分类，代码进行解耦 一个类或者一个接口只负责唯一项职责，尽量设计出功能单一的接口；

栗子：一个网络请求框架大致分为：请求类，缓存类，配置类；不能把这三个功能混合在一起，必须分成三个类分别去实现不同的功能

定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。

问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。

解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

举例：

医生的职责就是诊断

护士的职责就是护理

不能既让医生去诊断的同时还要去护理，来干扰护士的职责

 

里氏替换

概念：在继承类时，除了扩展一些新的功能之外，尽量不要删除或者修改对父类方法的引用，也尽量不要重载父类的方法

栗子：每个类都是Object的子类，Object类中有一个toString()的方法，假如子类重写该方法并且返回null，这个子类的下一级继承返回的都是null，那么在不同开发人员维护时可能考虑不到这个问题，并且很可能会导致程序崩溃

定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。

定义2：所有引用基类的地方必须能透明地使用其子类的对象

问题由来：有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。

解决方案：当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法

举例：

父类要尽可能做到唯一性，因为继承在给程序设计带来巨大便利的同时，也带来了弊端，多继承会慢慢给程序代理局限性，并且在创造子类时，要尽量不侵入父类方法，否则以后只要有点变动，影响范围会成几何倍数上升。

如公司开发广告牌：

首先采购了很多铁片（父类）

调研了市场觉得矩形广告牌销量最好，于是将铁片全部裁剪成了矩形（子类），为了独特性，在所有矩形的铁片打孔（子类1），最后为了美观，全部统一上色（子类2），一套流水线下来当时取得了很好的销量。但是过段时间，矩形广告牌不再畅销，圆形广告牌畅销，但是现在库存全时矩广告牌，修改起来就费时费力。

 

依赖倒置

概念：高层模块不依赖低层次模块的细节，高层次就是不依赖细节而是依赖抽象（不依赖具体的类，而是依赖于接口）       高层模块不应该依赖低层模块具体实现，解耦高层与低层。既面向接口编程，当实现发生变化时，只需提供新的实现类，不需要修改高层模块代码;

栗子：某个网络框架为了满足不同开发者的需求，即能使用高效的OkHttp框架，也可以使用原生的API。正所谓萝卜白菜各有所爱，那么是如何进行切换的呢，这个时候需要面向接口编程思想了，把一些网络请求的方法封装成一个接口，然后分别创建OkHttp和原生API的接口实现类，当然也方便后续其他开发人员进行扩展其他网络框架的应用

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。

举例：

要根据业务逻辑划分层级，以及依赖关系

比如“张三开汽车”，可以分为三个层级：司机，交通工具，交通工具类别。

张三可以开汽车，后期可以开宝马牌汽车，当然也甚至也可以开其他交通工具。

所以它们的结果关系就最好有层级关系如下：

[self driver] vehicle]  vehicleType]

抽象不应该依赖细节：

交通工具也要做为抽象类，它既不依赖于车，也不依赖与飞机，它就是抽象的作为出发点

当然交通工具类别也要做为抽象类，它既不依赖于宝马，也不依赖于奔驰

在这之后就能很友好的表达改业务场景

 

接口隔离

概念：在定义接口方法时应该合理化，尽量追求简单最小，避免接口臃肿

栗子：在实际开发中，往往为了节省时间，可能会将多个功能的方法抽成一个接口，其实这设计理念不正确的，这样会使接口处于臃肿的状态，这时就需要合理的拆分接口中的方法，另外抽取成一个独立的接口，避免原有的接口臃肿导致代码理解困难

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

问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。

解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。

举例：

建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。

比如两个部门：客户部和销售部

客户部功能：客户信息收集，客户拓展，售后处理

销售部功能：咨询价格，下订单，提货，售后处理

那就可以在分一个售后部的接口出来：

客户部功能：客户信息收集，客户反馈与投诉

销售部功能：咨询价格，下订单，提货

售后部功能：货物售后处理

 

迪米特 | 最少知道

概念：一个对象应该对其他对象有最少的了解；一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现、如何复杂都与调用者或者依赖者没关系，调用者或者依赖者只需要知道他需要的方法即可，其他的一概不关心。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。只与直接的朋友通信。每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型有很多，例如组合、聚合、依赖等。

栗子：一般在使用框架的时候，框架的开发者会抽出一个类供外部调用，而这个主要的类像是一个中介一样去调用框架里面的其他类，恰恰框架里面其他类一般都是不可访问（调用）的，这个框架就遵守了迪米特原则，其他开发人员只关心调用的方法，并不需要关心功能具体如何实现

定义：一个对象应该对其他对象保持最少的了解。

问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。

解决方案：尽量降低类与类之间的耦合。

举例：

有一个集团公司A，下属单位B有分公司C和直属部门D，现在要求打印出所有下属单位的员工姓名,

A与C和D并不是直接关系，所以需要B这个媒介去与C，D通信，而A只需要知道关心B反馈的结果，不需直接联系C，D。

 

 

开闭

概念：类、模块和函数应该对扩展开放，对修改关闭，换句话说，当需求发生变化时，我们可以通过添加新模块 来满足新需求，而不是通过修改原来的实现代码来满足新需求  打个比方  公司有新的需求   增加新的部门来完成  而不是用原来的部门人员

栗子：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试，整个流程对开发周期影响很大，这个时候就需要开闭原则来解决这种问题

定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

问题由来：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。

解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

举例：当有新需求时，如果增加功能涉及老功能点某些地方，最好不要轻易修改老功能，最好重新新增相应的功能，不然一些忽略的细节可能就会造成隐患

 

总结

单一职责原则告诉我们实现 类 要职责单一

里氏替换原则告诉我们不要破坏继承体系

依赖倒置原则告诉我们要面向接口编程  理解：类A调用类B  A是依赖B 但是要用A中的接口 让B依赖A  即依赖倒置

接口隔离原则告诉我们在设计 接口 的时候要精简单一

迪米特原则告诉我们要降低耦合  栗子：框架.h文件

开闭原则是总纲，告诉我们要对扩展开放，对修改关闭