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

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

Of course! The smaller your methods, the easier to maintain your software.

Answer 3

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.

Answer 4

Yes, it is.

• 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.

Answer 5

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.

Answer 6

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

Answer 7

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.