设计模式01——设计模式六大原则

2020-04-24 本文已影响0人 Java面典

本文开始将为各位带来设计模式相关话题。关注我的公众号「Java面典」，每天 10：24 和你一起了解更多 Java 相关知识点。

一、单一职责原则

原则：一个类只负责一项职责；
引出问题：比如一个类 C 负责两个不同的职责：管理学生信息、管理教师信息。当由于学生信息相关需求发生改变而需要修改类 C 时，有可能会导致原本运行正常的教师信息相关功能发生故障；
解决方案：遵循单一职责原则。分别建立两个类 Student、Teacher，使 Stuednt 完成学生信息管理功能，Teacher 完成教师信息管理功能。这样，使得两个类的修改，不影响另一个功能的使用。

单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点：

原则：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求；
引出问题：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试；
解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

开闭原则是面向对象程序设计的终极目标，它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性。具体来说，其作用如下：

原则：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法；
引出问题：用户信息管理，由类 User 完成。现需要将用户信息管理进行扩展，扩展后的功能为 VIP 用户信息管理，其中 VIP 用户管理由原有功能用户信息管理与新功能 VIP 信息管理组成。新功能 VIP用户信息管理由类 User 的子类 VIP 来完成，则子类 VIPUser 在完成新功能 VIP信息管理的同时，有可能会导致原有功能用户信息管理发生故障；
解决方案：当使用继承时，遵循里氏替换原则。类 VIPUser 继承类 User 时，除添加新的方法完成新增功能 VIP信息管理外，尽量不要重写父类 User 的方法，也尽量不要重载父类 User 的方法。

里氏替换原则的主要作用如下：

原则：要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合；
引出问题：类 User 直接依赖类 WeChatInfo，假如要将类 User 改为依赖类 SinaInfo，则必须通过修改类 User 的代码来达成。这种场景下，类 User 一般是高层模块，负责复杂的业务逻辑；类 WeChatInfo 和类 SinaInfo 是低层模块，负责基本的原子操作；假如修改类 User，会给程序带来不必要的风险；
解决方案：将类 User 修改为依赖接口 ISocialInfo，类 WeChatInfo 和类 SinaInfo 各自实现接口 ISocalInfo，类 User 通过接口 ISocailInfo 间接与类 WeChatInfo 或者类 SinaInfo 发生联系，则会大大降低修改类 User 的几率。

依赖倒置原则的主要作用如下:

原则：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。；
引出问题：类 Student 通过接口 IDepartment 依赖类 Class，类 Teacher 通过接口 IDepartment 依赖类 Group，如果接口 IDepartment 对于类 Student 和类 Teacher 来说不是最小接口，则类 Class 和类 Group 必须去实现他们不需要的方法；
解决方案：将臃肿的接口 IDepartment 拆分为独立的几个接口，类 Student 和类 Teacher 分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。

接口隔离原则是为了约束接口、降低类对接口的依赖性，遵循接口隔离原则有以下 5 个优点:

将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性；
接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性；
如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使* 设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险；
使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义；
能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码。

迪米特法则要求限制软件实体之间通信的宽度和深度，正确使用迪米特法则将有以下两个优点：