我一直试图遵循马丁先生和其他人的建议来保持我的课程小。很小，只有一个理由改变一个班级。但现在我面临一个两难的境地，我认为这不会那么方便。
我有GenericDatabase的界面。此接口定义了任何实现必须实现的所有方法（例如getUsers，getUser(id)等），可能是30或40个。
这种方式非常方便，因为类只需实现该接口，代码将与不同的特定数据库无缝协作。然而，问题是这样的实现可以获得+7000行（神级）。
我过去通常做的是根据他们管理的对象将数据库功能划分为不同的类。但它只适用于一个固定的数据库实现。现在，我可以根据数据库对象（用户，文档等）将功能划分为不同的接口，但是维护似乎更有负担。首先，我不能保证数据库实现实现所有接口。然后，开发人员需要创建20个不同的类，实现20个不同的接口，之前可以在实现单个接口的单个类中找到所有内容。所以我不确定这是否是规则的例外，总是让你的班级变小。
如何重构此类/设计？
答案 0 :(得分：2)
请记住，基本原则是：您总是喜欢简单的复杂网络，而不是复杂事物的简单网络。
重点是：一旦接口（因此实现类）变得太大，它们（几乎自动地）就违反了单一责任原则。而且迟早（而不是更早）这意味着你不会选择那些“可以理解”的小单位而是那些只是“太大”的大型课程。
再次说明：主要更喜欢小班级的动机是，当“整件事情”小到足以“适应”你的大脑时，你的大脑会更好地理解“整件事”。脑。
所以，是的 - 这可能意味着你想出了一系列接口。还有更多实现它们的类。复杂性就像水：你无法压缩它 - 你只能选择它如何“流动”。
除此之外，域驱动设计在这里也可能有一些好的建议 - 例如关于并非所有方法都属于实体的事实 - 有时候让更有意义服务类，负责与实体“做某事”（而不是让实体实现该方法本身）。
鉴于OP的评论：人们必须明白， hard 对这种“通用”输入提供具体建议。为了真正提出有用的接口（这些接口更有意义，足够的意义来“弥补”具有许多接口的成本）必须坐下来看看真正的要求。含义：此时无法提供更具体的建议。这只能由OP（及其同行）坐在一起仔细进行实验来确定哪些设计选项最适合他们的需求。
答案 1 :(得分：0)
让你的班级变小是一种尝试避免给一个班级承担多项责任的方法。我看到的问题是你的界面试图做太多事情。
如果您正在使用单独的商务层，我建议您查看Repository pattern。模型的每个概念都有他关心的少量方法，这就是他所链接的界面。每个接口可能有一个或多个不太大的实现。也许，他们中的一些人可以继承或合作没有责任的数据库助手（创建连接，创建准备好的声明等等）。