第3章 抽象接口设计原则：面向接口、依赖倒置与最小知识

3.1 原则定位：接口抽象的三层内核

在 Room 数据访问层架构中，抽象接口不是简单的 Java/Kotlin 语法选择，而是三个经典设计原则共同作用的结果。这三个原则分别从 契约形态、依赖方向 和 信息暴露面 三个维度，划定了访问层的边界与信任链路。

原则核心关注边界角色信任链路影响
面向接口编程组件之间通过契约通信，而非具体实现接口即为边界门面调用方只信任接口签名，不信任内部状态
依赖倒置高层模块不应依赖低层模块，二者都应依赖抽象反转依赖流向，控制权上移业务层不再依赖具体数据库驱动，核心逻辑稳定
最小知识原则一个实体只与最直接的接口交互限制对外暴露的方法集减少意外副作用，增强可替换性

这三个原则在 Room 中的落地并非各自为政，它们共同构建了一条从 业务服务 → DAO 接口 → Room 实现 → SQLite 的清晰信任链路。接口设计若违背其中任一原则，都会在后续迭代中暴露出耦合扩散、测试困难或职责臃肿的问题。

架构判断依据： 凡是需要调用方知道“接口背后的数据库是 SQLite 还是其他存储”的接口，均已违反依赖倒置；凡是单个 DAO 接口暴露超过 12 个方法的，通常已违反最小知识原则。

3.2 面向接口编程：契约即边界

面向接口编程 要求在数据访问层中，所有对数据库的操作都通过接口定义来完成，调用方只与接口耦合。在 Room 中，DAO 本身就是最典型的接口契约，但架构师需要进一步区分 框架接口 与 业务接口。

  • 框架接口： Room 自动生成的 DAO 实现，包含 @Insert、@Query 等注解方法，属于基础设施层。
  • 业务接口： 由上层业务服务定义的数据访问抽象，只声明业务语义方法（如 fetchActiveUsers() 而非 query("SELECT ...")），属于业务层。

数据流在业务接口处发生第一次方向变化：调用方 → 业务接口 → 框架 DAO 接口 → Room 实现 → SQLite。控制流则由业务服务发起，经过接口转发，最终由 Room 执行。信任链路的起点是业务接口的签名——只要签名不变，内部数据库变更、表结构调整都不会传导到业务层。

实践建议： 业务接口不应直接继承 Room 的 DAO 接口，而应通过适配器模式或仓库模式隔离。这保持了业务层对数据库框架的无知。

3.3 依赖倒置：谁拥有抽象

依赖倒置 强调：抽象不应依赖细节，细节应依赖抽象。在 Room 数据访问层中，这表现为业务层定义需要的操作接口，而 Room DAO 实现该接口，而非相反。

选型权衡在于抽象接口的归属层级：

抽象归属优点风险点
业务层定义接口，数据层实现业务完全掌控契约，数据库可替换接口语义可能偏离数据库特性，增加适配成本
数据层定义接口，业务层调用充分利用 Room 注解与类型安全业务层间接依赖 Room 框架，违反倒置原则
仓库接口独立成公共模块接口职责清晰，编译隔离模块拆分初期决策成本高，需考虑包名与版本管理

信任链路在此处发生关键逆转：业务层不再信任数据库的稳定性，而是信任自己定义的接口契约。只要业务接口不变，即便是从 Room 迁移到其他持久化方案，上层代码也无需修改。控制流跟随依赖方向：业务层通过接口向下发送请求，但接口的所有权属于上层。

常见陷阱： 很多团队在 DAO 接口上直接添加业务方法，导致一个 DAO 被多个业务服务依赖。一旦修改 DAO 接口签名，所有调用方都需要适配，本质上是违背了依赖倒置——业务被迫依赖具体 DAO 签名。

3.4 最小知识原则：接口的职责边界

最小知识原则 要求一个接口只向调用方暴露必要的方法，不多、不杂、不跨职责。在 Room 数据访问层中，这表现为每个 DAO 或仓库接口只处理一个聚合根的数据操作，不将多表关联、聚合查询、事务控制全部塞入同一接口。

接口方法数量与变更脆弱性呈正相关。当一个 DAO 接口包含超过 10 个方法时，任何一个方法的签名变更都会传播到所有消费者。最小知识原则通过控制方法集大小来降低耦合半径。

  • 数据流切割： 将写入、读取、批量、聚合操作分散到不同接口或同一接口的不同分组，避免调用方“顺便”拿到不该接触的方法。
  • 控制流收敛： 业务服务只调用与自己职责直接相关的方法，不关心其他实体的操作路径。
  • 信任链路限制： 每个接口的调用方只能信任该接口声明的功能，不能通过同一个接口间接操作其他聚合根。

3.5 三原则协同：接口设计检查表

接口设计落地时，三个原则同时起作用，任何单点突破都可能导致边界模糊。以下检查表用于评审现有或新设计的 DAO/仓库接口：

  1. 接口是调用方定义的还是实现方定义的？ —— 依赖倒置检查
  2. 调用方是否需要知道接口背后的数据库类型？ —— 依赖倒置检查
  3. 接口方法是否超过了 8 个？ —— 最小知识原则检查
  4. 接口中是否存在一个方法同时操作多个聚合根？ —— 最小知识原则检查
  5. 接口方法名是否体现了业务语义而非 SQL 细节？ —— 面向接口检查
  6. 该接口是否被多个不相关的业务模块依赖？ —— 最小知识原则检查

验收标准设定：每个接口都应能在不通知调用方的情况下，更换其背后的 Room DAO 实现或迁移到其他数据库，只要保持接口签名不变。

核心原则： 好接口让调用方觉得“理所当然”，坏接口让调用方觉得“我还要知道这么多”。

3.6 落地步骤：从原则到代码边界

  1. 步骤一： 识别数据访问需求，按聚合根划分职责域。每个聚合根对应一个仓库接口。
  2. 步骤二： 由业务层先定义接口契约，声明必要方法，只包含该聚合根必备的 CRUD 与查询。
  3. 步骤三： 在数据层创建 Room DAO，实现该接口。DAO 可以包含额外的 Room 注解方法，但这些方法不暴露给业务层。
  4. 步骤四： 构建仓库实现类，注入 DAO，并通过接口返回给业务层使用。
  5. 步骤五： 编写单元测试验证：更换 DAO 实现（如内存实现）后，业务逻辑应正常运行。

此过程确保接口的三条原则在编译期就可被验证，而不是等到运行时才发现耦合问题。

3.7 本章核心结构图

抽象接口三原则协同结构 · Room 数据访问层 业务层（调用方） 定义数据需求 不依赖具体实现 依赖倒置：拥有接口 业务接口 / 仓库接口 面向接口：契约即边界 最小知识：方法 <= 8 只暴露业务语义方法 无 SQL 细节 数据层（实现方） Room DAO 实现接口 内部可包含 Room 注解 细节依赖抽象 三原则联合作用效果 1. 依赖倒置：业务层定义接口，数据层实现接口，依赖方向从“业务→数据库”变为“数据库→业务接口”。 2. 面向接口：调用方只通过接口契约通信，不感知 Room DAO 内部实现细节。 3. 最小知识：每个接口只暴露与自身聚合根相关的有限方法，减少调用方的认知负担。 4. 信任链路：业务层 -> 业务接口 -> 仓库实现 -> Room DAO -> SQLite，每层只信任相邻前一层。 5. 验收标准：更换 DAO 实现（如内存数据库）时，业务逻辑无需修改。

3.8 风险点与选型权衡

风险点表现形式缓解策略
接口膨胀单一接口方法过多，调用方被迫依赖不需要的方法按聚合根拆分接口，引入 CQRS 分离读写接口
抽象泄漏接口方法中暴露了 Room 特有的类型（如 LiveData、Flowable）业务接口返回标准类型或自定义 Result 类
过度分层为满足依赖倒置，引入过多中间接口层只在职责边界处放置接口，内部实现不需要接口
测试假象伪造接口实现时，忽略了 Room 特有的查询优化与事务行为接口契约中明确事务边界与数据一致性保证
风险提示： 当团队在“是否应该为每个 DAO 都创建业务接口”上争论不休时，说明尚未厘清最小知识原则的职责域。此时可先为有明显替换需求的 DAO 创建接口，其余直接调用 Room DAO，后续重构。

3.9 验收标准

  • 编译隔离： 业务层代码不直接 import 任何 Room 相关的包（androidx.room.*）。
  • 接口可替换： 为任意业务接口编写一个内存实现后，业务层单元测试可通过，无需启动 Room 数据库。
  • 方法数量约束： 每个业务接口的方法数 ≤ 10，超出部分必须分组或拆分。
  • 语义清晰度： 接口方法名称不包含 “insert”、“query”、“delete” 等 SQL 术语，而使用业务术语（如 registerUser、findActiveOrders）。
  • 依赖方向检查： 使用 IDE 的依赖图功能，确认业务层模块不存在指向 Room DAO 实现类的依赖边。

以上标准应纳入 CI 门禁或代码评审检查项，确保每个数据访问接口在交付时都经过三原则校验。

← 上一章 📖 返回目录 下一章 →