我正在研究一项功能，并且对方法的长度感到困惑。阅读了某些要点，但不确定什么是最好的或标准的
- 一种方法应该只要执行它所设计的任务所需的时间。
- 无需滚动即可阅读整个方法，并且适合页面。
还有其他点。我有一个静态辅助方法，其长度正在增加，因此我可以选择创建更多静态辅助方法并将任务分配给这些方法，但看起来我正在创建不必要的静态方法。
其他方法是创建另一个助手类并将一些工作委托给助手类中定义的方法
我不确定这样做的最佳方式/标准方式是什么。
问问题
2248 次
1 回答
1
一般来说，这两点都是非常值得考虑的事情。您已经提到的主要原因之一：它使代码更具可读性和易于消化。
拆分方法和创建辅助方法的另一个好处是不会立即显现出来。取而代之的是，有一天您将在一个拥有客户用户的系统上工作，并且您需要实现一项功能，您需要在其中创建管理员用户、供应商或某个人的其他抽象版本.
您会发现自己在考虑如何将供应商的订单或供应商的任何东西保存到数据库中，并且您需要生成某种形式的东西来识别订单，而您您将意识到您为客户执行相同操作而编写的代码将与 Vendor 对象和 Customer 对象一起使用。
但是，如果所有这些代码在处理与客户相关的所有内容的同一方法中都很强大，那么您将使用我们所说的剪切和粘贴可重用性。这涉及检查您之前编写的代码并剪切和粘贴相关部分并创建一个大部分相似但有非常细微差异的副本。（注意：这通常被认为是一种不好的做法。）
但是，当您编写小而简洁的方法，只做一件事，并且把一件事做得非常好时，您会发现您能够利用已经构建的那些构建块，然后使用它们构建其他东西，从而节省您的时间，节省质量保证时间，总体上降低项目的维护成本，让产品向前发展，让你向前发展，做更酷的事情。
但是，要考虑的最后一点是，可能会过度使用它或过度架构。太长和太短之间有一条细线，你可能会想把你的方法分开太多。如果你到了拆分方法变得难以使用的地步，那么请考虑一下你可能走得太远了。祝你好运！
于 2012-05-25T05:30:46.050 回答