java - 接口(interface)实现避免大类

Question

我一直努力听从 Martin 先生和其他人的建议，让我的类(class)保持小规模。很小，只有一个换类的理由。但现在我面临一个两难境地，我认为这不会那么方便。

我有一个用于 GenericDatabase 的接口(interface)。此接口(interface)定义了任何实现必须实现的所有方法(例如 getUsers、getUser(id) 等)，可能有 30 或 40 个。

这种方式非常方便，因为一个类只需要实现那个接口(interface)，代码就可以无缝地与不同的特定数据库一起工作。然而，问题在于这样的实现可以达到 +7000 行长(神级)。

我过去通常做的是根据它们管理的对象将数据库功能划分为不同的类。但它仅适用于一个固定的数据库实现。现在，我可以根据数据库对象(用户、文档等)将功能划分为不同的接口(interface)，但维护起来似乎更麻烦。首先，我不能保证数据库实现会实现所有接口(interface)。然后，开发人员需要创建大约 20 个不同的类来实现 20 个不同的接口(interface)，而以前一切都可以在实现单个接口(interface)的单个​​类中找到。所以我不确定这是否是始终保持小类(class)规则的异常(exception)。

如何重构此类/设计？

Answer 1

请记住，基本规则是:您总是更喜欢由简单事物组成的复杂网络，而不是由复杂事物组成的简单网络。

重点是:一旦接口(interface)(以及因此实现的类)变得太大，它们(几乎自动地)就会违反单一职责原则。迟早(更确切地说:更早)这意味着您最终会得到那些简单地“太大”的大类，而不是小的、“可以理解的”单元。

再说一次:选择较小类(class)的主要动机是这样一个事实，即当“整体”小到足以“适应”您的学习时，您的大脑更善于理解“整体”大脑。

所以，是的 - 这可能意味着您提出了一系列接口(interface)。还有更多实现它们的类。复杂性就像水:你无法压缩它——你只能选择它如何“流动”。

除此之外，领域驱动设计在这里也可能有一些好的建议 - 例如关于并非所有方法都属于 Entity 这一事实 - 有时 更有意义负责对实体“做某事”的服务类(而不是让实体自己实现该方法)。

鉴于 OP 的评论:人们必须明白，很难就此类“通用”输入提供具体建议。为了真正想出有用的界面(它们本身更有意义，足以“弥补”拥有许多界面的成本)必须坐下来看看真正的需求。意思是:目前无法给出更具体的建议。这只能由 OP(和他的同行)坐在一起并仔细进行实验以确定最适合他们需求的设计选项才能解决。