I was shocked by the popularity of the interview. Since it is advertised as a mission-orientedProgramClerk, I think it's my responsibility to write another article about polymorphism. I have no intention of initiating a non-technical dispute again. Therefore, the interview reply is not included in this article. This article is a pure technical text, which contains any errors. I have reserved the words "interview again" in my questions, so that the whole process starts and ends, because I said I would like to write an article like this.Article. However, please leave the background for the interview while reading.
Most of my articles are boring. I recommend you read Allen Lee or idior articles, or Google more articles (using Polymorphism or polymorphism as keywords ).
1. What is polymorphism?
Polymorphism is one of the most critical features of OO (gof ). Gof defines the ability to substitute objects of matching interface for one another at runtime. That is, the ability of interfaces matching objects to be interchangeable at runtime. On Wikipedia, it is expressed as..., polymorphism lets you treat derived class members just like there parent class's members. That is, polymorphism allows you to treat the derived class members as the parent class members. Not intuitive enough? In practical terms, polymorphism means that if Class B inherits from Class A, it doesn't have to inherit everything about class A; it can do some of the things that Class A does differently. That is, if Class B inherits from Class A, it does not have to inherit everything from Class A. For some methods, Class B can adopt different practices and implementations from Class.
In the language mechanism of Java and C #, polymorphism is post binding (or dynamic binding or late binding). There are two forms: inherit the parent class and reload the methods with the same signature in the parent class (namely overriding or overwriting); Implement abstract methods with the same signature in the parent class (or interface. When you call this method for an object declared by the parent class, the method in the corresponding subclass will be called. By the way, overloading is generally not considered a polymorphism mechanism.
In the OO idea, polymorphism hides the specific implementation, so that the client can access the object without knowing the specific implementation but only its interface, which makes abstraction possible.
2. Relationship between Polymorphism and abstraction
Let's use Wikipedia: Usually action is a mechanic and practice to reduce and factor out details so that one can focus on a few concepts at a time. That is, abstraction is a mechanism and practice that allows you to focus only on one thing at a time. I think it is easier to explain from the opposite. abstraction is not specific, so you can leave the details you don't care about.
Abstraction allows us to better classify objects. Imagine how helpless you are when facing a light bulb without being Abstract:
- It has weight, which is similar to stone;
- It has a volume, which is similar to stone;
- It emits light, which is similar to the sun;
- It consumes power, which is similar to a fan;
- It can be switched, which is similar to the door.
- ......
All these features belong to the light bulb, so the light bulb is not a stone, a sun, a fan, or a door. There is no abstraction. When you want to write a switch for a light bulb, it can only process the light bulb object, because in this world (in the system) there is no other thing with all the features of the light bulb.
What will happen to the world with abstraction?
- You said that a light bulb is a weight object, so it is a weighable (which can be weighed). The system used to weigh a stone is also suitable for the light bulb!
- You said that the light bulb is a volume object, so it is a stereometriable (product can be obtained). The system used to calculate the volume of the stone is also applicable!
- You said that the light bulb is an object that can be switched, so it is a switchable (switchable), and the system that is used to switch the door can also switch the light bulb!
Now we can classify the features of a bulb from different perspectives.
At this time, you will find that your system is less and less dependent on the light bulb. On which day the light bulb does not shine (also called the light bulb :)), you still don't need to rewrite the function. The abstraction is more stable than the specific class, so the dependency on abstraction is more stable than the dependent class.
It does not mean that abstraction cannot be achieved without polymorphism, but it is difficult to do so elegantly without polymorphism abstraction. Polymorphism in the language mechanism is abstract to deal with most of the details you don't want to care about.
Iii. Relationship between Polymorphism and Coupling
Definition of coupling: the degree to which software components depend on each other. That is, the degree of dependency between software components. When the system coupling is stronger, the more rigid the system is, the less maintenance it is, and the less reuse it is. What's worse, the more unstable the system is. In theory, all components in the system are coupled, but the degree of coupling is different. Therefore, our pursuit of decoupling is actually the pursuit of loose coupling. In this article, loose coupling is the ultimate goal of software. Although it is somewhat radical, it makes sense.
The decoupling method usually includes abstract coupling and adding layers. Abstract coupling: since it is necessary to depend on, the total ratio of abstraction is looser than that of dependency (for example, the observer mode ). There are many ways to add layers. In the OO mechanism, some functions can be transferred to a dedicated class in the way of delegation (for example, the creation function can be transferred to the factory ), this specialized class is a relatively stable class. You can also add a layer Isolation relationship with components you do not want to care about (such as the facade mode ).
Abstract coupling has been discussed in the previous section and is closely related to polymorphism. The main idea Method for adding layers is delegation, which has little to do with polymorphism.
It's Too Late To write it here today. The following examples may be added to demonstrate the relationship between polymorphism and coupling, as well as the relationship between polymorphism and common Ood principles, and there may be a relationship between polymorphism and design patterns.