"Hello, Amigo! I'd like to tell you about another benefit of OOP. You see, programs are more like animals than buildings. They aren't built, they're grown. Development means constant changes. In construction, you can have a good plan and follow it to a T. But in software development, that's not the case."
Quite often, you can't do something in the way you intended to, and you have to rework your program a lot. And even more often, the customer's requirements change.
"But what if the customer provided a really detailed specification?"
"Take a look at what happens over time. If a product succeeds, the customer will want to release a new version, and then another, and another. And, of course, you'll have to make a few «small changes» to the existing product. So software development is a long series of changes. Only the cadence differs. A new version might be released each week, once a month, or every six months."
"So what do we conclude from all this?"
"The product's internal structure must be maintained in a way that will allow major (and minor) changes to be made with minimum reworking."
"How do you do that?"
"We've already talked about how a program consists of objects that interact with one another. Let's use thick dots to represent all of our program's objects on the board. We'll draw arrows from each object (dot) to all of the objects (dots) that it interacts with."
Now let's combine the objects (dots) into groups. Dots belong to the same group if they are a lot more connected to each other than the other dots. If most of a dot's arrows point at dots in its group, then we've group the objects correctly. Dots within the same group are said to be tightly coupled, while dots in different groups are loosely coupled.
This is called the «principle of loose coupling».A program is split into several parts, often layers, whose logic is strongly tied to their internal structure and weakly tied to other layers/parts. Interaction between layers is usually highly compartmentalized. One layer can call another layer using only a small subset of its classes.
"The same 'division of labor' principle, but on a larger scale?"
"Precisely. This allows us to reorganize a department, make it more efficient, and hire even more people, and if we don't change the interdepartmental protocols, then all our changes will be local. Nobody has to be retrained. We don't have to rework the entire system. Each department can optimize its internal affairs in this way if the mechanisms for departmental interaction are chosen well."
"If they're chosen well. And what if they aren't chosen well?"
'Then you'll quickly run out of «wiggle room» for making changes, and have to rework the entire system. That happens from time to time. We can't predict the future, but we can minimize the number of times we have to rewrite the program."
"Okay. I see the benefit of dividing the program like that, but how does OOP come into the picture?"
"When we choose how to structure the departments and how they will interact, we apply the 'principle of abstraction'. In programming, abstraction is used to determine the best way to split up the program and how the parts should interact. This principle can also be applied repeatedly to the constituent parts until we have broken the program down into individual classes."
"And hiding the internal structure of these parts, and strictly limiting how they interact with other parts – that's encapsulation, right?"
"Exactly. Encapsulation and abstraction are cornerstones of OOP. A good program must adhere to these two principles. Later we'll take a look at other principles and come to understand their advantages."
"Good stuff. I can't wait!"
GO TO FULL VERSION