设计模式的七大设计原则总结(全方面详细总结)

1.单一职责原则

• 对类来说，一个类应该只负责一项职责(并不是一个类只有一个方法，可以有多个方法，这些方法共同完成一项职责)。
• 如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力；这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。
• 软件设计真正要做的许多内容，就是要发现职责并把那些职责相互分离。
• 如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责。
• 通常情况下，我们应当遵守单一职责原则，只有当逻辑足够简单时，才可能在代码级违反单一职责原则；类中方法数量足够少时，可以在方法级别保持单一职责原则。
• 单一职责原则的作用：
  • 降低类的复杂度，一个类只负责一项职责。
  • 提高类的可读性，可维护性。
  • 降低变更引起的风险。

2.里氏替换原则

• 问题的提出：
  • 继承包含这样一层含义:父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。
  • 继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承， 则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障。
  • 在编程中，如何正确的使用继承? => 由此提出里氏替换原则
• 里氏替换原则(Liskov Substitution Principle)在1988年，由麻省理工学院的Barbara Liskov女士提出的。
• 它的内容白话翻译就是一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别；也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。
• 简单来说，子类型必须能够替换掉它们的父类型。
• 只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。
• 由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展。
• 里氏替换原则注意点：
  • 在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法。
  • 里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以让原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉， 采用依赖，聚合，组合等关系代替。

3.依赖倒转原则

• 高层模块不应该依赖底层模块，二者都应该依赖抽象。也就是说我们可以去依赖接口，可以去依赖抽象类，但是我们不要去依赖一个具体的子类。
• 抽象不应该依赖细节，细节应该依赖抽象。也就是说我们要针对接口编程，不要对实现编程。
• 依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多，在Java中，抽象指的是接口或抽象类，细节就是具体的实现类。
• 使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成。
• 使用依赖倒转原则的细节：
  • 底层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性好。
  • 变量的声明类型尽量是抽象类或接口，这样我们的变量引用和实际对象间就存在一个缓冲层，利于程序的扩展和优化。
  • 继承时遵循里氏替换原则。

4.接口隔离原则

• 客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。
• 图示讲解：
  
  • 类A通过接口Interface1依赖类B，类C通过接口Interface1依赖类D，如果接口Interface1对于类A和类C来说不是最小接口， 那么类B和类D必须去实现他们不需要的方法。
  • 按隔离原则应当这样处理: 将接口Interface1拆分为独立的几个接口， 类A和类C分别与他们需要的接口建立依赖 关系。也就是采用接口隔离原则，如下：

5.开闭原则

• 开闭原则(Open Closed Principle)是编程中最基础、最重要的设计原则。
• 开闭原则是说软件实体(类、模块、函数等等)应该可以扩展，但是不可修改。
• 也就是说对于扩展是开放的，对于修改是封闭的。
• 编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则。
• 无论模块是多么的“封闭”，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜出最有可能发生的变化种类，然后构造抽象来隔离那些变化。
• 面对需求，对程序对改动是通过增加新代码进行对，而不是更改现有的代码。
• 我们希望的是在开发工作展开不久就知道可能发生的变化，查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难。
• 开闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象；然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好注意。拒绝不成熟的抽象和抽象本身一样重要。

6. 迪米特法则

• 一个对象应该对其他对象保持最少的了解。
• 类与类关系越密切，耦合度越大。
• 迪米特法则(Demeter Principle)又叫最少知道原则，即一个类对自己依赖的类知道的越少越好；如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
• 迪米特法则首先强调的前提是在类的结构设计上，每一个类都应当尽量降低成员的访问权限，也就是说，一个类包装好自己的private状态，不需要让别的类知道的字段或行为就不要公开。
• 迪米特法则其根本思想是强调了类之间的松耦合。
• 类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。也就是说，信息的隐藏促进了软件的复用。
• 迪米特法则还有个更简单的定义:只与直接的朋友通信。何为直接的朋友：
  • 直接的朋友:每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系， 我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖，关联，组合，聚合等。其中，我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。

7.合成复用原则

• 原则是尽量使用合成/聚合的方式，而不是使用继承。
• 举个例子，如果A类中有两个方法，我们想让B类中能够用到A类中的两个方法，我们有以下几种方法：
  • 让B类继承A类，这样B类就可以使用A类中的方法了，但是这种方式要尽量少用，因为它提高了类与类之间的耦合。
  • 让B类中某个方法的形参类型为A类
  • 让B类中某个属性的类型为A类

8.设计原则核心思想总结

• 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
• 针对接口编程，而不是针对实现编程。
• 为了交互对象之间的松耦合设计而努力。