When I was young, I got a tape recorder. It came with a large (A1 format) electrical scheme. This scheme contained the entire design of the machine: engine control, amplification, tone control (2 times, because it was a stereo machine), etc.
If you open a modern video recorder, you will see something entirely different. There are large components (subassemblies), like a preamplifier module, an engine control module, etc. that are clicked together with plugs.
History went the same for programming. We started with languages like GW-Basic, which were one "recipe" containing everything. But we now have object-oriented languages that allow us to do things in modules (called classes).
Mind you, there is absolutely nothing you can do with object orientation that you cannot do otherwise. You could build a video recorder in just one scheme as well.
So why do we do things in a modular fashion?
[ul]
[li]Because it's less work. This sounds really strange. Designing every component with plugs is extra work. However, if it is done correctly, you can reuse such a component. If you designed a preamplifier module for a CD player, you can use the same component in an MP3 player, a computer, a video recorder, your navigation system, etc. Also, a well-difined plug allows you to outsource such a component or use a ready-made one. The same thing applies to, say, a Database class.[/li]
[li]Because it is testable. If the only signals that a component receives come in trough the plug and come out through it, you can feed that component a known signal and check for the known output. It is quite normal for bought electronic components to be tested before they are built in. However, "unit testing" in software development is still a rare phenomenon. Strange.
By the way, this will only work if there are no hardwired connections between modules and everything really goes through plugs. The "Law of Demeter" guides you to design your classes well in an object-oriented application.[/li]
[li]Modular components have little impact on the rest of the structure. This comes from the fact that a plug usually defines an abstract function. A sound plug only tells you that a device produces or consumes a sound signal. It does not tell you how it is generated. The same plug is found on a CD player, a cassette player, etc. Your wall power socket does not care what you connect to it as well, as long as it behaves correctly. This means that a plug is recongizable, and that components have a responsibility. Google for "Design by Contract" if you want to know more on this.[/li]
[li]Modules are much easier to maintain. Due to their limited implact on the rest of the design, their clickable nature, and their coverager of only a part of the functionality, they can eaily be repaired or replaced. What's more, you don't need to know the insides of a component. The plug tells you enough.[/li]
[li]The responsibility allows a component to do its own optimization. A clock card in your PC might have its own battery, for example. Or a Database class may only open a connection when one is needed.[/li]
[/ul]
Now wait. Do objects have plugs then? Certainly. They are called the interface of the object. The interface consists of all accessible methods and properties (including the constructor). To be recognizable, you should therefore always used meaningful names for methods.
(Do not confuse this with the interface keyword in a lot of languages, which defines a restriction on the interface of an object: the interface should have at least these methods)
Off course, there is a lot more to tell, but this is probably complicated enough already. I hope it clarifies some things.
![[rofl]](/data/assets/smilies/rofl.gif "[rofl] [rofl]")
![[rofl2]](/data/assets/smilies/rofl2.gif "[rofl2] [rofl2]")