单一职责原则：变更原因的粒度

Question

当应用单一职责原则并查看类的更改原因时，如何确定更改原因是否太细粒度或不够细粒度？

Answer 1

我不知道这是一个很好的答案，而不是“根据您的经验应用您的判断”。失败了，得到帮助，我想这就是您在这里做的；）

不过，说真的，如果您发现您正在创建无数的类来完成看似简单的工作，那么您可能太细粒度了。如果你的类看起来都很大，那么你可能太粗俗了。如果这是显而易见的陈述，请原谅我。

我认为这是那些模糊的、没有硬性规则的案例之一，它向我们展示了为什么我们需要人类程序员。只要尝试一些事情，寻求平衡，如果您发现自己在一个方向或另一个方向走得太远，就进行重构。并记住： 如果值得做，那就值得做得不好.

Answer 2

1. 最初我不会太担心粒度。我最初会在更广泛的层面上进行关注点分离。基本点是我们应该避免过度设计。但就够了。我同意 卢卡斯 在此，第一步将随着经验的积累而改进。
2. 随着需求的变化，当我开始感觉到“气味”，当我对问题的理解提高时，我会通过在它们变得明显时剔除单独的关注点来重构设计。基本上，与整体设计一样，关注点分离也应该是渐进的。