Should you refactor code into private methods if they aren't called more than once? [closed]

Question

Is it worth extracting private methods for code that only gets called once in a class, or leaving the code in the parent method (maybe) with a comment that says what it does?

Answer 1

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.

Answer 2

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.