设计模式六大原则（总结）
摘要：1. 设计模式之单一职责原则 一个类只负责一项职责，不要存在 1 个以上导致类发生变更的原因。 优点：a. 降低类的复杂度，一个类只负责一项职责，逻辑简单清晰；b. 类的可读性，系统的可维护性更高；c. 因需求变更引起的风险更低，降低对其它功能的影响。 总结：只有逻辑足够简单，才可以在代码级别上违反
阅读全文
posted @ 2022-06-27 21:04
随笔分类 - 设计模式
设计模式之开闭原则
摘要：1.1 定义 开闭原则的全称是 Open Close Principle（OCP），软件中的对象（类、模块、函数等）应该对于扩展是开放的，对于修改是封闭的。 1.2 问题产生 在软件的生命周期内，因为变化、系统升级和维护等原因需要对软件原有代码进行修改时，可能会将错误引入原本已经测试过的旧版本中，破
阅读全文
posted @ 2022-06-27 21:03
设计模式之迪米特法则
摘要：1.1 定义 迪米特法则(Law of Demeter,LoD)是 1987 年秋天由 lan holland 在美国一个叫做迪米特的项目设计中提出的，它要求一个对象应该对其他对象有最少的了解，所以迪米特法则又叫最少知道原则。 1.2 理解 迪米特法则的意义在于降低类之间的耦合，每个类尽量减少对其他
阅读全文
posted @ 2022-06-27 21:02
设计模式之里式替换原则
摘要：1.1 介绍 肯定有很多人跟我刚看到这项原则的时候一样，对这个原则的名字充满疑惑，其实原因就是这项原则最早是在 1988 年，由麻省理工学院的一位女士（Barbara Liskov） 提出来的。 当然，这对于我们来说不是最重要的，我们需要关注的是里式替换原则本身，以及采用里式替换原则，能够为我们的开
阅读全文
posted @ 2022-06-27 21:00
设计模式之依赖倒置原则
摘要：1.1 定义 高层模块不应该依赖低层模块，二者都应该依赖其抽象； 抽象不应该依赖细节； 细节应该依赖抽象 1.2 问题由来 类 A 直接依赖类 B，假如要将类 A 改为依赖类 C ，则必须通过修改类 A 的代码来达成。这种场景下，类 A一般是高层模块，负责复杂的业务逻辑；类 B 和类 C 是低层模块
阅读全文
posted @ 2022-06-27 21:00
设计模式之单一职责原则
摘要：1.1 定义 通俗的说，即一个类只负责一项职责，不要存在1 个以上导致类发生变更的原因。 1.2 问题由来 类 T 负责两个不同的职责：职责 P1 和职责 P2。当职责 P1 需求发生改变时，我们需要修改类 T，此时，就有可能会导致原本运行正常的职责 P2 功能发生故障。 1.3 解决方案 遵循单一
阅读全文
posted @ 2022-06-27 20:59
设计模式之接口隔离原则
摘要：1.1 定义 客户端不应该依赖它不需要的接口 一个类对另一个类的依赖应该建立在最小的接口上 1.2 问题由来 类 A 通过接口 Interface1 依赖 B，类 C 通过接口 Interface1 依赖 D，如果接口 Interface1对于类 A 和类 B 来说不是最小接口，则类 B 和类 D
阅读全文
posted @ 2022-06-27 20:58
