I am going to talk here about something that is not well formalized and that there are different currents of thought. More recently we have started to define the subject differently than originally defined, so keep this in mind when reading. The answer even serves to evolve the theme
Structured and procedural programming
Structured programming has to do with code flow, it’s something about the algorithm itself. Maybe you’re talking about procedural programming, The confusion is common, it must even have been induced to error by another way I see many wrong around.
Maybe you’re just talking about a granular aspect of modularity. This is not even opposed to object orientation that is concerned with the organization of the code of the data structures and their behaviors.
Modular programming improves procedural programming and is a basis for object orientation, and cares from the code of the algorithm, through the code of the data structure, to the structuring of the solution as a whole.
Procedural programming can be structured or not, it can be monolithic or modular. In the past it was common to do something monolithic. In clear Portuguese before a code was made "linguição".
Procedural programming is already a bit modular, but it is not so emphatic in the separation of responsibilities. The modular takes it to another level, to other code units.
Modular programming
This paradigm mainly establishes the separation of responsibilities in modules.
It is not well defined what a module is. It is a code unit, then it preaches to separate the code into functions.
Of course these functions are grouped so that they interact with each other or operate on top of the same object. Call it module, class, structure, whatever you want.
In some cases you may need an extra level of modularization, it may be that you create a package with a compilation unit in which each language handles the way you think best.
So I see the module as something that segregates code, not just a group of classes, as the question already understands.
Some people may consider that a namespace is a module. A module predicts some encapsulation that the namespace does not provide.
Precisely by providing encapsulation I say that if object orientation places this as a single point of its definition then people should be saying that they program modularly. I see that other aspects together with this form object orientation.
Modular programming usually has code visibility definition. Until C has it, although it could be better. C is not the best example for the paradigm.
It seems obvious to me that codes that are small and only do one thing are more readable and easy to maintain. Adding that it needs to be encapsulated and not expose details that its consumers don’t need to know. Decreasing the impact area on a change is a goal of modular programming and the question is right in this.
Therefore the term interface is used. In the same contract sense, as it is in OO, but the mechanism does not need to be the same. Take C and its header files that have interfaces, although we don’t usually call them that. Yes, it’s a little different, but it’s a contract with signatures.
The question talks about cohesion and that’s very important. I have a book that talks about it and it was written before anyone pronounces object orientation.
Proper abstractions are important in modular programming, and of course they should be consistent. It’s not that this defines PM, it’s just a matter of importance.
How to modularize
Modularization has no clear rule, it’s that kind of thing that you can define abstractly or show a concrete case. It’s very difficult to teach, to give specific rules on how to do this. The more specific questions I could not easily answer, and I even think that for that I would need a chapter of a book, which makes the question broad.
But it equals object orientation, the difference is that modular programming does not define couplings by inheritance and it itself does not predict polymorphism, which does not prevent the mechanism from being used along with it and often is in more modern languages, like Rust and Go, just to be on the hottest rides lately.
So as in OO, modular programming has no clear rules of the "size" of the module, is to analyze the problem, understand it, model, refine, learn from your mistakes and from others and get better.
Most of the time I do imperative programming with modular. Eventually transpasso to OO. Although there are times it is easier to say that it is OO since the modular paradigm did not get traction. Everything is a matter of marketing. And what matters is engineering. In the end the right name matters little.
Advantages of modularization
The advantages of its adoption are mainly those sold in OO, there is no difference, why I say that many people program modularly but not to be out of fashion says OO program, even because she does not know what is PM.
There’s the OO school that’s tied to abstractions, code modeling, design patterns and not proper OO mechanisms, and everything this school talks about in the background is talking about PM unknowingly, one of the reasons I don’t like this school and I don’t trust it, at this point, in who defends this.
PM is different from OO
PM does not encourage state association with behavior, but also does not prevent. The more modern languages are avoiding this somewhat by giving better segregation mechanisms and not so much joining. In OO has rules that are even conflicting. Time say to gather everything, time say to separate.
The practice showed that putting too much together can make the idea easier to understand, but it makes maintenance more difficult, which is why in databases we often think of logical models and physical models. Object-oriented design is one thing and few people do, object-oriented programming is quite another and using OOD to program doesn’t look good.
I always say that people adopt things that they read, not what they know. If she knew all the fundamentals, she’d know what she’s doing. But it’s also no use trying to impose the right nomenclature on every conversation about the subject.
Most of what you learn in OO is actually learning PM (or MOP in English) and I find it tragic that usually the person you’re teaching doesn’t know that.
Also part of what is said about modular oriented Programming is just procedural programming.
There are paradigms that are antagonistic, others are complementary, some have hierarchical relationship, so there may be some confusion.
Is always confusing
Helps in the confusion that OO is hype and PM be on the corner. So have less structured definitions, less debates, less disclosure.
I did some research to answer and I saw that there is some nonsense on the subject, not only because the consolidated basis on the subject does not talk about some things that are talking around, but also because some, or do not make sense, or "steal" from other paradigms, or are clearly wrong.
That includes the wikipedia article, which has its merit in some parts. Read the first section. The key aspects section has something useful, but not everything, and the first paragraph of the history section is very good, forget the rest except out of curiosity.
To Portland Wiki is always a place that generates good debates. People do not agree, but evolve understanding there. I disagree with several things in it, but it is useful if you know how to interpret texts.
This idea that a module is just a compilation unit does not please me and counters parts of the article, one of the wiki text problems.
Completion
The question has understanding well above average, by AP almost did not need. I hope people understand that modularization is good in any project that is not a script simple, even more in solutions Nterprise. Object orientation is good in some cases, as a complement to modularization.
As OO is still modular the term is more pompous, you can continue saying that does OO when it only does PM. But avoid saying that OO when evil does procedural right, when it misses the imperative.
It is not much question because it is related, but one of them seems to me very broad, I will answer what gives.
– Maniero