设计模式的六大原则

---

本篇博客属于《Java设计模式》系列之一，内容主要借鉴于 秦小波的著作《设计模式之禅》，在理解过程中可能还参考其他博主的知识，最后整理成自己的学习笔记，在此分享给大家。由于本人知识和能力有限，博客中有错误或者理解偏差的地方，还望同行及前辈们多多探讨和指点，感谢不尽。（目前本人还在实习阶段，个人认为设计模式还是要结合自己的实际经验去理解更佳，暂时更新最常见设计模式9+1篇。立个flag,将来一定会补齐）–2020.11.22

序号	内容	链接地址
> 1	设计模式六大原则	https://blog.csdn.net/Dawn510/article/details/109501957
2	单例模式	https://blog.csdn.net/Dawn510/article/details/109541109
3	工厂模式	https://blog.csdn.net/Dawn510/article/details/109588909
4	抽象工厂模式及与工厂模式区别	https://blog.csdn.net/Dawn510/article/details/109609350
5	模板方法模式	https://blog.csdn.net/Dawn510/article/details/109609368
6	建造者模式	https://blog.csdn.net/Dawn510/article/details/109609385
7	代理模式	https://blog.csdn.net/Dawn510/article/details/109633416
8	装饰模式	https://blog.csdn.net/Dawn510/article/details/109663917
9	适配器模式	https://blog.csdn.net/Dawn510/article/details/109962821
10	观察者模式	https://blog.csdn.net/Dawn510/article/details/109962858

---

设计模式是什么

设计模式是一套理论，是软件界的先辈们总结出的一套可以反复使用的经验。它可以提高代码的可重用性，增强系统的可维护性，以及解决一系列的复杂问题。

在学习设计模式之前，先要明白六大设计原则，设计模式是在六大设计原则上的实践。

单一职责原则

• 单一职责的定义是：应该有且仅有一个原因引起类的变更
• 单一职责的好处：
  • 类的复杂度降低，实现什么职责都有清晰明确的定义
  • 可读性提高
  • 可维护性提高
  • 变更引起风险降低
• 在写代码的时候，尽量做到单一职责。但职责的划分很难确认，要根据环境、项目、资源等而定，但还是尽量做到类的设计只有一个原因引起变化。

里氏替换原则

• 里式替换原则的定义：只要父类能出现的地方子类就可以出现，而且替代为子类也不会产生任何错误和异常，使用者可能根本不需要知道谁是父类谁是子类。但是，反过来就不行了，有子类出现的地方，父类未必能适应。
• 里式替换原则的目的就是增强程序的健壮性，版本升级时也可以保持非常好的兼容性。即使增加子类，原有的子类还可以继续运行。

依赖倒置原则

• 依赖倒置的表现：
  1. 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。
  2. 接口或抽象类不依赖于实现类。
  3. 实现类依赖接口或抽象类。

更加精简的定位是“面向接口编程”

• 采用依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。
• 依赖倒置原则的本质就是通过抽象使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合。核心就是“面向接口编程”

为什么叫“倒置”，首先说“正置”是什么意思，依赖正置就是类间的依赖是实实在在的实现类间的依赖，也就是面向实现编程，也是正常生活的思维，要开车就依赖车，要用电脑就依赖电脑，而编写程序需要对现实世界的事物进行抽象，抽象的结果就是有了抽象类和接口，然后我们根据系统设计的需要产生了抽象间的依赖，代替了人们传统思维中的事物间的依赖，“倒置”就是从这里产生的。

接口隔离原则

• 接口隔离原则的定义：
  • 客户端不应该依赖它不需要的接口
  • 类间的依赖关系应该建立在最小的接口上

总结一句话是：建立单一接口，不要建立臃肿庞大的接口。再通俗点就是：接口尽量细化，同时接口的方法尽量少。

接口隔离原则和单一职责原则是相同的吗？

是不同的。单一职责注重的是职责，要求职责单一，属于业务逻辑上的划分。接口隔离原则要求接口的方法尽量少，当二者发生冲突时，首先满足单一职责原则。

• 接口隔离原则也就是要做到高内聚。
• 接口的设计粒度越小，系统越灵活，但是灵活的同时也带来了结构的复杂化，开发难度增加，可维护性降低。需要深入了解业务逻辑，根据经验和常识决定接口的粒度大小，太小增加开发工作量，太大灵活度降低。

迪米特法则

• 迪米特法则：一个对象应该对其他对象有最少的了解。
• 迪米特法则的核心观念就是类间的解耦，弱耦合，类的复用率才可以提供。如果一个方法放在本垒中，既不增加类间关系，也不对本类产生负面影响，那就放置在本类中。

开闭原则

• 开闭原则定义：软件实体应该对扩展开放，对修改关闭。
• 开闭原则的好处：
  • 可以减少测试的工作量
  • 可以提高复用性
  • 可以提高可维护性
  • 面向对象开发的要求