设计模式之六大原则初识

背景

今天和前同事聊天得时候，突然说到了迪米特法则，突然脑子一片空白，努力在脑海中找出关于迪米特法则的相关信息，很遗憾，自己并没有找出任何比较有价值的信息。只记得这是设计模式的六大法则之一，以前虽然看过，但是只是粗略的看。这里为了加深映像和理解，再次进行了设计模式六大法则的回顾（还是老师那句老话管用：好记性不如烂笔头，到任何时候都适用）。设计模式不仅是面试的高频问题，而且能够真真切切的提高你写代码的质量。

何为设计模式

设计模式是我们的软件开发人员在软件开发过程中遇到的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。

设计模式的目的

设计模式的出现主要是为了让我们在开发应用中能够很好的拥抱变化，也就意味在日后的升级、维护中不破坏的系统的稳定性。其低耦合、高内聚、可扩展等特性可以为后续的迭代减负。让项目在多次迭代后依然保持清晰、灵活、稳定的系统结构

设计模式的六大原则

• 开闭原则（Open Close principle）
  这个原则从字面就能够理解个大概，主要有两点
  1.开：对（类、模块、函数）扩展开放
  2.闭：对（类、模块、函数）修改关闭
  因为软件不是一下就开发好的，因为在后期还需要对其进行变化、升级和维护。那么之前写好并测试过的功能，我们需要保证其稳定性，就尽量不要在原有基础进行修改，而是通过扩展的方式进行优化。想要达到这种效果我们需要使用接口和抽象类
• 里氏替换原则（Liskov Substitution Principle）
  这个原则大概就是一种替换原则吧，所有使用基类的地方必须能够使用子类对象。面向对象的三大基本特征：封装、继承、多态，里氏替换原则主要依赖继承、多态这两大特征，可以理解为只要使用基类的地方都可以使用子类，且使用后不会产生错误，但是反过来却不行。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
• 依赖倒转原则（Dependence Inversion Principle）
  依赖于抽象不依赖于具体。高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。核心思想就是面向接口编程。
• 接口隔离原则（Interface Segregation Principle）
  定义：客户端不应该依赖它不需要的接口。另一种定义是：类之间的依赖关系应该建立在最小的接口上。接口隔离原则将非常庞大、臃肿的接口拆分成更小和更具体的接口，这样客户端将会只需知道他们感兴趣的方法。接口隔离原则的目的是系统解开耦合，从而容易重构、更改和重新部署。
• 迪米特法则，又称最少知道原则（Demeter Principle）
  定义：一个对象应该保持对其他对象的最少了解
  问题由来：一个类与另一个关系越密切、耦合度越大，当改其中一个类时，其他类出现问题的概率就越大
  解决方案：尽量减少类之间的耦合
• 单一职责
  定义：对于一个类而言，应该只有只有引起它变化的原因，一个类只负责一个职责。
  问题由来：类T负责两个不同的职责P1、P2，当职责P1变更需要修改类T，这时候修改类T，可能会对职责P2造成影响。
  解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

---

这是个人参考不同的技术文章汇总出来，里面有直接抄录部分，也有个人理解部分，如有不对的地方欢迎指出，让我们一起学习、一起成长。

带有例子的参考文章