SRP和很多课程

Question

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

它应该如何？或者这也有点代码味道？

我的意思是，如果一个班级确实需要很多方法来履行它的责任，我想这就是它的必要条件，但是我不太确定很多小班也是特别好的做法？

Answer 1

很多小班听起来都不错:)。

特别是如果让每个类实现一个接口并让不同的协作者通过这些接口进行通信而不是直接相互通信，那么你应该能够实现所谓的 Supple Design （一个术语）来自Domain-Driven Design）有很多松耦合。

如果你可以把它煮熟以便重要的操作与输入具有相同类型的输出，你将实现Evans所说的关闭操作，我发现这是一个特别强大的设计技术

当您应用SRP时会发生的事情是，尽管所有课程都很小，但您不断进行重构，并且不时发生的是，一连串的洞察力澄清了一些特定的课程比以前更丰富假设

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

Answer 2

很多具有专注责任的小班是srp的全部内容。所以，是的，就srp倡导者而言，这就是“应该是”的方式。但是你看到系统中类的数量激增，它开始变得非常难以记住或者直观地知道事情的实际发生地，不是吗？实际上，你正在暴露出一种新的代码气味，这是与srp相关的复杂性（通常是不必要的）增加。我写了一篇关于它的条目here。看看你是否同意。

Answer 3

我认为你必须找到中途。太多的课程有时候是矫枉过正的。从我的角度来看，我尝试将关注点放在较小的层面上，如果事情发生了，那么重构更粗糙：

  

首先通过提取方法来编写单独的问题。如果您可以在数据（实例+静态字段）上看到一组方法，以形成专用的“提取类”。过了一会儿，如果你能在包中看到不同的类分组，那就“提取包”。

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

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