Is there a name for the concept of a hierarchy of many short methods in a class

Question

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

public void doSomething() {
    // do First thing
    doPartA1();
    doPartA2();

    //now something else
    doSomethingElse();
    doMoreSomethingElse();
    doEvenMore();

    // finally do this stuff
    someStuff();
    someMoreStuff();
}

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

public void doSomething() {
    doFirstThing();
    doSomethingElse();
    doStuff();
}

private void doFirstThing() {
    doPartA1();
    doPartA2();
}
...

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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):

EntryPointButtonPush()
{
   Button1()
   Button3()
   Button2()
}

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.