我的团队写了一个 url db。 我正在进行一些重组以优化它。因为我也将成为它的维护者，所以我想到了添加可读性重构。但是，我有一种情况，我的 OOP 直觉告诉我应该做一些改变，这实际上没有意义。 我想知道如何解决这种不和谐。
以下是数据库的基本描述，以及问题。
它使用一组磁盘上的 url、url 特征和元数据的 sstables。 sstable 分为几类。 db 支持加载请求，告诉它上传一个类别到 ram。它只保留 url 密钥及其功能。 （当内存不足时，它会删除最近最少使用的类别）。 查找请求要求其特征通过某个线性阈值（查找指定的特征分数的加权和）的 url。数据库尝试查找其特征满足查找请求的键。然后它从磁盘返回完整的查询。
在当前的实现中，查找需要一个 DataShard 结构列表，其中包含数据和 sstable 路径。它查找相关键，然后通过打开路径查找完整查询。
sstables 本身不由我的团队管理。 我知道加载功能必须知道 sstables 的结构才能知道如何加载，但在我看来，在这种植入中，查找类对缓存结构了解得太多了。
所以让 DataShard 成为一个具有自己逻辑的类对我来说是有意义的。它将公开一个查找函数，该函数从单个 sstable 中获取完整的查询。这个类会知道特征和元数据的划分，并且下划线系统是用sstables实现的。但是查找本身只会对分片内的请求进行优先排序，并统一来自不同分片的结果。
然而，当我在实践中看这个实现时，它是最糟糕的。 我知道谁实施了分片查找这一事实意味着我不需要在分片查找中测试不可能的边缘条件。例如，我知道查找会遍历一组有限的数据，因此它们不会永远停滞不前。如果我做了除法，lookup 只能“知道”DataShard.lookup 的签名告诉它什么。这将意味着更多的测试。 另外，假设 sstables 不变，我看不出这种划分的实际优势。
所以我问stackoverflow的可读性专家，查找职责应该如何划分，为什么？
P.S 代码是 cpp，但我认为这不相关。