A refactoring I commonly do is where I come across a large method such aspublic 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?
Is there a name for the concept of a hierarchy of many short methods in a class
code quality;refactoring;extreme programming