C# SRP和许多类

我正在重构几个月前编写的一些代码，现在我发现自己创建了很多小类（很少有属性、2-4个方法、1-2个事件）

应该是这样的吗？或者这也是一种代码气味

---

我的意思是，如果一个类确实需要很多方法来履行它的职责，我想这就是它应该具备的条件，但我也不确定很多小班是否是特别好的做法？

很多小班听起来很好：）

特别是，如果让每个类实现一个接口，并让不同的协作者通过这些接口而不是直接相互通信，则应该能够实现所谓的具有大量松散耦合的柔性设计

如果你能把它简化，使重要的操作具有与输入相同类型的输出，你将实现Evans所说的操作的关闭，我发现这是一种特别强大的设计技术

当您应用SRP时，可能会发生的情况是，尽管所有类都是从小开始的，但您会不断地进行重构，并且不时会有一些突发的见解澄清，一些特定的类可能比之前假设的要丰富得多

---

做到这一点，但要永远保持重构：）

srp的全部内容是许多具有集中职责的小型类。因此，是的，就srp倡导者而言，事情应该是这样的。但是你看到你的系统中的类的数量在爆炸，并且开始变得很难记住或者直观地知道事情实际上在哪里完成，不是吗？事实上，您正在暴露一种新的代码气味，这是srp带来的（通常是不必要的）复杂性增加。我写了一篇关于它的文章。看看你是否同意。

我认为你必须找到折衷的办法。太多的类有时是多余的。从我的角度来看，我尝试在较小的层面上分离关注点，如果事情进展顺利，则重构出更粗粒度的关注点：

首先通过提取方法编写单独的关注点。如果您可以在数据（实例+静态字段）上看到一组方法，以形成一个专用的职责“提取类”。一段时间后，如果你能在一个包中看到不同的类分组，你可以“提取包”

我发现这种（爆炸式）方法更自然，因为从一开始就创建了很多类和包。但这也取决于…：如果我一开始就可以看到更大的组件，那么我已经创建了专用的包结构

也许可以提供更多关于代码的详细信息，以提供更具体的帮助：）