How to program in a modular way?

Asked

Viewed 1,978 times

9

I am studying some concepts here and I want to see if I have the right ideas and also launch a(s) question(s).

In modular programming (either structured or OOP) instead of my application being monolithic it is divided into modules, with well-defined interfaces between each one. In OOP for example, a module would be a certain group of classes.

A modular application has advantages, which at the moment I can’t say exactly what they are (this would be a question, but not the most important one I want to ask). If memory serves, these benefits include being able to divide the task of implementing the modules between different teams or team members and the possibility of having less impact when a code change is made (this impact is restricted to the module).

Very well, but even an individual module can be broken into subparts, which can also be called (or not?) modules. If I’m not mistaken, a class or even a procedure or method can be called a module.

Well, the case is that at this level of granularity (class or method) it is possible to program in a modular way, with well defined routines, cohesive in relation to what they propose to do and whose implementation is maintained in an adequate and consistent level of abstraction (Are these the requirements for having a modular routine? This is another question). In turn, these routines may call equally well-defined subroutines.

How to achieve modularization in all these levels of granularity? At the level of application, of individual modules and at the level of routines? In particular in the latter case, what would be some heuristics to determine what a routine should do and at what level of abstraction to maintain? I get a lot in this part, of subdividing routines, "traffic" by the correct levels of abstraction and delegate functionalities to which subroutine.

In the case of OOP the modularization of the classes is obtained with encapsulation, so I believe that it is enough to know how to encapsulate (to distribute between the classes the data and operations on this data) correctly.

If it’s too much of a question, let me know and I’ll break it. Maybe indicate which specific topic deserves a separate question.

oop paradigms módulo
  • 2

    It is not much question because it is related, but one of them seems to me very broad, I will answer what gives.

1 answer

14


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 was procedural, I’m sorry. On the part of OO I would like to read more about situations where segregation is promoted as opposed to encapsulation, and about the languages that support this behavior. Would have some indication?

  • The segregation and encapsulation are orthogonal, I hope I haven’t given the impression that they’re not. It is that the person exaggerates the encapsulation and thinks that everything that concerns the object must be inside it. Today extension methods, standard implementation in interface, mixins, traits and things like that are more adopted where possible, which in a way is the return of using loose functions like ra in procedural. Okay, more modular, more meaningful, better mechanism. But it was clear that putting everything together was not good, To solve this start to create a lot of classes, the majority senseless.

  • Proponents of OOP attach much to established concepts more than seek appropriate mechanisms for each case. And it was worse, it was getting better, today many people who were more radical with OOP is less today, which shows that they are dancing on a slippery terrain. That’s why I don’t get too hung up on paradigms, design patterns. I go after the best solution and if a language does not provide me I want to provide. Pity that few mainstream are providing better mechanism.

  • "if using OOD for programming is not good" - Are you saying there’s a gap between OOD and implementation? And if that’s right, do you consider this "not good" a fait accompli or would it be more for an opinion?

  • "many people who was more radical with OOP is less today, which shows that they are dancing on a slippery terrain" - that part also I would like you to speak in a more specific way, if possible.

  • 1

    @Piovezan as I have no proof, I will say that is my opinion, but it has several clues. Design everything is beautiful, when creating the code always begins to realize that does not fit, unless you have already done something identical. I see a lot of developers who have been doing the same thing their whole lives, which I think is a mistake. I would say that today most of the software in the world is duplicated without necessity. Who always creates something new always screws up n time to implement. My keyboard is failing, then I reply more. If I forget, let me know.

  • Here is the reminder. : ) On second thought, this gap makes perfect sense, which should be at least the size of the distance between the model and the programming language.

  • This is the same reason that TDD is flawed. and because some Apis are weird. It’s made a design beautiful that at the time of implementing shows bad and ends up getting weird. Interestingly the such design is against Agile. And many people who do the design before programming only Agile advocates. I don’t understand how that is. It seems that one has its own definition of what Agile is. I’m for planning not a design before programming, because at the time you are doing you realize that "that is not quite how it works". Unless you already know the challenges of that...

  • ... what only happens when you’ve done it. What if you’ve done it already because you’ll do it again? I notice a lot of duplication of efforts. There are many people who are productive for the simple fact that they are always doing the same things. So actually this is unproductivity, every repetition is unproductive.

  • In the beginning of OOP many people defended the basic ideas of the paradigm as if it could only do that way, gradually the more pragmatic began to abandon certain ideas a little, or at least only to use when it was necessary. Some people keep doing it because you tell them to. Note that I’m talking about who knows the subject, I’m not talking about who even understands what OO is. Inheritance is one of those cases that saw that brought problems and in some cases useful indeed. Encapsulating everything can be good for the design, but not for performance, these things need to be looked at.

  • If you take the texts of each epoch you see that there is variation in the way people think, the gain of each element of OOP is not something so concrete and will need adjustments. Today there are many people who have arrived in the right understanding of what is useful and when. Of course, there are always those who stay in what they learned and do not change the thought. If it is good for them, it is fine.

  • Thanks for the clarifications. Without wanting to delay but a question now about modular, in this question of Soen is said: "Your modules can be implemented as classes (...) However, modules are Meant to be logically Separate Pieces of the Programs and as such it doesn’t make sense to have them as classes, as you can have Many Different Objects of a class. If I was to write a modular system and use classes for modules, I’d make them all singletons". When you program in a modular way in OOP you must follow this path, right? It makes sense?

  • 1

    So modular programming is one thing and few people understand that, to create a module that looks like a package, a namespace or this module you have in Java 9 is another completely different. This modular is to create compartments in a broad sense, is to have watertight parts, is to have clear separations of what is each thing.

Show 8 more comments

Browser other questions tagged oop paradigms módulo

You are not signed in. Login or sign up in order to post.