Modular Programming – Most Programmers Think They do it. But Hardly Anyone Does!

Very well explained

I’m loving this series. I appreciate your clear and straight forward way of teaching. It’d be wonderful to see a video covering the functional programming approach as well.

I will write my first assumption of what modularity is here and see if by the end of this video, the explanation is better.

Modularity is simply the ability to hold one module in the mind’s context without having to consider anything else.

Modularity is not a computer science concept. It is a reality concept.

All of the ideas around it exist to accomplish this.

Information hiding isn’t anything really. It is simply a way to control what users (including me) have to think about when looking at this block.

Imagine if all clocks were opened up and you had to solder the power source to it to start it.

This is the other extreme against modularity.

It works, but the amount of irrelevant information provided to the consumer can be greatly reduced.

I have personally found the physical analogy to be most helpful in understanding all of the techniques around it.

Now, to watch the video.

So let me get this straight : You can only pass by value into a function of an object in Smalltalk?
How about passing arrays of any dimensions? In C++ that is done by reference since you wouldn't get to the "next value" in the index of the array without knowing where the whole array starts.
How is that done in Smalltalk? Or passing arrays as pointers where you can have dynamically sized arrays? (yes there are also pre-defined data structures that are dynamic arrays in C++ but that is beside the point).

Technically this is a breach of contract since the caller is relying on unspecified internal behavior (the object being passed being altered internally) but I see your point.

No bad though. So far I've only seen a couple of your videos and although I find them a bit drawn out, that might be a good thing for those not so familiar with what you should actually be doing with OOP, which seems to be a lot of programmers. I had a suspicions that the original ideas were actually well thought out but had their various implementations broken (cough, C++, cough) and it looks like those were right.

Your GetBonus example isn't quite right. The argument passed by reference is technically part of the function's interface, so if the developer doesn't modify the argument, he's violated the interface's contract. It's more of an example of why not to duplicate interface features as part of making good interfaces.

😮😮😮😮😊😮😮

😮😮😮😮😮😮😮😮

Thankyou for this in depth exploration of object-oriented programming. I am getting hung up on this idea of message passing. In an earlier video I believe you mentioned that a message may not be a command. This gives me the impression that messages should behave more like events. So I wonder if part of the confusion with OO is just this. For example, rather than telling the black box to give you chocolate, you might just say I am hungry for chocolate.

Lovely explanation. Thank you

I really liked this explanation!

Nice explainer.

As a college student learning modularity (yay Pascal!) in the early-to-mid 80s, this idea was not taught. I'm not sure object-oriented programming was even mentioned. When I came across OOP after college, I could not wrap my head around it. When I dove headlong into PL/SQL (and O'Reilly's PL/SQL Vol 2) is when I really started getting a better grasp. And still, I'm barely a novice.