《代码整洁之道》第10章 类 - 笔记
类组织
- 大白话: 这一小节讲的是一个类内部成员(变量、方法)的排列顺序。它不像函数顺序那样有严格的“向下原则”,但也有一些推荐的组织方式,目的是提高类的可读性。
- 核心思想:
-
- 垂直距离要短: 互相调用的方法或者使用同一个变量的方法应该在代码中相互靠近。
- 高层在先: 公共的常量、静态变量通常放在前面,然后是私有变量,接着是公共方法,最后是私有方法。公共接口通常放在类定义靠前的位置,让你一眼看到这个类提供了什么功能。
- 为什么重要: 好的类内部组织能让阅读者更容易找到他们关心的信息,理解类成员之间的关系,而不是在一个大类里“迷路”。
- 类比: 整理你的书桌抽屉。经常一起使用的文具放一层,不常用的放另一层,同类物品(比如所有笔)放在一起。
类应该短小
单一权责是类的原则,类的名称应该描述其权责,命名正是可以帮助判断类的长度的第一个手段。如果无法为某个类精确的命名,这个类大概就大长了。
单一权责原则( SRP )
单一权责原则认为:类或模块应该只有一条加以修改的理由,如果同时有两个理由修改这个类,那么权责过多了
系统应该由许多短小的类而不是少量巨大的类组成,每个小类封装一个权责,只有一个修改的原因,并与少数其他类一起协同达到期望的系统行为。
保持内聚性就会得到许多短小的类
内聚:如果一个类的变量被所有的函数使用,那么这就是最高的内聚。这不太可能实现,比较高内聚倒是应该实现。
高内聚是遵循 SRP 的自然结果
将大函数拆为许多小函数,往往也是将类拆分为多个小类的时机。
为变更而组织
核心思想: 将那些因为同一个原因而可能一起改变的类放在同一个包或靠近的位置(这符合共同封闭原则 CCP - Common Closure Principle)。相反,将那些因为不同原因而改变的类分开放置(这符合共同重用原则 CRP - Common Reuse Principle)。
为什么重要: 当某个需求变化发生时,你只需要到项目的某个特定区域去修改代码,而不是在整个项目中东改一块、西改一块。这让修改变得更容易、更安全。
类比: 把同一个项目的所有文件放在同一个文件夹里。项目有改动时,你知道所有相关文件都在这个文件夹里。
隔离变更 (加个接口)
使用接口和抽象类来保护代码,使其不受实现细节变化的影响 ,更简单来说,不用直接调用实现类,而是调用接口,这样实现类任由你改,调用代码都不用改。
核心思想: 你的应用代码(特别是高层模块)应该依赖于抽象(接口或抽象类),而不是具体的实现类。这样,当底层实现发生变化时(比如数据库从 MySQL 换成 PostgreSQL,或者第三方库升级),依赖于接口的代码通常不需要修改。这呼应了依赖倒置原则 (DIP) 和我们之前在第八章讲的边界概念。
为什么重要: 这是实现系统灵活性的关键。它将“功能做什么”与“功能具体怎么实现”分离开来,让实现细节可以独立于使用它的代码而变化。