保持我的类和方法尽可能小？

20

几天前，我正在与一名软件工程博士候选人交谈，在某个时候她对我说：

保持类和方法尽可能的小

我想知道这是否总是一个好习惯。

我的意思是，举个例子，只上两副服装值得吗？例如，在某些方法中，我需要使用成对的整数。我应该写一个“ PairOfIntgers”类吗？

这种思维方式可以将代码“破坏”太多吗？

code-quality coding-style

— 弗洛伦斯·谢莱
source

10

那应该是"As small as possible, but no smaller."

— StuperUser 2011年

“我的意思是，举个例子，只穿着两个服装是值得的吗？” -它可以是，搜索“原始痴迷”（例如jamesshore.com/Blog/PrimitiveObsession.html）

— 托斯滕

我认为混乱的根源是“可能”一词。如果“可能”仅指代代码，则该原理变得很荒谬，因为做任何有用的事情的最小可能类只有一个方法（在某些情况下为零）。候选人很可能打算考虑凝聚力和耦合性。

— 开尔文

23

该建议有一定道理，但恕我直言，它的表达方式不够好，因此容易被误解和/或愚蠢到极致。无论如何，这应该是一个经验法则，而不是硬性法律。并且您应该始终在此类规则中暗指“在合理范围内”或“但不要忘记使用您的常识” :-)

事实真相是，在实践中，阶级和方法总是倾向于自然发展，而不是萎缩。这里的错误修复，那里的功能扩展，在那里处理特殊情况……瞧，您曾经整洁的小班学习开始膨胀。随着时间的流逝，您的代码几乎不可避免地会变成一团糟的意大利面-除非您通过重构积极地对抗这种趋势。重构几乎总是从几个大类中产生许多较小的类/方法。但是，当然，缩小尺寸是明智的。重构的目的不是使类和方法本身变小，而是使代码更整洁，更易于理解和维护。。在某个时候，使您的方法/类更小会降低可读性，而不是增加可读性。追求最佳。这是一个模糊且移动的目标区域，因此您无需将其击中。只要发现有问题，就对代码进行一些改进。

— 佩特·托罗克
source

1

绝对不能盲目遵循的规则，太多的小班多数情况下要比几个大班差很多。

— Ryathal 2011年

4

我个人的经验法则是：如果您无法一次在屏幕上看到整个方法的实现，请进行重构。

— 丹·雷

6

@DanRay，是的，在我阅读Clean Code之前，我曾经有同样的规则。这真是令人震惊，但逐渐使我的最优值下降到大约10行。

— 彼得Török

2

国际海事组织清洁法典的极端之处在于采用小方法。问题在于，当方法变小时，将会有更多的方法。当然，太长的方法太长了，但是鲍勃·马丁似乎比10个1行的方法更喜欢10个1行的方法（因此，有效的相同代码占用大约5倍的屏幕空间）。也许这是某种教育技巧，我无法相信有人实际上认为那本书中的代码有什么用。

— Joonas Pulakka 2011年

5

@JoonasPulakka-让我们说我从未读过一种方法，并想：“我希望这种方法能做更多。” 通过缩短方法，您可以编写非常具有描述性的方法名称，而这些名称通常可以消除完全读取方法主体的需要。我发现“ 清洁代码”中的建议非常明智。我们只需要同意不同意。:)

— David Harkness 2012年

9

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

有时在一个类中封装两个整数是很有意义的。尤其是如果您希望将方法“附加”到此类上，以封装如何处理这些属性的方式，并确保您保护它们免受更改它们的程序其他部分的影响。

在这种情况下，创建类的另一个好处是，与可以说像Map或List这样的较低级别的数据结构相比，该类可以发展得更好/更好。

第三，良好的抽象可以极大地提高可读性。坚持SRP的课程通常比不理解SRP的课程容易理解。

最后要说的是……无论您的学生多么优秀……要了解OOP和良好的抽象，以及何时使用它们，都需要经验。您需要编写错误的代码并经历痛苦来维护它。您需要看到其他人编写好的代码来建立关于什么是“好”以及什么是问题的知识……因此，如果您不马上就不要打败自己。

— c_maker
source

2

她可能在暗示上帝之物反模式。我确实倾向于认为，如果我的班级描述中有一个“和”，我应该有两个班级。如果一个方法/函数中有十行以上的代码，则应该将其分解。作为盗版代码，这些准则比规则更多。

— Sardathrion-恢复莫妮卡
source

2

在面向对象的编程中，单一责任原则规定每个对象应具有单一责任，并且责任应完全由类封装。如果班级太大，通常您会做一件事。在您的情况下，该类只是一个数据类，它完全可以容纳数据。您不应将类命名为PairOfInteger。整数描述什么？根据您的情况，一个元组（如C＃）可能也足够。您可能想考虑一个支撑而不是一个类。

尝试使您的课程小一些。而且方法更小。也许10行？！？当前，我正在尝试使用流设计和基于事件的组件，这似乎有助于使类保持较小。首先，我担心上很多课，但确实有效！！！ http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/19/flow-design-cheat-sheet-ndash-part-i-notation.aspx http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03 /20/flow-design-cheat-sheet-ndash-part-ii-translation.aspx

— CT
source

2

使事情尽可能简单，但不要简单。这就是我要遵守的规则。有时，如果某类事情与某个共同的主题有关，那么严格意义上讲，要做一件事实际上对一个班级来说是有意义的。看.NET；有很多实现大量接口的类，每个类都有自己的所需成员列表。如果一个方法要通过许多相互关联的中间步骤来做复杂的事情，那么它最终可能会变得有些长，因此无法很好地用于进一步的重构。（重构保持简短的方法最终应该与可读性和可维护性有关；如果长方法比短方法更具可读性和/或可维护性，那么在其他所有条件相同的情况下，我将每天花较长的时间。）

在我看来，仅“使类和方法尽可能小”是错误的。正如@c_maker所指出的那样，真正的挑战是提供良好的抽象。例如，如果您正在执行复数算法的实现，或者在Unix系统上需要引用用户/组上下文，那么将两个数字组合在一起的示例就很好。如果数字代表要添加到该发票的发票ID和产品ID，则意义不大。

— 简历
source

0

可以的建议，但需要以智能的方式实施。绝对不要盲目跟随它。

当我查看代码时，我知道方法是否太大。如果它做得太多，并且很难阅读，那就是重构时间。

这是一个很好的例子：您有一个循环，并且该方法中可能有60行代码。在这种情况下，可能是重构的时候了，因为您可能在该方法中做了太多事情。

但是，这不是一个硬性规定。这只是您从中学到的东西。而且，您与我合作的其他开发人员并不总是同意的，他们可能会在代码审查中或其他方面要求您。

— 艾伦·德利蒙（Alan Delimon）
source

永远不要缩小方法，而要遵循SRP，它将自动完成工作。

— Vinay Prajapati

0

Bob叔叔说您应该重构/拆分/提取方法 直到不可能将其缩小。通常以几种方法（每行3或4行）结束。当方法太多时，必须创建更多的类。

如果您尝试遵循SRP和每种方法的一种抽象级别，那么这些规则将为您提供很好的服务。至少他们对我有用。争取“越小越好”为我提供了合理的小方法，因为我通常达不到目标。

而且，理解较小的类总是更容易。继续阅读“清洁代码”

— 彼得·科夫勒
source