Modularity - I'd like to understand the term better

Question

I just watched this video:

https://youtu.be/QyJZzq0v7Z4

The guy tries to sort out how OOP became the boss of paradigms and not functional programming.

He seems to claim that, when OOP languages were adopted, programmers secretly wanted modules/modularity and more or less clumsily ended up with classes and objects instead.

He names Go as a language having no classes, but modules (and no inheritance since even OOP fans don't trust it much) and sort of describes that as the quintessence of modularity.

I get the feeling he has a very specific understanding of the word.

In my mind, modularity is just an abstract term that could describe many things:

Modules, classes, objects, but also functions, since they isolate a specific task, hide the implementation details and provide a clean interface - args plus return value.

Anyone got an idea what exactly he's talking about?

Answer 1

Your two descriptions sound more like what I had in mind - a rather general concept.

The speaker in the video has one screen in his presentation that says modules were about having a public interface and a private implementation.

Then he basically goes on to state: See? That's like encapsulation all over again, so who needs encapsulation? (Yeah, rather polemic. 😉)

In a book about OOP which I had only started to read, a module was described as *any* separate unit of code that has one job.

Java had no modules before, right? So every class was itself a module. But now they also have a *specific* module thing, right?

In Python, it's confusing for me to decide what should be a class, or what a module, or what comes together in what.

I recently got the feeling, that modules and classes in Python are somewhat overlapping with each other's responsibilities.

(Makes only sense that modules also have no real privacy. 😉)

Answer 2

Based on the way modular languages are designed, I think modularity is more than just seperation of concerns.

A module is a standalone class, function, package etc. that performs a specific tasks. It must be reusable across projects and the implementation details must be internal and hidden. It is not limited to OOP but is easily achieved in OOP.

Your question:
"In my mind, modularity is .... isolate a specific task, hide the implementation details and provide a clean interface"

If it does all that and can be easily distributed for reuse then it is a module

Answer 3

Modularity is related to Single Responsibility Principle.

SOLID Principle, by Web Dev Simplified

S - Single Responsibility Principle
https://youtu.be/UQqY3_6Epbg

O - Open / Closed Principle
https://youtu.be/-ptMtJAdj40

L - Liskov Substitution Principle
https://youtu.be/dJQMqNOC4Pc

I - Interface Segregation Principle
https://youtu.be/JVWZR23B_iE

D - Dependency Inversion Principle
https://youtu.be/9oHY5TllWaU