What is the big difference between modular and object oriented programming?

Question

An object-oriented program usually contains different types of objects, each corresponding to a particular kind of complex data to manage, or perhaps to a real-world object or concept such as a bank account, a hockey player, or a bulldozer.

Modular programming (also called "top-down design" and "stepwise refinement") is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.

Differences that I can think of are that you can have more than one objects on a class, where as in modular programming you are supposed to have only 1 module (1 object) for one specific thing.

Here is an example (the way I understand it)

Consider you have a program. A few input fields and a button. Then some calculations are made and the program outputs something.

This program can have 2 modules: The input/output one and the calculation one.

However I don't see why the program can't have a layout (a class containing all the objects that will be shown on the screen) and a logic part (which can be a class or a function depending on the depth of the calculations).

Is this example "correct" in temrs of both modular and object programming ? Can modular and oop be used together ? And what is the big difference between these two paradigms/programming styles?

Answer 1

Your modules can be implemented as classes, that is indeed correct. 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.

In your example, object-oriented programming you would have classes defining the input fields and buttons, or maybe a class that is used as a calculator. You could even go to greater depths and define a Calculator interface that could be implemented as SumCalculator, ProductCalculator etc, and maybe even throw in some factories so the user can choose between different calculations performed by your program. Yes, you could have singleton classes such as LayoutModule (which would keep track of objects of InputField and Button type) and LogicModule (which would keep track of the Calculator implementations).

Modular programming just implies you have these two (or more) modules, but says nothing of how they achieve what they achieve. The modules can use object-oriented approaches or not at all and use procedural C-style programming. The way you described modular programming via classes is just a way of separating modules. You can separate them as classes, or you can separate them as functions across multiple compilation units, for example. It's your choice.

Object-oriented programming implies that your program is, well, oriented towards objects. It says nothing about modules within your application but demands that logical pieces that represent some ideas within the application are modeled via classes and objects.

As such, the two approaches can be used together, and when you decide to be modular, the object-oriented choice usually imposes on you that these modules are defined via classes and their relationships.