【发布时间】：2009-12-26 18:32:17
【问题描述】：
我正在重构几个月前编写的一些代码，现在我发现自己创建了很多小型类（很少的属性、2-4 个方法、1-2 个事件）。
这是应该的吗？还是这也有点代码味道？
我的意思是，如果一个类确实需要很多方法来履行它的职责，我想这就是它的样子，但我不太确定很多小类是不是特别好的实践？
【问题讨论】：
标签： c# design-patterns single-responsibility-principle
【发布时间】：2009-12-26 18:32:17
【问题描述】：
很多小班听起来不错:)
特别是如果你让每个类实现一个接口，让不同的协作者通过这些接口而不是直接相互通信，你应该能够实现所谓的Supple Design（一个术语来自Domain-Driven Design)，有很多松散耦合。
如果您可以将其归结为重要操作具有与输入相同类型的输出，您将实现 Evans 所说的 操作闭包，我发现这是一个特别强大的设计技术。
当您应用 SRP 时往往会发生的情况是，尽管所有类一开始都很小，但您会不断进行重构，并且有时会突然发现一些特定的类可能比以前更丰富假设。
这样做，但要永远重构:)
【讨论】：
srp 的宗旨是开展许多职责集中的小班教学。所以，是的，就 srp 倡导者而言，这就是“应该是”的方式。但是您看到系统中的类数量呈爆炸式增长，并且开始变得非常难以记住或直观地知道事情实际在哪里完成，不是吗？实际上，您正在暴露一种新的代码气味，这是 srp 带来的（通常是不必要的）复杂性增加。我写了一篇关于它的条目here。看看你是否同意。
【讨论】：
我认为你必须找到中间道路。太多的类有时是矫枉过正的。从我的角度来看，我尝试在较小的级别上分离关注点，如果事情变得更粗粒度，则重构：
首先通过提取方法编写单独的关注点。如果你能看到一组关于数据的方法（实例+静态字段）形成一个专门的责任'提取类'。一段时间后，如果您可以看到包内的不同类分组，请执行“提取包”。
我发现这种（爆炸式）方法更自然，因为从一开始就创建了许多类和包。但这也取决于...：如果我一开始就可以看到更大的组件，我已经创建了专用的包结构。
也许有关您的代码的更多详细信息可以提供更具体的帮助:)
【讨论】：