Modular Programming Versus Object Oriented Programming
(The Good, The Bad and the Ugly)

An Article Written by Stéphane Richard (Mystikshadows)


I'm sure some of your, by now, might be saying "what is that all about?". Allow me to begin this with a brief history of why I decided to write on this subject. You see, for decades already, when I hear talks about programming concepts and paradigms, It seems that Modular Programming techniques and object Oriented Programming have been under somekind of comparison by developers all around the world. A hidden feud between the two serving the soul purpose of boasting the advantages of one over the other. Also, It seems that with time, O.O.P. took on a very different role, one that radically changes the way newcomers to the world of development see and understand the concept. However, if you go on C forums, QB forums, and other languages too, and talk about O.O.P. you might be surprised at the answers you get from those communities.

Basically, these two items are what motivated me to write about the subject in question. NOte that the contents of this document represent my own point of view, my personal understanding of the concepts and my thoughts on what should be what. But i have seen the evolution of Modular Programming and Object Oriented Programming from their very beginning, I've also seen all the deviation that these programming methods took in the course of their evolution. I will be explaining these methods and share my views and insight on where each method can provide the best advantages on a project. This will give you the information you need to understand the rest of the document where I will be sharing what has been said about these methods and show you where the deviations that was bestowed upon the O.O.P. paradigm changed everything that O.O.P. is known as today.


Modular (or Procedural) programming is a coding method that entails the use of routines, sub routines and functions in order to organize and execute specific sets of instructions pertaining to a given task to be done. The main rule of thumb in this technique is that if a set of instructions, that perform a specific task or calculation, will be called several times, it should be moved to a subroutine (if it does not return a value) or a function (if it does return a value) and called from the needed other parts of the program.

Typically, to create a successful modular structured approach to solve a problem, you need to define the problem in terms of what actions or calculations the program needs to do in order to perform the task defined in the problem. You also need to see if there is any special connection between procedures and functions to establish an execution order for them. The other concept here is that if a subroutine or a function is quite big, it is probably due for a refactoring into two or more sub routines. This is essentially how modular programming manages the complexity of a program by breaking it down into smaller, simpler, more managable sections of code.

Over the years, structured programming has been given more than one coding style and as such gives a good foundation to adapt the programming method to fit one's minding. By that I mean that depending on a developer's background he or she might like to organize their modules, procedures and functions based on functional grouping (all string manipulation functions go in one module, all datatypes go in another module, all constants in yet another module, this is often the type of organization I like to follow as well. Others might prefer to organize their modular approach based on an entity structure (somewhat closer to O.O.P.). For example, all datatypes, procedures and functions that affect an employee's information goes in one module, all inventory datatypes and functionality goes in another module. This is one of the great advantages to the modular programming approach in that it allows to organize the code in a way that fits the developer's way of thinking. When you think about it, it can be a very strong point since everyone thinks in very different ways but everyone needs to be able to define their problem and bring solutions based on how they would solve them manually.


Object Oriented Programming is a coding method that entails the use of objects and their relationships in order to describe, programmatically, the problem to be solved. The classic definition of O.O.P. was based on three founding pillars which were Encapsulation, Inheritance and Polymorphism. Here is a brief explanation of these founding blocks.

In the classic definition of O.O.P. These founding blocks were created because of the birth of a need for code reusability without simply cut and pasting existing code into a new module. Hence you could create an object or a hierarchy of objects that pertained to a specific role. then give the compiled version of that object as a library to another person who could then create his own objects as being part of the originally defined hierarchy. Today, two new pillars have been added to the definition of O.O.P. They are Interface and Abstraction. Here are their definitions.

Essentially, O.O.P. is an evolving standard that adapts to new needed concepts as they are needed. This can be fun in some cases, but a real curse in most other cases. These last two pillars also created the concept of black box and white box programming techniques. The classic object was White box (which means that levels of the hierarchy needed to know what came at the parent level in order to be able to perform its task. In White Box development, a hierarchy defined levels of specializations of objects in a hierarchy where objects in a lower level had more refined programming compared to it's parent. In Black Box development, Each level of the hierarchy tends to define containment rather than refinement. For example: The white box would state that a dog is a specialized (or refined) type of Canidae. In Black box, a Canidae has a dog (and a wolf, and a fox as it's sub components. This can lead to some serious conflicts in my opinion, which i will share later in this document. For now, let's compare Modular Programming and Object Oriented Programming versus a typical problem scenario to get a glimpse of the real differences of both methods.


The Scenario:

The scenario I'll be using is the following. The boss comes to see you and asks you: "I would like a program that can save information on the employees to a file, I would like to be able to enter the Employee's ID, his name, address, city, state, zip code, telephone number, email and hourly rate and it should also be able to to retrieve that information based on one or more criteria that I would enter in different fields. I would like to print that information so I can put the employee information in a physical file. The employee should be able to to enter the time they arrive at, the time the leave and come back from lunch and the time they leave at the end of the day in a timesheet program. The program should be able to calculate how many hours they have worked that week, the gross pay they have gotten and the amount of overtime they worked (as well as what monetary value the overtime amounts to. Employees are paid 1 1/2 times their hourly rate for any hours over the regular 40 hours a week and they are paid twice their rate on any holiday. Everything should be saved and retrievable on a per employee basis. I also want weekly, monthly and yearly detailed and summary reports on all this information for all or one of the employees at a time."

The Modular Programming Approach:

In the modular programming approach, the verbs in the problem description are the ones considered first. Typically, these verbs represent the work to be done and therefore the likely subroutines that we would have to implement in order to solve the problem. The names in the description represent the information (variables and datatypes) that will will be acting on or producing at the end. Modular programming is based on three things, which are: 1. The information needed before the process can start, 2. The work to be done with that information and 3. The expected output of a procedure. We will here answer these questions as per our scenario above:

As you can see, the modular approach is closely related to the functionality needed in the problem description. You think in terms of what needs to be done and usually can pretty quickly devise a workable complete solution to a problem by consecutively answering these three questions (some of these answer may require that you breakdown the system into smaller answers to a subset of these three question depending on how complex the system gets. This breaking down into smaller more specific procedures and functions is how Modular Programming offers to manage the complexity of a program.

The Object Oriented Approach:

In Object Oriented Programming, the names, not the verbs, are the first to be considered because in O.O.P. the first task is to define entities, not actions. O.O.P. starts by defining the players (or actors if you will) of a given scene (the problem) and them proceeds to defining how the actors are described (the properties) and what the actors can do (the methods). Once all these are defined for all playing actors, then the scene (the main part of the program controls what each players has and what it does. Only when you are defining the methods of the object can you actually start answering the same three questions that the modular approach lets you define right from the start. Again, as we did in the modular approach, I will define the same problem description using the Object Oriented Programming Approach instead of the Modular Approach I used previously:

The Entities:

By reading the problem description. We can clearly indentify three entities. The Employees, the Timesheet and the reporting system. This is how O.O.P. problem solving begins. You need to identify these entities first and the define how you describe the object as well as define what the object can do. So let's take each entity and define them so you can see how things work:

As you can see, the Object Oriented Approach to problem solving is quite different from the Modular Approach. With all this information you now have on the two methods, you might be wondering if there are certain projects, or certain parts of a big project that could benefit from the Modular Approach and likewise for the Object Oriented Approach. Is there situations where you would be better off using one method over another. In this next section, I will discuss this subject, based on my own personal experiences with both methods.


If we take into consideration both methods used in the example above. We can see that both of them managed to define the problem, and possible organization adequately. In their own domain, we can say that they were both as successful as the other in doing what they are supposed to do. So where and when can and should you use one method over another? My experience has shown me that the best way to answer that question is to go by development domains they each have their own best way of describing their needs. Let's take a few examples industries to see how to select the best method.

This covers the industry and which method you're more likely to want to employ when developing (and presenting) a solution to the people that work in these respective industries. There is another factor that can be a very big player in your decision to use one method over another. That factor is one of the size of a project and hence it's complexity. There are many cases where even a program, for an entirely O.O.P. oriented industry like Multimedia and Entertainment, just doesn't need O.O.P. or would fail to take advantage of the O.O.P. approach to bring a solution to that particular problem. Likewise, O.O.P. could very well be the only viable solution to a problem brought forth by industries that have never needed O.O.P. before. It really all depends on the way they can explain these problems based on what they know of their industry. One last factor could be that the company you are developing for already have tools and do not wish to purchase tools to accomodate for the missing method. In other words, companies could very well impose their development methods and expect you to be able to arrive at a solution using their method whether it's suited for the task or not. In those case you just need to make the best of what you have.

These represent how I would deal with problems in these specific industries. I'll take the time to see how a concept can best be described to the users of the program I am making and if the description is based on objects, unless there is a restriction that stops me from doing so, I will use an O.O.P. approach especially when you are creating an entirely new project. When you think about it, there isn't just the program that you are making to consider but also how easy your solution will be for the users to understand and use. This means that you have to take the time, in making your decision, to see what kind of user you are dealing with to see how they might react to one or the other of the explanation methods and based on the findings of that little research, use the method that can be thought the fastest and easiest.


When you talk about O.O.P. today, you'll hear some very different explanations by different software professionals. Since O.O.P. is found on the 5 pillars I mentionned about, how can these answers be so diverse and, in some cases, so out of touch with each other? The first answer I have to bring here is that depending on when developers started learning O.O.P. they were given some very different notions on what exactly O.O.P. is and how to efficiently use it for problem solving.

One of these new notions arrived when Java hit the mainstream programming industry. Which suddently told you that everything imaginable in programming is now an object including strings, integer and other datatypes. hence the base of all programming should be the object. The problem with this notion is that it's true only for languages that are designed around the same concept as Java where everything you can create is an object. This does not today constitute the majority of the popular languages you can use today. When you think about it, a datatype has no reason to be an object simply because of the way a compiler organizes memory. An object has an overhead that would represent a major waist of memory compared to storing the classic 4 bytes for integers. All these little things is what makes Java so slow and a perfect example of sloppy bloated code waiting for a faster processor to surface so it can make it look faster.

Another one of the confusions in O.O.P. definitions arrived when Objects Modelling techniques like U.M.L. (Unified Modeling Language) made surface. U.M.L. in itself is not a bad approach at all in problem solving. However, today, alot of what defines U.M.L. is confused, or atleast stated when talking about O.O.P. Often when I talk to people, they will mention such notions as agreggations and composition. The problem with this is that any language that can do O.O.P. doesn't have an aggregation or composition construct per se. But these people say that they do alot of aggregations and compositions when they develop. I then have to explain to them that these are object modeling principles and have no direct equivalent in the language itself. Aggregation denotes a whole/part relationship between objects. For example a Circle is the whole object and a point, is part of a circle objects this is created as an aggregation of two objects. A Composition can be used to create a relationship between objects too but it has the added ability to have a source and a destination (Circle knows about Point, but Point doesn't know anything about circle). These are Object Modelling principles and cannot be directly coded in a language. but when translating the principle to the selected programming language, it could mean that the module that defines Circle will have an #include "point.h". But it does not mean that because this include statement is in the Circle Module that you have created an aggregation necessarily.


If you have been to forums and message boards that compare and debate modular programming and object oriented programming, you might have noticed that many claim O.O.P. is the only intelligent methods and start enumerating reasons that have absolutely no direct relationship to O.O.P. I've seen these too many times and it's a shame to see most of them are enumerated in an effort to bring down modular program and try to boast O.O.P. as a better approach. I will be listing here some of the more popular myths about O.O.P. that I have seen and tell you what I have experienced in regards to the myths themselves.

I do have to say however that there are some myths that I found to be true however, again based on my own experience. And when you think about the reasons I give here, you'll find it hard to see it differently. This told me that O.O.P. can have it's specific place. Here are the two most widespread myths that have proven themselves to me as being true.


The bottom line is quite simple. It would not be wise to decide that everything can be made from one of these methods and stick to it alone for all your programming endeavors. In some cases, O.O.P. will naturally be able to represent a problem much more efficiently where in other cases, a modular approach could save you loads of time by being able to represent the problem much quicker, easier and cleaner than any O.O.P. model ever could. it's important to remember that Modular Programming and Object Oriented Programming are two problem solving methods and that both are designed to bring answers to questions and solutions to problems. They are two different means of implementing a solution and that is really all that needs to be remembered.

It's important that you remember that this article really reflect my own experiences with both problem solving methods and my own personal opinions about them. Others probably have a different point of view and may have all the right reasons to believe them. All I can say is so far, in my 30 years of personal and professional development, my judgement on these has not failed me once. It takes good common sense and a bit of logic to make the right decisions and opinions about them. I will finish by saying that it's not wise to destroy a problem solving method over another, they truely do have their advantages and could make your life easier if you didn't reject either of them. It is even worse to believe what others say without knowledge. This means that if you want to form your opinions, don't read comments from anyone and believe them blindly. Give Modular Programming and Object Oriented Programming atleast a fair chance, find a project for each and see where each method takes you. It won't be bad for your career to know when each methods has advantages so it should be time well spent on your part. Learn them, evaluate them, compare them THEN when you have the knowledge you need, you can make a good choice.

As you now know, with all my writings, I am always opened to discussion and comments, suggestions and even debates. You can email me whenever you want to clear things that weren't clear to you when you read this. This article is the result of my own experience with the different programming methods. Your past experiences might give you a similar or different point of view on this subject. I'd like to hear of them because I know that everyone has his or her own thoughts on this subject, I see it every day on forums I visit. Until the next time I write, happy reading and programming no matter which method you like to use.

Stéphane Richard