Is client code eventually written in a procedural style?

Question

Programming

I actively study and rethink OOP, patterns, principles and other fundamentals of software architecture. And I caught myself thinking that in the end, at the main / end point of the program, we still work in a procedural style. Perhaps I made a mistake in terminology somewhere, so I will explain what I mean next.
Let's take any design pattern as an example. In most cases, it will rely heavily on the final client implementation, if you take the strategy - the choice and implementation of the strategy occurs in the input client code, i.e. all OOP happens directly "after/before" the client code where the procedural occurs.
- I'll try to give another example, let's take the general architecture of MVC, in most cases the client here will be the controller (I note that the controller in this case is the logical basis, not the system one) - it is he who determines the basic behavior and operation algorithm of this or that "module" ", and again, the same procedural code is written in the controllers.
- Also, if we take even basic concepts, such as polymorphism, as an example, here again, the procedural from the client comes in, which determines specific implementations.
Definitely, in all the above examples, I use the concept of "procedural / ka" too loudly, I mean a more localized and simplified concept - something like a sequential / procedural algorithm.
Am I understanding the situation correctly or not?

Answer 1

Horses mixed up in a bunch, people ...
OOP is needed to manage complexity.
In simple projects, it only introduces an extra headache in terms of design, but in complex ones, it allows you to divide the huge terrible business logic into some separate blocks / modules / classes that you can work with without trying to shove the entire project into your head.
So I use the Billng.getUserBalance() method and don’t think about what’s inside this getUserBalance()
, maybe reading from a file, or querying the database, or maybe sending a signal to the moon with a laser - I don’t care, I just need a number.
Patterns (design patterns) are needed in order to explain to OTHER PROGRAMMERS what the hell we wrote here.
You can write code that doesn't look like anything at all and doesn't conform to any patterns. And those people who want to understand the code will have to read it in its entirety and comprehend it. Or we write: here we have the "observer" template, but here we have a singleton and everyone immediately understands the general meaning.
With MVC, the example is not particularly successful. The fact is that now there are quite a lot of different things that for some reason have stuck MVC letters, although in fact ... In general, it is clear that you are writing about the case with "thick controllers", but there may be several different controllers that work with one model.
And there can be different models giving data to the same view. But more on that below.
And you messed up something with polymorphism. Take a look at Wikipedia what it is and why. There can be more than one client. Today our code works on an ios phone, tomorrow on andoid, and the day after tomorrow on a psi-controlled holographic TV. And yesterday he took the data from MSSQL and today he takes it from mongodb. But at the same time, everything is coolly designed with us, and we do not change the core of the application . We only slip new implementations of interfaces as necessary. That's what polymorphism is about.

Answer 2

Or I'm not catching up with something, or you need to study programming terminology better, the phrase:
"- I'll try to give another example, take the general MVC architecture, in most cases the client here will be the controller" The
client is the front end, the server is the back end, the Controller this is a class connected to the core of our program with a set of basic methods and properties, and then we already inherit from this class to create an extension of our program, supplementing with new methods and properties, interacting with the inherited model class, forming an array of data, we give an answer to our template.
Accordingly, the Model Class contains the main logic of queries to the database, then we also extend our functionality by inheriting from it.
Thus, our actions are sorted, have a tree-like nature of interaction, and therefore reading the code and expanding is much more efficient than monolithic procedural chaos, where after several years of expansion, even the most ardent coder will break his brain. I wrote a lot of obvious things about MVC, but this is so by the way for the overall picture, and it will be useful to someone.