Making some methods mostly contain method calls, while others doing “the lowest level” work [duplicate]

Question

This question already has answers here:

Is it OK to split long functions and methods into smaller ones even though they won't be called by anything else? [duplicate] (13 answers)

Closed 6 years ago.

So I thought about this, and I don't know if it's included or not in any methodology.

I think the advantages of this coding style is that, at the lowest level, the code is extremely testable, and then the integration tests should also be very easy to build.

I also think this would make the code more readable and the UML would be understood faster.

So here's my example:

class CoolObject{
var member1; //needed for instance in lifecycle events
var member2; //same comment

   //This method could be for instance an event handler
   //Notice this contains only assignments and method calls. No library calls or lower level stuff
   [public] method high_level(params...){ 
    var local_var1;
    var local_var2;
    local_var1 = call method lower_level1(param1,param2);
    local_var2 = call method lower_level2(param1, local_var1);
    member1 = call method lower_level3(local_var2);
   }

   //Notice this contains only library calls and lower level processing
   [private] method lower_level1(param1, param2){
    return param1 + param2 + libraryXXY123.function142(current_date);
   }

   //Notice this contains only library calls and lower level processing
   [private] method lower_level2(param1, param2){
     var return_value;
     loop over param2{
        if(condition){
           add param1 to return_value;
        }
     }
     return return_value + libraryASDF123.function3132(system_user);

   }

}

Please note that this is not written in any specific language, as I only wanted to illustrate the concept.

So do you know some methodologies that use this, or that warn against it? Please elaborate on the answer, as I think this would be a good idea, and would like this either confirmed, or the opposite.

Answer 1

In layman's words:

• That's good structured programming practice.
• OOP builds on structured programming, meaning code inside a class is usually structured programming code.
• Your sample is not a good or bad OOP idea per se, but rather a good structured programming idea.
• Good OOP code usually builds on good structured programming code.
• Your code seems OK to me.

Answer 2

It is called "layered design".

The idea is that your system design is separated into "layers". Each layer provides an interface for the layer above it. Each layer calls only methods from the layer immediately below it.

The canonical reference to this approach is Dijkstra's paper "The Structure of the T.H.E. Multiprogramming System". It is required reading in this racket.

Answer 3

More than the actual coding, the important thing is to come up with a good programming structure. This is something your program has done, because things are well sorted out, and it follows logically from one step to another. It could lay a good foundation for similar programs, and if it needs to be changed, its good structure makes it easier to change than would otherwise be the case.