本文主要讲迪米特法则和开闭原则.
一, 迪米特法则
1. 定义
迪米特法则也称最少知道原则, 虽然名字不同, 但描述的是同一个规则: 一个对象应该对其他对象有最少的了解. 通俗地讲, 一个类应该对自己需要耦合或调用的类知道得最少, 你 (被耦合或调用的类) 的内部是如何复杂都和我没关系, 那是你的事情, 我就知道你提供的这么多 public 方法, 我就调用这么多, 其他的我一概不关心.
2. 迪米特法则对类的低耦合提出明确的要求
4 层含义如下:
(1)只和朋友交流
迪米特法则还有一个解释是: 只与直接的朋友通信.
什么叫直接的朋友?
每个对象都必然会与其他对象有耦合关系, 两个对象之间的耦合就成为朋友关系, 这种关系的类型有很多, 例如组合, 聚合, 依赖等.
注意:
一个类只和朋友交流, 不与陌生类交流, 不要出现 getA().getB().getC().getD()这种情况(在一种极端的情况下允许出现这种访问, 即每个点号后面的返回类型都相同), 类与类之间的关系是建立在类间的, 而不是方法间, 因此一个方法尽量不引入一个类中不存在的对象, 当然, JDK API 提供的类例外.
(2)朋友间也是有距离的
人和人之间是有距离的, 太远关系逐渐疏离, 最终形同陌路; 太近就相互刺伤. 对朋友关系描述最贴切的故事就是: 两只刺猬取暖, 太远取不到温暖, 太近刺伤对方, 必须保持一个既能取暖又不刺伤对方的距离. 迪米特法则就是对这个距离进行描述, 即使是朋友类之间也不能无话不说, 无所不知.
注意: 迪米特法则要求类 "羞涩" 一点, 尽量不要对外公布太多 public 方法和非静态的 public 变量, 尽量内敛, 多使用 private,package-private,protected 等访问权限.
(3)是自己的就是自己的
在实际应用中经常会出现这样一个方法: 放在本类中也可以, 放在其他类中也没有错, 那怎么去衡量呢? 你可以坚持这样一个原则: 如果一个方法放在本类中, 既不增加类间关系, 也对本类不产生负面影响, 那就放置在本类中.
(4)谨慎使用 Serializable
3. 最佳实践
迪米特法则的核心观念:
类间解耦, 弱耦合, 只有弱耦合了以后, 类的复用率才可以提高. 其要求的结果就是: 产生了大量的中转或跳转类, 导致系统的复杂性提高, 同时也为维护带来了难度. 所以我们在采用迪米特法则时, 需要反复权衡, 既做到让结构清晰, 又做到高内聚低耦合.
二, 开闭原则
1. 定义
一个软件实体如类, 模块和函数应该对扩展开放, 对修改关闭.
注意:
开闭原则对扩展开放, 对修改关闭, 并不意味着不做任何修改, 低层模块的变更, 必然要有高层模块进行耦合, 否则就是一个孤立无意义的代码片段.
变化可以归纳为如下三类:
(1)逻辑变化
只变化一个逻辑, 而不涉及其他模块, 比如原有的一个算法是 ab+c, 现在需要修改为 ab*c, 可以通过修改原有类中的方法的方式来完成, 前提条件是所有依赖或关联类都按照相同的逻辑处理.
(2)子模块变化
一个模块变化, 会对其他的模块产生影响, 特别是一个低层次的模块变化必然引起高层模块的变化, 因此在通过扩展完成变化时, 高层次的模块修改是必然的.
(3)可见视图变化
可见视图是提供给客户使用的界面, 如 JSP 程序, Swing 界面等, 该部分的变化一般会引起连锁反应(这个连锁反应, 我相信使用过 JSP 作为视图层的朋友们都深有感触)
2. 为什么要采用开闭原则
都说开闭原则是非常重要的, 可通过以下几个方面来理解其重要性:
(1)开闭原则对测试的影响
(2)开闭原则可以提高复用性
(3)开闭原则可以提高可维护性
(4)面向对象开发的要求
3. 如何使用开闭原则
(1)抽象约束
抽象是对一组事物的通用描述, 没有具体的实现, 也就表示它可以由非常多的可能性, 可以跟随需求的变化而变化. 因此, 通过接口或抽象类可以约束一组可能变化的行为, 并且能够实现对扩展开放, 其包含三层含义:
第一, 通过接口或抽象类约束扩展, 对扩展进行边界限定, 不允许出现在接口或抽象类中不存在的 public 方法;
第二, 参数类型, 引用对象尽量使用接口或抽象类, 而不是实现类;
第三, 抽象层尽量保持稳定, 一旦确定即不允许修改;
(2)元数据控制模块行为
尽量使用元数据来控制程序的行为, 减少重复开放.
什么是元数据?
用来描述环境和数据的数据, 通俗地说就是配置参数, 参数可以从文件中获得, 也可以从数据库中获得.
(3)指定项目章程
在一个团队中, 建立项目章程是非常重要的, 因为章程中指定了所有人员都必须遵守的约定, 对项目来说, 约定优于配置.
(4)封装变化
对变化的封装包含两层含义:
第一, 将相同的变化封装到一个接口或抽象类中;
第二, 将不同的变化封装到不同的接口或抽象类中, 不应该由两个不同的变化出现在同一个接口或抽象类中;
封装变化, 也就是受保护的变化, 找出预计有变化或不稳定的点, 我们为这些变化点创建稳定的接口, 准确地讲是封装可能发生的变化, 一旦预测或 "第六感" 发觉有变化, 就可以进行封装, 23 种设计模式都是从各个不同的角度对变化进行封装的.
4. 最佳实践
我们在使用开闭原则时要注意以下几个问题?
开闭原则也只是一个原则(开闭原则只是精神口号, 实现拥抱变化的方法非常多, 并不局限于 6 大设计原则, 但是遵循这 6 大设计原则基本上可以应对大多数变化);
项目规章非常重要(优秀的章程可以给项目带来很多好处, 如提高开放效率, 降低缺陷率, 提高团队士气, 提高技术成员水平等);
预知变化(适应未来的变化, 比如未来新增某项功能需求, 在不影响现有的架构下, 轻松扩展就能实现等);
来源: https://www.cnblogs.com/youcong/p/11808774.html