use*_*544 5 java refactoring interface
我一直试图遵循马丁先生和其他人的建议，保持小班授课。很小，只有一个理由换班级。但现在我面临着一个困境，我认为这不会那么方便。
我有一个 s 的接口GenericDatabase。该接口定义了任何实现都必须实现的所有方法（例如getUsers，getUser(id)等），可能有 30 或 40 个。
这种方式非常方便，因为类只需实现该接口，代码就可以与不同的特定数据库无缝协作。然而，问题是这样的实现可以达到+7000行长（上帝级）。
我过去通常所做的就是根据数据库管理的对象将数据库功能划分为不同的类。但它仅适用于一种固定的数据库实现。现在，我可以根据数据库对象（用户、文档等）将功能划分为不同的接口，但维护起来似乎更加负担。首先，我不能保证数据库实现实现所有接口。然后，开发人员需要创建大约 20 个不同的类来实现 20 个不同的接口，而在此之前，所有内容都可以在实现单个接口的单个类中找到。所以我不确定这是否是始终保持班级规模较小的规则的例外。
如何重构这个类/设计？
请记住，基本规则是：您总是更喜欢由简单事物组成的复杂网络，而不是由复杂事物组成的简单网络。
要点是：一旦接口（以及因此实现的类）变得太大，它们（几乎自动地）就会违反单一职责原则。迟早（更确切地说：更快）这意味着您最终会得到那些“太大”的大类，而不是小的“可理解”单元。
再次强调：选择小班授课的主要动机是，当“整体”足够小以“适合”您的大脑时，您的大脑更能更好地理解“整体”。
所以，是的 - 这可能意味着您想出了一系列界面。还有更多的类来实现它们。复杂性就像水：你无法压缩它——你只能选择它如何“流动”。
除此之外，领域驱动设计在这里也可能有一些好的建议 - 例如，关于并非所有方法都属于实体这一事实-有时让服务类负责对实体“做某事”更有意义（而不是让实体自己实现该方法）。
鉴于OP的评论：人们必须明白，很难对这种“通用”输入提出具体建议。为了真正提出有用的界面（它们本身更有意义，足以“弥补”拥有许多界面的成本），人们必须坐下来看看真正的需求。意思是：目前无法给出更具体的建议。这只能通过 OP（和他的同事）坐在一起并仔细进行实验来确定哪种设计选项最适合他们的需求来解决。