URL数据库重构：Lookup职责划分的OOP直觉与实践矛盾求解

核心原则：基于实际场景做最小化职责划分，拒绝为OOP教条过度抽象 #

• 保留Lookup模块对核心查询逻辑的掌控，剥离底层细节依赖

  • 具体操作：将DataShard从纯结构体改为轻量级类，仅封装缓存数据访问、sstables磁盘读取的细节逻辑。Lookup模块依然负责线性阈值匹配、分片请求优先级调度、查询结果合并这些核心流程。
  • 原因：你当前明确分片查询的边界（不会出现无限执行等极端情况），保留核心逻辑在Lookup中可以避免测试范围不必要的扩大；同时通过DataShard封装底层细节，解决当前Lookup对缓存结构了解过多的问题。

• 给DataShard暴露最小必要接口

  • 仅提供Lookup所需的关键方法，比如：
    • get_matching_keys(linear_threshold)：负责从内存缓存或磁盘sstables中筛选符合线性阈值的URL键
    • fetch_full_result(key)：根据指定键读取完整的URL元数据
  • 原因：既隐藏了sstables内部结构、缓存淘汰规则等底层细节，又不会让Lookup模块陷入黑盒困境——你依然能清晰知晓DataShard的能力范围，测试时只需针对这两个接口做基础验证，无需覆盖复杂的分片调度逻辑。

• 放弃完全按OOP职责拆分的方案（当前场景下）

  • 既然sstables由外部团队维护且无变更预期，过度封装DataShard的lookup逻辑只会增加冗余抽象层，反而降低代码可读性：当前你能直接追踪分片查询的全流程，拆分后反而需要跨模块梳理逻辑，提升了认知负担。
  • 原因：代码可读性的核心是让维护者快速理解全流程逻辑，而非严格遵循OOP设计原则。当底层依赖稳定时，适度的耦合反而能减少不必要的抽象跳转。

内容的提问来源于stack exchange，提问作者Nimrod Fiat