问SRP和很多类

EN

很多小班听起来还不错:)

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

如果您能将其简而言之，使重要的操作具有与输入相同类型的输出，那么您将实现Evans所说的操作的闭包，我发现这是一种特别强大的设计技术。

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

做到这一点，但永远保持重构:)

srp的全部内容就是大量具有集中职责的小班。所以，是的，对于srp倡导者来说，这就是事情“应该是这样的”。但是，您看到系统中类的数量呈爆炸式增长，并且开始变得非常难以记住或直观地知道实际在何处完成了操作，不是吗？实际上，您暴露了一种新的代码味道，这是srp带来的(通常不必要的)复杂性增加。我写了一个关于它的条目here。看看你会不会同意。

我认为你必须找到折中的办法。太多的类有时会被过度杀伤力。从我这方面来说，我尝试在较小的层次上分离关注点，如果事情变得更好，那么就会重构出更粗糙的粒度：

首先通过提取方法来编写单独的关注点。如果你可以在数据(实例+静态字段)上看到一组方法来形成一个专门的责任‘提取类’。一段时间后，如果您可以看到包中的不同类分组，请执行“提取包”。

我发现这种(爆炸)方法更自然，因为从一开始就创建了大量的类和包。但这也取决于...：如果我一开始就能看到更大的组件，我就已经创建了专用的包结构。

可能需要更多关于您的代码的详细信息，以提供更具体的帮助:)