23种设计模式的支撑---六大原则

一、开闭原则

开闭原则是指在面向对象编程领域中，规定软件中的对象，类，函数是允许扩展但不允许修改的。开闭原则的核心思想可以理解为面向抽象编程。

如何理解呢？

我们在编写代码时要尽可能的提高代码的灵活性，可以去对功能进行扩展，但尽量避免去修改之前已经写好的类。举个例子，当我们要去修改之前一个工具类，我们不应该直接去修改源代码而是进行水平扩展，重新构建工具类，通常要实现这种效果，我们一般要使用继承或者实现接口，这两种方式，无论哪种，都是面向抽象编程的思想。

在设计代码时遵循开闭原则，对一些可抽象的点去进行抽象能够很好的帮助我们后期进行项目维护，可以在不改动之前的代码基础上对功能进行扩展和修改。

二、单一职责原则

单一职责原则就是在设计代码时，保证一个类只去承担项目中的一个职责，尽可能避免复用。

如何理解？

我们在使用spring框架编写代码时，对于前后端数据交互我们通常要封装实体类。做过项目的朋友我们就会发现，有很多实体类其实是可以复用的。但，我们不要复用！虽然复用之后可以少写一些代码，但每个类的职责划分就会不清晰，同时对于项目后期的变更需求，我们就会难以维护，因此绝对禁止复用实体类。

上述例子是一个日常开发的例子，在设计代码时，当一个类所承担的职责过多时，我们要对该类进行抽象，然后划分职责。譬如，一个视频网站，我们要实现三种用户观看时给予不同的反馈，正常我们需要使用if-else循环来进行判断，遵循单一职责原则，我们可以对功能进行抽象，实现三个实现类来实现功能，每个用户类都只承担一个责任，并且对于后续的用户类别的细分也很容易进行水平扩展。

三、里氏替换原则

里氏替换原则是指，子类可以扩展父类的功能，但不能修改父类的功能。也就是说，我们子类继承父类后尽可能不去重写父类的方法。

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
• 子类可以增加自己的特有方法
• 当子类重载父类的方法时，方法的前置条件要比父类的方法更宽松。
• 当子类的方法（重载，重写，实现抽象方法）时，方法的后置条件（返回指或者输出）要比父类方法更加严格或者相等。

如何理解？

很多朋友可能会很懵为什么不允许重写父类的方法，其实从代码层面上是被允许的，实际应用在业务上也并无不可，但从类的角度上看业务划分就完全不同了。譬如，现在有一个储蓄卡和信用卡类，储蓄卡拥有两个功能，扣款和充值，信用卡有两个功能，贷款和还款。储蓄卡和信用卡的两个行为从现实生活中看并无二致。当我们编写好储蓄卡类后可以选择信用卡类继承储蓄卡类，然后重写储蓄卡类的方法。采用这种设计方式，我们在无形间就违背了里氏替换原则，让子类修改了父类的功能，虽然能够实现效果，但在业务上划分是不够清晰的，对于系 统后期维护和扩展时不利的。我们应该去抽象出一个card接口，定义需要实现的方法，让储蓄卡和信用卡去进行实现。

 四、迪米特法则

迪米特法则又称为最少知道原则，是指在一个类中对于其他对象类知道的越少越好。换言之，降低耦合，知道越少体现在代码上就是引用越少，自然耦合度越低。

如何理解？

在进行代码设计时，我们尽可能的让每个类把本职工作做好，不要跨层级依赖。譬如在spring框架编写业务代码时，我们通常划分为controller层，service层，DAO层，各个层级之间通过依赖注入的方式实现交互，遵循迪米特法则就是要在每一层去做好本职的事情，不允许在controller层去注入DAO层，于controller层而言，DAO层是感知不到的。

五、接口隔离原则

接口隔离原则是指，我们对一些抽象出来比较臃肿的接口，要进一步细分，避免接口过于臃肿。

单一职责原则、开闭原则可以看作是对类的重构，强调对类进行抽象和划分，增强代码灵活性。而接口隔离原则则是强调对接口的功能细分。

六、依赖倒置原则

依赖倒置原则又称为面向接口编程。该原则表明，高层模块不应该依赖于底层模块，二者都应该依赖于抽象。

如何理解？

在spring编写业务时，我们通常会定义service接口，以及对应的实现类，在controller层注入时，我们不会去在代码中直接定义依赖service的实现类而是去依赖它的接口。

为什么要使用这种方式？

遵循依赖倒置原则，可以降低类之间的耦合，提高系统的稳定性及可维护性，譬如，当我们去定义了两个实现类去实现同一个接口，我们如果在controller层定义具体的实现类，Java中的多态就无法发挥作用。定义成接口，在spring依赖注入时就可以实现接口多态，使得代码更加灵活。