Detailed explanation of examples of interface-oriented programming in Java

This article introduces some things about interface-oriented programming to everyone by combining the nature of interfaces, the relationship between object-oriented programming and interface-oriented programming, and some of the author's own understandings. Friends who need it can learn about it.

I think that for programmers who use object-oriented programming languages, the term "interface" must be familiar, but I wonder if you have such doubts: What is the use of interfaces? What is the difference between it and abstract class? Can an abstract class be used instead of an interface? Moreover, as a programmer, you must often hear the phrase "interface-oriented programming", so what does it mean? What is the ideological connotation? What is its relationship with object-oriented programming? This article will answer these questions one by one.

1. What is the relationship between interface-oriented programming and object-oriented programming?

First of all, interface-oriented programming and object-oriented programming are not on the same level. , it is not an independent programming idea more advanced than object-oriented programming, but is attached to the object-oriented ideological system and is part of it. In other words, it is one of the essence of ideas in the object-oriented programming system.

2. The essence of interface

Interface, on the surface, is a collection of several method definitions without body code. A unique name that can be implemented (or inherited) by a class or other interface. It may look like the following in form:

interface InterfaceName
{
void Method1();
void Method2(int para1);
void Method3(string para2,string para3);
}

So, what is the essence of an interface? In other words, what is the meaning of the existence of the interface. I think it can be considered from the following two perspectives:

1) An interface is a set of rules, which stipulates a set of rules that a class or interface that implements this interface must have. embodies nature's philosophy of "if you are..., you must be able to...".

For example, in nature, everyone can eat, that is, "if you are a human, you must be able to eat." Then when simulated into a computer program, there should be an IPerson (customarily, the interface name starts with "I") interface and a method called Eat(). Then we stipulate that every class representing "person" must implement IPerson interface, which simulates the rule of nature "If you are a human, you must be able to eat".

From here, I think you can also see some object-oriented thinking. One of the cores of object-oriented thinking is to simulate the real world and abstract things in the real world into classes. The entire program relies on instances of each class to communicate with each other and cooperate with each other to complete system functions. This is very consistent with the operating conditions of the real world and is also oriented to The essence of object thinking.

2) An interface is an abstract representation of similar things on a certain granular view. Note here that I emphasize on a certain granular view, because the concept of "similar things" is relative, and it differs because of different granular views.

For example, in my eyes, I am a person, fundamentally different from a pig. I can accept that my classmates and I are the same kind, but I can never accept that I and a pig are the same. similar. However, if in the eyes of a zoologist, pigs and I should be of the same kind, because we are both animals, he can think that both "people" and "pig" implement the IAnimal interface, and when he studies animal behavior, he does not He will treat me and the pig separately, and will study it from the larger granularity of "animal", but he will think that there is an essential difference between me and a tree.

Now I have changed to a geneticist, and the situation is different. Because all living things can be inherited, so in his eyes, I am not only no different from a pig, but also a mosquito, a bacteria, a There is no difference between a tree, a mushroom or even a SARS virus, because he will think that we all implement the IDescendable interface (note: descend vi. inheritance), that is, we are all heritable things, and he will not study us separately, but He will study all living things as the same kind. In his eyes, there is no distinction between humans and viruses, only heritable materials and non-heritable materials. But at least there is a difference between me and a stone.

But something unfortunate happened. One day, a great man appeared on the earth. His name was Lenin. After familiarizing himself with Marx and Engels’s masterpieces of dialectical materialism, he became quite knowledgeable. So he made a famous definition: the so-called substance is the objective reality that can be reflected by consciousness. At this point, there is no difference between me and a stone, a breath of air, an idiom, and the electromagnetic field that transmits mobile phone signals, because in Lenin's eyes, we are all objective realities that can be reflected by consciousness. If Lenin were a programmer, he would say this: The so-called matter is the instances generated by all classes that implement both the "IReflectabe" and "IEsse" interfaces. (Note: reflect v. reflect esse n. objective reality)

Maybe you will think that my above example is nonsense, but this is exactly the meaning of the existence of interfaces. One of the core concepts of object-oriented thinking is called polymorphism. What is polymorphism? To put it bluntly, it means that similar things are treated uniformly without distinction at a certain granular view level. The reason why we dare to do this is because of the existence of interfaces. Like the geneticist, he understands that all organisms implement the IDescendable interface, so as long as it is an organism, it must have the Descend() method, so he can conduct unified research instead of studying each organism separately and eventually dying of exhaustion.

Maybe I can’t give you an intuitive impression of the nature and function of the interface. Then in the following examples and analysis of several design patterns, you will more intuitively experience the connotation of the interface.

3. Overview of interface-oriented programming

Through the above, I think everyone has an understanding of interfaces and the ideological connotation of interfaces, then What is interface-oriented programming? My personal definition is: in system analysis and architecture, distinguish the levels and dependencies. Each level does not directly provide services to its upper layer (that is, it is not directly instantiated in the upper layer), but only by defining a set of interfaces. The upper layer exposes its interface function, and the upper layer only depends on the interface of the lower layer and does not rely on specific classes.

The benefits of doing this are obvious. First of all, it is great for system flexibility. When the lower layer needs to be changed, as long as the interface and interface function remain unchanged, the upper layer does not need to make any modifications. You can even replace the entire lower layer without changing the upper layer code, just like we replace a WD 60G hard drive with a Seagate 160G hard drive. There is no need to make any changes to other parts of the computer. Instead, we unplug the original hard drive and install the new hard drive. Just plug it in, because other parts of the computer do not rely on a specific hard disk, but only rely on an IDE interface. As long as the hard disk implements this interface, it can be replaced. From here, the interface in the program is very similar to the interface in reality, so I always think that the word interface is really similar!

Another benefit of using interfaces is that developers of different components or levels can start work in parallel. Just like those who build hard disks do not have to wait for those who build CPUs or monitors. As long as the interfaces are consistent, the design It is reasonable and can be developed in parallel to improve efficiency.

This article ends here first. Finally, I would like to say one more thing: the essence of object-oriented is to simulate reality, which can also be said to be the soul of my article. Therefore, thinking more about object-oriented things from reality will be of great benefit to improving system analysis and design capabilities.

In the next article, I will use an example to demonstrate the basic methods of interface programming.

In the third article, I will analyze some interface-oriented programming ideas in classic design patterns, and analyze the interface-oriented ideas in .NET layered architecture.

1. Regarding the two words "interface" in "interface-oriented programming" and "interface" in specific object-oriented languages

See A friend once suggested that the word "interface" in "interface-oriented programming" should have a wider scope than the word "interface" in a pure programming language. After thinking about it, I think it makes sense. What I wrote here is indeed unreasonable. I think "interface" in object-oriented languages ​​refers to a specific code structure, such as the interface defined with the interface keyword in C#. The "interface" in "interface-oriented programming" can be said to refer to a structural component that is used to hide specific underlying classes and implement polymorphism from a software architecture perspective and from a more abstract level. In this sense, if an abstract class is defined and the purpose is to achieve polymorphism, then I think it is reasonable to call this abstract class an "interface". But is it reasonable to use abstract classes to implement polymorphism? Discussed in the second article below.

In summary, I think the two concepts of "interface" are both different from each other and related to each other. The interface in "interface-oriented programming" is an ideological architectural component used to achieve polymorphism, improve software flexibility and maintainability, and the "interface" in a specific language is a concrete component in this ideological level. Implemented into the code.

2. Regarding abstract classes and interfaces

This is a more intensely discussed issue in the replies. I'm sorry that I didn't think twice about discussing this in the article. My personal understanding of this issue is as follows:
If you look at the specific code alone, it is easy to blur these two concepts, and even think that the interface is redundant, because from the specific function alone, except for multiple inheritance (C# , Java), abstract classes seem to be able to completely replace interfaces. But, does the interface exist to implement multiple inheritance? of course not. In my opinion, the difference between abstract classes and interfaces is the motivation for their use. The purpose of using abstract classes is for code reuse, while the motivation for using interfaces is to achieve polymorphism. So, if you are indecisive about whether to use an interface or an abstract class somewhere, think about your motivation.

I saw some friends questioning the IPerson interface. My personal understanding is that whether the IPerson interface should be defined depends on the specific application. If we have Women and Man in our project, both inherit Person, and most of the methods of Women and Man are the same, only one method

DoSomethingInWC() is different (the example is rather vulgar, please forgive me), then of course the definition An AbstractPerson abstract class is more reasonable, because it can include all other methods, and the subclass only defines DoSomethingInWC(), which greatly reduces the amount of repeated code.

However, if the Women and Man classes in our program basically have no common code, and there is a PersonHandle class that needs to instantiate them, and we don’t want to know whether they are male or female, but just Treat them as human beings and implement polymorphism, then it is necessary to define them as interfaces.

In short, the difference between interfaces and abstract classes mainly lies in the motivation for use, not in themselves. Whether something should be defined as an abstract class or an interface depends on the context of the specific environment.

Furthermore, I think another difference between interfaces and abstract classes is that there should be a general and special relationship between an abstract class and its subclasses, while an interface should only be a subclass. A set of rules implemented. (Of course, sometimes there may be a general and special relationship, but the purpose of using interfaces is not here.) For example, it is acceptable to define vehicles as abstract classes, and cars, airplanes, and ships as subclasses, because cars, airplanes , ships are a special means of transportation. Another example is the Icomparable interface. It just says that classes that implement this interface must be comparable. This is a rule. If the Car class implements Icomparable, it just means that there is a method in our Car to compare two Car instances. It may be more expensive or larger, it doesn't matter. But we can’t say “cars are a special kind of thing that can be compared.” This is grammatically unreasonable.

Summary

#In general, interface-oriented programming means that between all classes or modules in an object-oriented system The interaction is completed by the interface.

The above is the detailed content of Detailed explanation of examples of interface-oriented programming in Java. For more information, please follow other related articles on the PHP Chinese website!