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

What is modularity? Dividing code into separate files? No! Hiding data? Well, up to a point… Protecting implementation details? Well, that’s a bit nearer the mark. But what does that really mean? How do you protect the implementation details of a module or an object? And why does it matter?

In this lesson, I look at some of the ideas and the history of modular programming. From Smalltalk to Modula-2, and onwards to C#, Ruby, Java and Object Pascal, I’ll try to explain what modularity is and why your code will be more reliable if you make use of it.

BOOKMARK THE SERIES PLAYLIST

To follow this series in order, bookmark the playlist. New episodes are added to the playlist whenever they are published.

DOWNLOAD SQUEAK
Squeak Smalltalk

DOWNLOAD THE SMALLTALK/V TUTORIAL
I will using the excellent Smalltalk/V Tutorial as the “course text” for this series and I encourage you to download a PDF copy of that too:
or:

SUBSCRIBE TO THE CODE WITH HUW CHANNEL

To be notified whenever I upload new lessons, be sure to subscribe.

WHO IS HUW COLLINGBOURNE?

I’ve been programming since the early 1980s. I’ve written wrote programming columns on Java, C#, Delphi and other languages for “PC Plus Magazine”, “Computer Shopper” and numerous other UK magazines. I wrote the cult adventure game, The Golden Wombat Of Destiny, I have developed programming tools with SapphireSteel Software and I have written programming books published by Dark Neon and No Starch Press. These include books on programming C, C#, Java, Ruby, Delphi and Object Pascal, pointers, recursion and programming adventure games.
All my books can be found on Amazon.

Keep in Touch
==============================

Code With Huw on Facebook:

[vaishantsah]

This videos required so much research that the hard work shines on your face! Mad respect!

[CipherOne]

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.

[lucavalentino]

Thanks for this course! I feel less alone finally. ❤
As a Smalltalk developer I had to work on other projects in other languages (C#, Python, Java) and it was always a big pain as most of developers don't understand OO, don't understand encapsulation, don't understand messaging and therefore modularity. In addition they think that OO is mainly about state and state change which is not at all a prerequisite for OO.

[jackcurl]

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.

[mehtubbhai]

Thank you Huw for giving me a much better understanding of OOP. Never has it been explained so well to me👍

[BrainInAVat]

This is in line with how modularity and encapsulation are understood in cognitive science. Perhaps it’s no accident Fodor wrote “Modularity of Mind” in the early 80’s

[wumbo]

I'm a beginner Python developer and I have wrote code in procedural way. I was wondering why we need OOP. I love how this series explains what are the urgencies and problem that OOP mean to solve. You are a great explainer and storyteller too!

[eyeiozm]

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.

[plsreleasethekraken]

8:16 isn't this just the functional concept of pure vs impure functions?

[zoltankovacs]

Very interesting aspects of OOP. I think what modern languages do is a totally broken OOP. It is some "pragmatical" mixture of the original ideas. It can not even be fixed because of the ecosystem which forces to "inherit" the wrong behavior. People often think OOP modularity is about using private fields with public methods but that is not true. OOP modularity is a different way of thinking. You can write low level accessors and mutators for private fields that seems to be very modular, however it is just a fake modularity with low level binding. Message sending is about high level binding: I ask/request the printer to print not just set its inner values using setters then call its print method. Etc..etc...
Low level binding is bad because it leaks the inner structure of an object and leaks cause spaghetti code and reduces robustness.

[VIRAJBHOSLE]

Where exceptions fit into this? for example divide by zero exception? Is it considered as a response?

[Astrosisphere]

Does it matter whether the object in question is a black box or a white box regarding modularity though? I mean if an object only holds data, what's wrong with exposing the data it holds directly. For example, in C#:
```
public enum MidiNote : byte
{
A1,
ASharp1,
B1,
C1
//...↓
}
public readonly record struct PianoKey(decimal Frequency, MidiNote MidiNote);
public readonly record struct Keys);
```
All of the data on all of these objects can come out of the object the same way it went in; I guess the question comes in on: where does that data get created? In this form I'd say I'd have a function on PianoKeyboard which creates a default set of PianoKeys but by also having this constructor public, it allows an alternative implementation to be created by the caller - does this break modularity though?

[jks]

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.

[Peter_prker]

These videos feel like Cosmos from Sagan but for programmers 🙌

[Magnus_Loov]

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).

[perfectionbox]

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.

[pointer]

This channel is vastly under appreciated by the algorithm. Hey Algorithm, GET IT TOGETHER.

[loc]

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.

[johnp.johnson]

Typical of academia, which has polluted the business world is excessive jargon. Essentially, , it is Tower of Babel gibberish.

Egg heads misunderstand each other and hence the proliferation of false meanings to concepts.

Often they are not even talking about the same levels of zoom. The confuse and conflate all of these: modularity, modules, modular programming, information hiding, encapsulation, object-oriented, message oriented.


*RIGHTLY*

Modular programming is how one implements modular design, i.e., modularity.

A module should be a component of a system emulated or modeled in software.

In modular programming, Team A could write a module emulating a printer. So could Team B.

The internals are irrelevant. What matters is that each module exports the same interface so that Team C can use either version.


*ALL OF THE JARGON and CONTINUAL JARGONIZING* reveals what utter bullshit the field of computer science is, at least on the software side.

In software, the closest, truest concept of modularity are plug-ins / add-ins. Some would argue dynamic linked libraries, but these only offer up functions.

Take a real world object like a guitar amp. It has internal electronics that manipulate electronic signal. It has an interface to control volume, signal frequencies and so on.

A software guitar amp modeller would be a modular system that would abstract the UI and the amp internals so that one could model write "black box code" to produce the signals of these amps: Fender 5E3 Deluxe, Marshall JCM800, Marshall 1959 Super Lead 100 Watt Plexi, Vox AC30, Fender Twin Reverb and so on.

All that would be needed is an API to tweak the generated signal with software controls that emulate volume, treble, bass, reverb, etc.

*REAL OOP*

Real OOP would use DSLs to pass messages and not function calls renamed as method calls.

"Tell me your size" would be the message rather than a.sizeof

*Another notably bad misuse of language by eggheads is "information hiding".*

Rightly that ought to be called DESIGN HIDING or IMPLEMENTATION HIDING or at minimum INTERNAL STATE DATA HIDING.

Information is data in sequence that conveys meaning. Key-value pairs might define aspects of a thing, but are not information. Code to implement a method or function definitely is not information.