尝试将组件划分为逻辑元素时代码结构中的问题

问：

我的团队编写了一个 url 数据库。 我正在进行一些重组以优化它。由于我也将成为它的维护者，因此我想到了添加可读性重构。但是，我有一种情况，我的 OOP 直觉说我应该做一个改变，这在实际中没有意义。 我想知道如何解决这种不和谐。

以下是数据库和问题的基本描述。

它使用一组 url、url 功能和元数据的磁盘上的 sstables。sstable 分为几类。 数据库支持加载请求，这些请求告诉它将类别上传到 ram。它只保留 url 键及其功能。（当内存不足时，它会删除最近使用最少的类别）。 查找请求其功能超过某个线性阈值（查找指定的功能分数的加权总和）的 URL。数据库尝试查找其功能满足查找请求的键。然后，它从磁盘返回完整查询。

在当前实现中，查找会要求提供 DataShard 结构列表，其中包含数据和 sstable 路径。它查找相关键，然后通过打开路径来查找完整查询。

警员本身不是由我的团队管理的。 我知道加载功能必须知道 sstable 的结构才能知道如何加载，但在我看来，在这种植入中，查找类知道太多的缓存结构。

因此，对我来说，将 DataShard 作为一个具有自己逻辑的类是有意义的。它将公开一个查找函数，该函数从单个 sstable 中获取完整的查询。该类将知道要素和元数据的划分，并且下划线系统是使用 sstable 实现的。但查找本身只会优先考虑分片内请求，并统一来自不同分片的结果。

但是，当我在实践中查看此实现时，它是最糟糕的。 事实上，我知道谁实现了分片查找，这意味着我不需要在分片查找中测试不可能的边缘条件。例如，我知道查找会覆盖一组有限的数据，因此它们不会永远卡住。如果我进行除法，lookup 只能“知道”DataShard.lookup 的签名告诉它什么。这将意味着更多的测试。 此外，假设 sstables 没有改变，我看不到这种划分的实际优势。

因此，我问 stackoverflow 的可读性专家，应该如何划分查找职责，为什么？

PS 代码是 cpp，但我认为这无关紧要。