It is always worth extracting methods if it clarifies the intent of the code.
This is especially true for very long methods. While comments are fine, they do not delineate (at least not in a very solid way) where the process it explains ends and where the next one begins. Sometimes common abstractions will only become more obvious after you've extracted the method.
If you are into automated unit-testing (not necessarily TDD), it will also be much, much easier to unit test smaller chunks of methods -- although you might have to make your methods public for that, depending on the testing framework you use.
The point is, you can't go wrong with smaller methods, especially if they have descriptive names.
As said above: It will generally clarify the intent of the code.
Even if it is only used once now, it will make it easier to reuse the code in the future.
An additional point: For simple helper methods, you might want to make them static (such that they do not depend on or alter the state of their instance), then you can make them public for even easier reuse.
For me it depends on how large the code is, and how related it is to what the parent method does. If it is a lot of code (say more than 5-10 lines of code, or more than 50% of the total amount of code in the parent method) I would extract it to a private method, for code structure and readability. Otherwise I would leave it in the parent method with a descriptive comment.
I think that maintainability and readability can be degraded if there are too many, very small methods in the code. I strive for a good balance. But whenever I doubt; I extract it as a private method.
您应该根据 API 和 API 的设计将其重构为私有。 您在其他地方使用时想要公开的方法/属性。 您不应该考虑它的用途来决定是否将其设为私有/公开。
You should refactor to private based on the design of your API & methods/properties you want to expose when using elsewhere. You shouldn't be considering it's usage to decide whether or not to make it private/public.
Just a dumb estimate, but I'd say the majority of private methods get called in only a couple of places in the average class. However as mentioned above, it makes your code much more readable and easier to test/maintain if you break all functionality into logical blocks. Refactoring is a good habit
发布评论
评论（6）
如果能够阐明代码的意图，那么提取方法总是值得的。
对于很长的方法尤其如此。 虽然注释很好，但它们并没有描绘（至少不是以一种非常可靠的方式）它所解释的过程在哪里结束以及下一个过程从哪里开始。 有时，在提取方法之后，常见的抽象只会变得更加明显。
如果您热衷于自动化单元测试（不一定是 TDD），那么对较小的方法块进行单元测试也会容易得多——尽管您可能必须为此公开您的方法，具体取决于您使用的测试框架。
关键是，使用较小的方法不会出错，尤其是当它们具有描述性名称时。
It is always worth extracting methods if it clarifies the intent of the code.
This is especially true for very long methods. While comments are fine, they do not delineate (at least not in a very solid way) where the process it explains ends and where the next one begins. Sometimes common abstractions will only become more obvious after you've extracted the method.
If you are into automated unit-testing (not necessarily TDD), it will also be much, much easier to unit test smaller chunks of methods -- although you might have to make your methods public for that, depending on the testing framework you use.
The point is, you can't go wrong with smaller methods, especially if they have descriptive names.
这样做有巨大的好处。 这都是关于信息隐藏，并使意图非常明确。
在《重构代码》中，他们将这种方法称为组合方法，您可以将一个大方法分解为许多较小的方法。 这有两件事。
首先，它减少了您在处理父方法时需要担心的信息量。
其次，方法的名称应该表明其意图，这使得代码更具可读性。
There is a huge benefit in doing this. It's all about information hiding, and making intentions very clear.
In Refactoring to Code they called this Composition Methods where you break a large method down into many smaller methods. This does two things.
First it reduces the ammount of information you need to worry about when working on the parent method.
Secondly the name of the method should indicate its intention which makes the code more readable.
是的。
附加一点：对于简单的辅助方法，您可能希望将它们设为静态（以便它们不依赖于或改变其实例的状态），然后您可以将它们公开以便更轻松地重用。
Yes, it is.
An additional point: For simple helper methods, you might want to make them static (such that they do not depend on or alter the state of their instance), then you can make them public for even easier reuse.
对我来说，这取决于代码有多大，以及它与父方法的功能的相关程度。 如果代码很多（比如超过 5-10 行代码，或者超过父方法中代码总量的 50%），我会将其提取到私有方法中，以提高代码结构和可读性。 否则，我会将其保留在父方法中并带有描述性注释。
我认为如果代码中有太多非常小的方法，可维护性和可读性就会降低。 我努力寻求良好的平衡。 但每当我怀疑时； 我将其提取为私有方法。
For me it depends on how large the code is, and how related it is to what the parent method does. If it is a lot of code (say more than 5-10 lines of code, or more than 50% of the total amount of code in the parent method) I would extract it to a private method, for code structure and readability. Otherwise I would leave it in the parent method with a descriptive comment.
I think that maintainability and readability can be degraded if there are too many, very small methods in the code. I strive for a good balance. But whenever I doubt; I extract it as a private method.
您应该根据 API 和 API 的设计将其重构为私有。 您在其他地方使用时想要公开的方法/属性。 您不应该考虑它的用途来决定是否将其设为私有/公开。
You should refactor to private based on the design of your API & methods/properties you want to expose when using elsewhere. You shouldn't be considering it's usage to decide whether or not to make it private/public.
只是一个愚蠢的估计，但我想说大多数私有方法只在普通类中的几个地方被调用。 然而，如上所述，如果将所有功能分解为逻辑块，它会使您的代码更具可读性并且更易于测试/维护。 重构是一个好习惯
Just a dumb estimate, but I'd say the majority of private methods get called in only a couple of places in the average class. However as mentioned above, it makes your code much more readable and easier to test/maintain if you break all functionality into logical blocks. Refactoring is a good habit