_{I will talk here about something that is not well formalized and that there are different currents of thought. More recently it has begun to define the subject differently than it was 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 , confusion is common, must even have been misled by another fontem I see many wrong out there.

Maybe I'm just talking about a granular aspect of modularity. This does not even contradict the object orientation that cares about the code Organization of data structures and their behaviors.

Modular programming improves procedural programming and is a basis for object orientation, and cares from the algorithm code, going 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's not as emphatic in separating responsibilities. Modular takes this to another level, to other units of code.

Programming modular

This paradigmmainly institutes separation of responsibilities into modules.

Is not well defined what a module is. It is a unit of code, so it preaches separating 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 may need an extra level of modularization, it may be that you create a package with a compilation unit in which each language treats the way you see fit.

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 provides for some encapsulation that the namespace does not provide.

Precisely by providing encapsulation I say that if the orientation to object puts this as a single point of its definition so people should be saying that they Program modularly. I see that other aspects together with this is that form the object orientation.

Modular programming usually has Code visibility definition. even C has this , 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 that only do one thing are more readable and easier to give maintenance. Adding that it needs to be encapsulated and not expose details that your consumers don't need to know. Decreasing the area of impact on a change is a goal of modular programming and the question is right in that.

So the term interface is used. In the same contract sense, as even it is in OO, but the mechanism does not need to be the same. Take C and its header files that have interfaces, even though we don't usually call it that. Yes, it's a little different, but it is a contract with the signatures.

The question speaks in cohesion and this is very important. I have a book that talks about it and it was written before someone uttered object orientation.

Proper abstractions are important in modular programming, and of course they must be consistent. It's not that this defines the PM, it's just a matter of importance.

How to modularize

Modularize has no clear rule, it's the kind of thing you can define abstractly or show a concrete case. It is very difficult to teach, give specific rules of how to do this. The more specific questions I would not know how to answer easily, and I even think that for this I would need a chapter of a book, which makes the question broad.

But it is equal to object orientation, the difference is that modular programming does not define couplings by inheritance and it itself does not provide for polymorphism, which nothing prevents the it is often used in more modern languages, such as Rust and Go, just to stay in the hottest lately.

So just like in OO, modular programming has no clear rules of the "size" of the module, it is to analyze the problem, understand it, model, refine, learn from the S their mistakes and others and go improving.

Most of the time I do imperative programming with modular. Eventually transpasso to OO. Although it has Moment That is more easy to say it's OO since the modular paradigm hasn't picked up traction. It's all about marketing. And what matters is engineering. In the end the correct name matters little.

Advantages of modularization

The advantages of its adoption are mainly those sold in OO, it has no difference, so I say that many people Program modularly but not to be out of fashion says that program OO, even because she does not even know what is PM.

There is the school of OO which is attached to abstractions, code modeling, in design patterns and not in Oo's own mechanisms and everything that this school talks about in the background is talking about PM without knowing, one of the reasons why I do not like this school and I do not trust, at this point, who defends it.

PM is different from Oo

PM does not encourage state association with behavior, but it also does not prevent. More modern languages are avoiding this a bit by giving better mechanisms of segregation and not so much of joining. In OO has rules that are even conflicting. Time they say to put everything together, time they say to separate.

Practice has shown that putting too much together can make the idea easier to understand, but it makes maintenance more difficult, so in database we often think of logical model and physical model. Object-oriented design is one thing and few people do, object-oriented programming is quite another and if you use OOD to program it does not look good.

I always say that the people adopt things they read, not what they know. If she knew all the fundamentals she would know what she is doing. But there is also no point in trying to impose the right nomenclature in every conversation on 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 who is teaching doesn't know it.

Also a part of what is said about modular oriented programming it's just procedural programming.

There are paradigms that are antagonistic, others are complementary, some have hierarchical relationship, so there can be some confusion.

Is always confusing

Helps in the confusion the fact that OO is hype and PM is in the corner. So it has less structured definitions, less debate, less disclosure.

I did a survey to answer and saw that it has some nonsense on the subject, not only because the consolidated base on the topic does not talk about some things that are talking out there, but also because some, either do not make sense, or "steal" from other paradigms, or are clearly wrong.

This 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 story section is very good, forget about the rest unless out of curiosity.

To Portland Wiki E always a place that generates good debates. People don't agree, but understanding evolves 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 build unit doesn't appeal to me and contrasts parts of the article, one of the wiki text problems.

Conclusion

The question has understanding well above average, by the AP almost did not need. I hope people understand that modularization is good in any project that is not a simple script, even more so in solutions enterprise. Object orientation is good in some cases, as a complement to modularization.

Since OO is still modular the term is more pompous, it can continue to say that it does Oo when it only does PM. But avoid saying that it does OO when it badly does procedural right, when it errs in the imperative.