Suppose I have low level classes A, B, and C that are independent of each other. The functions in them take some input and does some computation and returns some output.Now suppose I want to create an executable where it read in some data and output some statistics with the flow of input->A.func1->B.func1->C.func1->outputThere are two options for me to handle this, Create a high level class called ABC. It does no computation, it simply receives the input from the main function, parses the input and pass it into A.func1, and forward the output of A.func1 into B.func1, and forward the output of B.func1 into C.func1, and output it to the main function.In the main function, directly parse the input itself, pass it into A.func1 and then B.func1 and then C.func1 and then save the output.If class ABC does some computation internally while calling functions from A, B, and C, it's a no brainer that ABC class should exist. However, I am having a hard time to justify the need of a ABC class since it's just calling functions from low level class without any additional computation. It also means if we want to create 10 executables that are using the functions from the low level classes with different combination and order, we will have 10 of these high level classes. However, I heard people said having a high level ABC class is better because  Why should main() be short?Which approach is better?
Single function from a high level class VS Multi functions from low level classes
design;code quality;class design
Neither 1. nor 2. is always better. Here is how I would typically make the decision:start without an additional class ABC and call functions from A, B and C directly from main. If the orchestration logic is very simple, no need to change it.as soon as the logic in main becomes more complex, needs unit tests or has to be reused somewhere else, refactor. For example parsing looks like a task on its own, it could be placed in a separate class.as a result of the refactoring, you may end up with a separate class ABC (hopefully with a more descriptive name). Maybe you end up only with a class orchestrating A and B, a parsing class, some output processing class, and let the calls to C separated. This depends on the details of your situtation.However, I would typically not make this decision up-front, I think it is much better to decide during the refactoring process. The driving forces here should beforming better abstractionstestabilityreusability.For very simple programs, it is perfectly possible you have all the abstractions you need in main, don't need to write tests which require a separate class ABC, and you don't need to reuse anything. If that is the case, stay with option 2.