Introduction to object-oriented

During this time, I was brainwashed by Mr Mi every day and talked about a center oriented object!

However, what exactly does object orientation do? Let's take a look at what Wikipedia says:

Object-Oriented Programming (OOP) is a programming model and a programming method. An object refers to a class instance. It uses objects as the basic unit of a program and encapsulates programs and data to improve software reusability, flexibility, and scalability.

So what is the difference between him and the traditional design? Similarly, we provide our answer in Wikipedia:

Object-Oriented programming can be seen as an idea that contains various independent and mutually called objects in a program. This is just the opposite of the traditional idea: in traditional programming, a program is regarded as a collection of functions, or directly a series of commands issued to computers. Every object in object-oriented programming should be able to accept, process, and transmit data to other objects, so they can be considered as a small "machine", that is, an object.

I think there is a very important sentence here: "Every object in object-oriented programming should be able to accept, process, and transmit data to other objects." I think, if any object in our project cannot meet this requirement, it cannot be called object-oriented.

For example, when we write a program, we want to write a function for the student examination. People who have done the examination system know that these questions are involved in the student examination. First, whether it is random question extraction or fixed question type, in fact, whether it is on-site examination or after the examination, and whether the answer is out of order, etc. Now, if we use object-oriented design ideas, how should we proceed? First, encapsulate question extraction into an object called question extraction class, encapsulate the judgment and determination into an object called classification, and encapsulate the answer in disorder, what will we do later? I think it is easy to think about it. The key is, how can we proceed down? Let's talk about my initial thoughts:

The idea at the beginning was: You don't need to write a test method to achieve question extraction. random question extraction and classification. spot score, out of order. it is returned to the user in non-disordered order. It is reasonable. If you need to change the question extraction method, you only need to expand the question extraction class. However, have we ever thought that, even so, we still need to modify the client, that is, the code in my exam class? further, we can use reflection, write the required call in the configuration file so that reflection can be called directly. But what if we need to add one? For example, we need to add one. If the score is not suitable for re-reading the exam? Or others, in any case, we cannot encapsulate the examination class well.

Or let's take a closer look. If we don't need to call it directly through reflection, I think it is more like process-oriented development, because the examination class depends on the three classes, there is no way to develop the test class independently without the three classes! All we do is divide the code in a class into several copies.

Next, let's talk about it. After these days of fierce struggle, if we are designing it, we may be like this:

First of all, I need to develop four objects: Question extraction, classification, out-of-order, examination, and summary. To remove the messy things, we actually get the exam and show it, so there are very few items in the examination class. Then, how are they associated and handed over to the container.

Therefore, our containers are crucial. What we need to do is to throw the objects written in this way to containers without knowing who they are, the relationship between them is determined by the container, and the user can directly deal with the container. Therefore, if there is a container, We developers only need to develop independent particles one by one. If you want to call other particles in a particle, as long as there is a process, they are not purely object-oriented. Let the container decide how to call them.

For example, when we were a child, we often encountered a situation where the team was standing. Now we can regard the people who needed the Team as one object and there is no relationship between them, it is not said that a must be associated with B, and C must be associated with D. However, our teachers usually say that small C should be arranged by size, we naturally know that this is the arrangement, or another teacher has come. The teacher said, boys and girls are listed in a column, and we will automatically sort them in the order of boys and girls, it does not depend on us, but on who calls us, that is, on which container we are placed, the container determines who is before us and who is behind us. Therefore, as developers, we only need to care about the relationship between a small A and B. We need to look at what containers we put in. In this way, during the development process, this reduces the coupling between objects. At the same time, the reuse is greatly improved during use, because any object can be used, if small A and Small B are connected (that is, the call relationship we often write in the Code), if small A and B can be used in the queue from high to short, from short to high queues will inevitably be unavailable, and the value of reuse will be lost.

 

This is my understanding over the past few days. As for how containers manage these objects, there is no practice, so I will not discuss it in detail. Here I will talk about a kind of understanding of object-oriented in these days, yes or no. please correct me!