软件设计模式六大原则

前言

在现如今 随着社会的快速发展 越来越多的人忽略了软件设计的本质 , 我们站在后人的角度 来仰望一下前辈们所总结的设计原则 , 回归一下软件设计的本质 , 欣赏一下前辈们的智慧

里氏替换原则

定义 : 继承必须确保超类所拥有的性质在子类中仍然成立 . 所有父类能实现的功能 , 如果把父类替换成子类 那么依旧可以正常运行 .
通俗讲 : 子类继承父类 , 但不要修改父类原有功能 , 如果要在父类的基础上新增新的功能 那么需要新创建方法调用父类的方法 .
自我理解 :举个例子 正方形是边长相同的长方形 如果我们硬是把圆归为长方形的话 就需要修改圆的周长以及面积的实现 (覆盖掉父类的方法) 实际上讲 , 任何做java的 都会说出java的三大特性 , 封装继承多态 , 但多态从字面上理解是否与里氏替换原则相冲突 ? 实则不然 多态本质上是让子类覆盖并重新定义父类的方法 , 那么但为了达到解耦 我们可以选择把需要覆盖的方法设计为抽象方法 , 让子类实现 再这样就会满足多态跟里氏替换原则 如果此抽象方法针对大部分场景都能实现 我们可以设置methodB 为其默认实现 权限为protected 供子类选择

依赖倒置原则

定义 : 客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上
通俗讲 : 高层次如果直接依赖于低层次 如果低层次需要改动的话 , 高层次也会随之发生变化 , 抽象如果直接依赖于细节 , 也会导致细节修改导致抽象修改
自我理解 :举个例子 我所做的是一家保险系统 , 在我们需要计算退保时 就存在这种情况 处理退保的业务逻辑是高层次 具体的计算要素是低层次 高层次直接依赖低层次的计算退保要素 就会导致如果需要新增或者修改 都会影响到业务逻辑的修改 (!!! 此条规范对于代码质量以及健壮性和维护性尤其的重要 说起来很容易可能做起来很难 需要长时间的培养相关的思维 重在平时)

接口隔离原则

定义 : 客户端不应该依赖它不需要的接口 , 类间的依赖关系应该建立在最小的接口上
自我理解 : 对于接口来讲 我们不能让类继承无用的代码 没啥好说的这个是必须的 但我们设计接口时会尽可能根据业务模型细化接口 来让接口实现接口 最后封装成一个大的接口 来让类继承 (对于java来讲 函数式接口 就意味着 无限的可扩展性 并且不需要新建类)

迪米特法则

定义 : 一个类对于其他类知道的越少越好，就是说一个对象应当对其他对象有尽可能少的了解,只和朋友通信，不和陌生人说话
通俗讲 : 知道一个类越少就代表当你调用时 , 如果其他类修改对此类的影响就越小 导致改动会非常非常小 达到解耦的目的
自我理解 : 朋友的概念 在类里面 方法参数/成员变量/静态变量都可以叫做朋友 , !!!局部变量就不是朋友 , 但如果局部变量功能能做到永远不改变 比如(java的内置库 , util工具类 工具生成的代码)其实我们可以叫做朋友类 , 但类似于业务逻辑处理封装成对象 我们一般不建议直接出现在方法参数里面new . 并且根据此原则 首先第一是尽可能的设计为不变类 , 也应该尽可能的控制权限 , 不要把实现细节或者成员变量暴露出来带到其他类对此类必须尽量少的了解

单一职责原则

定义 : 不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责
自我理解 : 字面意思 没啥好解释的 一个接口/类尽可能的只做一件事

开闭原则

定义 : 对修改关闭 , 对扩展开放
自我理解 : 我理解 就是字面的意思 , 如果要新增功能 尽可能的少修改 , 多做扩展或者改配置达到支持功能 . 其实这条就是对上面五条的总结 如果软件设计能严格遵守上面五条 这条就是我们要实现的最终目标 达到解耦程序的最终目标

后记

聊一点自己的感悟 如果所有设计都完全按照以上六条 我估计一个小小的功能可能都会有上千个类 大一点的可能都不止 其实软件设计的根本是 首先分析出变与不变的东西 不变的概念是(根据能遇见的业务分析 大概分析出5年内/或者更久不需要重构此功能 那么其实足矣) 不变的事物怎么都好弄 其实完全没有必要遵循以上准则 写死又如何 但对于变化的事物如何根据现有业务模型 以及上面的准则进行中和 (此时我想提一个经济学原理 边际递减效应 : 如果一种投入要素连续地等量增加，增加到一定产值后，所提供的产品的增量就会下降，即可变要素的边际产量会递减) 选择最最适合的并且合理的方式去划分模型拆解模型去设计代码 (不要盲目的为了拆而拆) 才能做到写好代码