A refactoring I commonly do is where I come across a large method such as

public void doSomething() {
    // do First thing

    //now something else

    // finally do this stuff

and use extract method refactoring it to make it like this:

public void doSomething() {

private void doFirstThing() {

I know the benefits of this are that duplication tends to be spotted more easily, comments are replaced by descriptive methods and methods can be tested at a finer granularity. Also, in a large class it can be easier to isolate and group a selection of methods/fields as a candidate to extract to a new class.

But, I think most importantly it means If I'm looking at doSomething() for the first time, I may only need to read 3 lines of code to know what it does instead of 7. If I don't fully understand doEvenMore(), I can choose to read the method and so on, working down through the class like a hierarchy. Effectively I start reading a short entry point method and only need to read the lower methods in any class when I need to drill down deeper.

So, my question - is there a name for this concept in programming and what is the easiest, most concise way to explain or demonstrate it? I have sometimes found it difficult to explain the benefits to colleagues why it's good to split up large methods, even when these new methods are only called from one place.

EDIT: I'll try to be clearer: I'm not asking about the concept of extracting methods, I'm asking about the principle that makes extracting methods the right choice in this case e.g. If I had duplicated code in the original method I would extract a method because of the DRY principle. In the case above I don't but it's still good to extract the methods because of the X principle. What is X?


It's a common refactoring pattern called "Extract Method".

Martin Fowler and Kent Beck explained the concept this way in their great book Refactoring: Improving the Design of Existing Code :

Extract Method is one of the most common refactorings I do ...

... I prefer short, well-named methods for several reasons. First, it increases the chances that other methods can use a method when the method is finely grained. Secod, it allows the higher-level methods to read more like a series of comments.

Other benefits are: the original method is now shorter and conceivably easier to comprehend, and the body of logic removed and placed into its own method is now easier to test.

The result of this refactoring process is called "strong cohesion". Cohesion referes to how closely the operations in a method are related. In particular, this would be what Steve McConnell refers to as functional cohesion in his book Code Complete.

The goal is to have each routine do one thing well and not do anything else.

Functional cohesion is the strongest and best kind of cohesion, occurring when a routine performs one and only one operation.

  • I know that what I am doing is the extract method refactoring, what I'm really asking is the name for the principle that makes it the right thing to do in my example. E.g. if I had duplicated code, I would also use the extract method refactoring but it would be because of the DRY principle. – Alb Apr 21 '11 at 23:37
  • I've edited my answer to add some more detail... – Eric King Apr 21 '11 at 23:47

I think you are looking for the expression "a class (or method) that reads like a newspaper article", borrowed from Uncle Bob's book Clean Code. We start at the top with important statements and drill down to details if we care to.

  • thanks, this is the type of answer I'm looking for, I'd never heard that expression before, is it commonly used? – Alb Apr 22 '11 at 2:00
  • Commonly used... I don't think so. However I understood it the first time UncleBob used it (it has its roots in English classes from College, etc...). – louisgab Apr 22 '11 at 17:22

This looks like an example of the Single Responsibility Principle. If you have a large, complex method, it is probably doing to much. Breaking it up into smaller, more succinct methods can make the code reusable and maintainable.

  • I don't think SRP is at work here. The amount of work done in the method is not changed, only the level of abstraction: instead of 7 small steps, it is now executing 3 larger, higher level steps. – Péter Török Apr 21 '11 at 23:22

This is a perfect example of the Extract Method refactoring. It also has some similarities with the Template Method pattern, where the code is split into a skeleton method that describes the logic, and low-level methods which implement individual steps (and could be overridden in subclasses).

  • Hmm the template method pattern is similar, but as I stated in my question, I think extracting methods in my case is the right thing to do from a readability POV even if they are private and are not to be overloaded. I'm asking if there's a well known principle that covers why this is. – Alb Apr 21 '11 at 23:42

What you have done is stripped the "entry point" down to what in design speak I would call a hard coded command pattern.

A way to visualize this pattern is to imagine a programmable remote control.

In this case the buttons are all there, but the remote hasn't been programmed to do more than one thing (whatever the entry point does):


This i Ok, considering your intentions. Just so long as you put the proper thought into the access modifiers. This could become an important point if you have multiple EntryPoints. There may be potential to implement the cmd pattern to reduce the amount of code you need to maintain across the project.

I also agree that SRP, extract method and Cohesion are (or should be) the guidelines used to get you to this point.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.