Most of the time, we understand that object-oriented means adding methods to data, encapsulation means hiding data, but this is not comprehensive. For example, a cat has a head, four legs, and a tail. Although there is no error, it is not comprehensive. In terms of appearance, this is indeed the case for Object-Oriented objects, but what is its essence? Let's take a look at design patterns explained, which tells us something.
Functional breakdown vs. demand changes
Before object-oriented development, we adopt a process-oriented development method. The most common analysis method for process-oriented development is functional decomposition. We will break down the requirements obtained from customers into modules, break down modules into major functions, break down large functions into small functions, and finally break them into functions one by one. This is very easy to do, but there will be a problem: process-oriented control Program (Generally the main program) undertakes too many responsibilities.
All control procedures should be taken care of, as if some families are too fond of their children, and all their parents are packed. After such children go out, they will often suffer from slight grievance and poor adjustment ability. This is often the case with process-oriented development programs that are too fragile to respond to changes in requirements.
Decomposition of responsibilities vs functional decomposition
Since process orientation cannot cope with changes well, what is the difference between object-oriented architecture and it? The answer is shift of responsibility ). The decomposition of responsibility is actually very simple, that is, to do what you do, to be responsible for yourself, just as parents don't have to do everything for their children, guide them, and then let them do it by themselves, in this way, the effect is often better, and the parents are more relaxed.
The object-oriented model encapsulates a series of methods and data with the same responsibilities in a class, which improves cohesion. Code From a point of view, this reduces the number of duplicates. In addition, object-oriented also abstracts these similar classes into abstract classes or interfaces to further reduce repeated code. When objects call each other, they often depend on abstract classes and interfaces. In this way, the coupling between codes is greatly reduced. In a word, object-oriented systems are inherently suitable for increasing cohesion, reducing coupling and repetitive code, so as to better cope with changes in requirements.
Summary
The key to object-oriented is responsibility decomposition. Interfaces, inheritance, and encapsulation are not only used to hide data, but more importantly, hidden types are loosely coupled.
