Designing functions with separation of concern in mind

Question

Is there a name related to the pattern shown in the code that follows? Or is there writing/thinking on the [design of] code shown that suggests it is an anti-pattern? In general, I'm curious if this is somehow a well known design strategy for non object oriented applications (and, more importantly, why or why not).

I suppose I'll use Python but this is just an application design question.

main.py

from some_other_file import func_get_data_from_an_api, func_calculate_something, #...
from ...

data1 = None
data2 = None
data3 = None
data4 = None
data5 = None
# ...

data1, data2 = func_get_data_from_an_api()
data3 = func_calculate_something(data1)
func_write_to_database(data3)
data4 = func_calculate_again(data3)
data5 = func_d(data2, data4)
func_write_to_database(data5)
# ...

Then, every other file would just have the implementations of the functions from main.py. So here is the general case for one such implementation:

def general_case_func(param1_from_main, param2_from_main):
  # Under this "pattern", a function in this application can never
  # call another function from this application (but functions in this application
  # can call things like functions from 3rd party software, functions from the 
  # library of the language being used, functions from external systems and so on).
  # Note: This ☝️ is a central requirement for the "pattern" I'm asking about.
  m = 3
  if param1_from_main < 1500:
    m = param1_from_main % param2_from_main
  return max(m, 5)

Never mind the logic in this function (there isn't any intentional meaning in the calculation). The point is that the rules are that functions can only take inputs passed from main and do some combination of the following:

1. Calculate on those inputs
2. Communicate with services/libraries that came from outside of the application
3. Return a value or values to main

So if the application happened to have 500 functions (each with about 4 or so lines of code in them, perhaps importantly for the sake of "clean" functions that only do one thing), then there would be exactly 500 function calls in main.py.

Unless of course considering such things is an essential part of the answer, never mind loops and if statements in main.py. By that I mean, never mind if main.py has if statements that possibly cause some of the functions to not run during some executions, or whether some of the functions in main.py are in a loop.

Answer 1

There is no industry-recognized software design pattern for this. More generally what you describe is functional decomposition, which is just fancy-talk for breaking a large problem into smaller pieces.

Each piece, or function, is responsible for one thing. These functions are written such that they have few outside dependencies, which promotes code reuse. They are easier to combine in different ways to achieve different use cases.

Having main call the other functions is typical for procedural programming, especially for smaller programs. Again, there is no officially recognized pattern for this, but main is where the program starts, so it must handle all use cases. If main doesn't delegate logic for each use case to other functions, then main must coordinate all use cases. This translates into a bunch of function calls, loops and decision structures where only certain branches of the code get executed depending on the use case.

Since main is where it all begins, it is common to see it import a large number of disparate modules. While there is no software design pattern for this, we do have a name for it: the composition root.

This composition root is responsible for configuring and coordinating use cases, but delegating specifics to other, more specialized functions.

Functional decomposition and the composition root pair well together. A consequence of decomposing functions is that something must combine these little bits into a cohesive program. The composition root is that thing that combines and configures dependencies to provide the cohesion necessary to execute a use case.