使我的类和方法尽可能小？

Question

几天前，我和一位软件工程PhD候选人交谈，她对我说：

保持类和方法尽可能小。

我想知道这是否总是一种好的做法。

我的意思是，举个例子，一个只有两种态度的班级值得吗？例如，在某些方法中，我需要一对整数来处理。我应该写一个"PairOfIntgers“类吗？

这种思维方式会不会“破译”过多的代码？

Answer 1

这一建议有一点道理，但IMHO没有很好地表达出来，因此很容易被误解和/或采取一个愚蠢的极端。无论如何，这应该是一条经验法则，而不是硬法律。在这样的规则中，你应该始终暗示“在合理范围内”或“但不要忘记使用你的常识”:-)

真理的精髓是，在实践中，阶级和方法往往是自然增长的，而不是缩小的。这里有一个bug修复，那里有一个小的特性扩展，处理那里的一个特例.瞧，你曾经整洁的小班开始膨胀了。随着时间的推移，您的代码几乎不可避免地会变成一团乱七八糟的意大利面--除非您通过重构积极地与这种趋势作斗争。重构几乎总是从几个大类/方法中产生许多较小的类/方法。但当然，小型化有一个合理的限制。重构的意义不在于拥有更小的类和方法本身，而在于使代码更简洁、更易于理解和维护。在某种程度上，使您的方法/类更小开始降低可读性，而不是增加可读性。朝着最优的方向。这是一个模糊和移动的目标区域，所以你不需要击中它的地点。只有每当您注意到代码有问题时，就稍微改进它。。

Answer 2

这里需要强调的更重要的问题是创建良好的抽象。松散耦合并具有高度内聚力的小类是良好抽象的产物。

有时，将两个整数封装在一个类中是非常有意义的。特别是如果您希望将方法“附加”到这个类中，以封装如何操作这些属性，并确保您保护它们不受程序其他部分更改它们的影响。

在这种情况下创建类的另一个积极方面是，类可以比更低级别的数据结构(比如Map或List )进化得更好/更好。

第三，一个好的抽象可以大大提高可读性。遵守SRP的类通常比不遵守SRP的类容易理解。

最后一个音符..。不管你是个多好的学生.要理解面向对象( OOP )和良好的抽象以及何时使用它们，您需要经验。您需要编写糟糕的代码，并通过痛苦来维护它。你需要看到其他人写好代码来积累你对什么是“好”的知识，以及什么将是一个问题。所以，如果你不马上得到它，就不要自责。

Answer 3

上帝对象反模式可能是她所指的。我确实倾向于认为，如果我的课堂描述中有“和”，我应该有两门课。如果方法/函数中有十行以上的代码，那么我应该将其分解。作为海盗密码，这些更多的是准则而不是规则。