How do I Understand Java Abstract classes and interfaces?

How do I Understand Java Abstract classes and interfaces?

During interviews, we are often asked: What is the difference between abstract classes and interfaces in Java? Then, let's say that an abstract class can have methods, and an interface cannot have actual methods. A class can only inherit one abstract class, but can inherit multiple interfaces. A lot of balabala, it is like speaking out the standard answer skillfully.

Abstract classes and interfaces this article describes their differences and relationships. They do have many similarities, but in essence, or from the perspective of language design, this is not the essential difference between them.

I personally understand these two points:

A class is the abstraction of a specific instance, such as the abstraction of A json string; an abstract class is the abstraction of a class; an interface is the abstraction of an abstract class, and an interface is more like a protocol.

Listen to me ~

Tucao

First of all, I have to talk about this interview. I think the interviewer asks such questions as "talking about the differences between abstract classes and interfaces" and "talking about the differences between processes and threads, is not responsible.

Why?

One reason is that the interviewer does not have his or her own rating for the target person, and the other reason is that he or she is not responsible for the subject. This problem cannot be used to test the interviewer's level.

So if I come to interview someone else, I will ask: Could you tell me how you understand abstract classes and interfaces? If you want to explain the difference between processes and threads to your grandmother, how would you explain them?

I think this can test the interviewer's understanding of the problem. I think Microsoft's interview questions (How do you explain Excel to your grandmother) can also test a person's understanding of something (although, so far I still cannot quite understand this question -. -)

Differences between abstract classes and interfaces

When talking about abstract classes and interfaces, you must talk about classes.

A class is the abstraction of real things.

For example, to define a BenzCar class, you need to have a good abstraction of the real Mercedes-Benz cars (of course, there are many series of Mercedes-Benz cars, which won't be a perfect place here ). That is to say, if you want to build a Mercedes-Benz car, you need BenzCar (this Mercedes-Benz car is an Instance in memory ).

The abstract class is the abstraction of the class.

How can this problem be solved? That is to say, many Car manufacturers define a specification (Car type) together. To build a Car, there must be an engine, tires, and sound equipment... (These are equivalent to abstract methods.) The specific engine, tires, and audio equipment used are completed by each vehicle manufacturer. In this way, there will be a variety of cars, the Mercedes-Benz brand, the BMW brand, the Toyota brand...

An interface is an abstraction of an abstract class.

This is my personal understanding.

In our daily life, we can see various "interfaces", and the power outlet is one. At first, I saw Uncle mouse's blog start to understand the concept of "control flip"-IoC/DIP is actually a management idea | CoolShell.cn. Later, I thought that this thing is actually everywhere. The factory that manufactures power sockets and the factory that manufactures electrical appliances only need to agree on an interface-two or three sockets, of course, interfaces in different countries are different, and the conversion between different interfaces requires an adapter.

In fact, the same is true in the program. For example, all transportation tools can be abstracted as an interface Drivable (I may not think well due to experience ), indicates that the objects created by the class implementing this interface (such as cars, airplanes, ships, and so on) are all public interface Drivable {public void drive;} and, we can create a AbstractCar class, which indicates that this class is an abstraction of all automobile classes, and all vehicles that can drive must inherit this class. This abstract class specifies some abstract methods, for example, getEngine, you can also inherit the AbstractCar class to abstract all vehicles that may have the same engine ). Drive is set to abstract. The two implementation methods are the same in terms of functions, but they are different in terms of class design. In the following code, I refer to java. util. abstractList * @ throws UnsupportedOperationException * if adding to this List is not supported. public abstract class AbstractCar implements Drivable {public abstract Engine getEngine; public abstract Wheel getWheel; @ Override public void drive {throw new UnsupportedOperationException ;} // omit other methods and attributes} by default, "car" cannot be enabled. After you implement a car, you need to Override this method, implement your own drive method. Use the List in the java container as an example.

Find the source code, and you will find that the top level of the inheritance relationship is Iterable, which means that List can be traversed, And it will generate an Iterator interface object. This indicates that a list can be traversed through this iterator.

As mentioned above, all vehicles can be driven, and all lists can be traversed.

A layer-by-layer approach makes the class more specific.

Last

Why can interfaces be inherited?

In fact, this principle is very simple. Because there is always a most essential protocol to constrain everyone, for example, all the means of transportation can be driven, all the easy to traverse. Then the protocol will gradually become more specific:

Iterable <-Collection <-List <-AbstractList <-List

From the bottom up, it is a layer-by-layer abstraction.

As I said at the beginning of the article,