How do I understand abstract classes and interfaces in Java

In the interview, we are often asked: what is the difference between abstract classes and interfaces in Java?

Then, let's talk about that abstract classes can have methods, and interfaces can't have actual methods; A class can only inherit one abstract class, but it can inherit multiple interfaces. There are a lot of balabalas, just like saying the standard answers skillfully.

Abstract classes and interfaces have talked about their differences and connections. They do have many similarities, but in essence, or from the perspective of language design, this is not their most essential difference.

I don't sell off. My personal understanding of these two is as follows:

Listen to me slowly~

To make complaints about

First, I must make complaints about this interview. I think it is irresponsible for interviewers to ask questions like "tell the difference between abstract class and interface", "tell the difference between process and thread" and so on.

Why?

One reason is that the interviewer has no own evaluation criteria for the person who wants to recruit. The other reason is that he is not responsible for the opposite candidate. This kind of question can't test the interviewer's level at all.

Then, if I come to interview others, I will ask: please tell me how you understand abstract classes and interfaces; If you had to explain the difference between process and thread to your grandmother, how would you explain it?

I think this can test the interviewer's understanding of the question. I want to test a person's understanding of something like Microsoft's interview question (how do you explain Excel to your grandmother) (although I can't understand this question well so far -)

The difference between abstract classes and interfaces

When it comes to abstract classes and interfaces, we must talk about classes.

A class is an 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, Mercedes Benz cars have many series, which is not to be learned here). That is to say, if you want to build a Mercedes Benz car, you need the benzcar class (this Mercedes Benz car is an instance in the memory).

Then an abstract class is an abstraction of a class.

How to understand? In other words, many automobile manufacturers define a specification (car type), saying that to build a car, you need to have engines, tires and sound equipment... (these are equivalent to abstract methods). Each automobile manufacturer should complete the specific engines, tires and sound equipment by itself. In this way, there are all kinds of cars, Mercedes Benz, BMW and Toyota

An interface is an abstraction of an abstract class

This is only my personal understanding.

We can see all kinds of "interfaces" in our daily life, and the power socket is one. At the beginning, I saw Uncle mouse's blog begin to understand the concept of "control flip" - IOC / dip is actually a management idea - cool shell cn。 Later, I thought that this thing is actually everywhere. As long as power socket manufacturers and electrical appliance manufacturers agree on an "interface" - two or three sockets, of course, the interfaces in each country are different, and adapters are needed for conversion between different interfaces.

In fact, the same is true in the program. For example, all vehicles can be abstracted as an interface drivable (I may not consider it very perfect due to experience), indicating that the objects created by the classes implementing this interface (such as cars, planes, ships, etc.) are drivable

public interface Drivable{
    public void drive();
}

Then, we can create an abstractcar class to represent an abstraction of all car classes. All cars that can drive must inherit this class. This abstract class specifies some abstract methods, such as getengine () method, which shows that the engines of each car are different, It needs to be customized in subclasses (of course, you can also inherit the abstractcar class to make a layer of abstraction for all cars that may have the same engine).

Why is the drive () method of driveable implemented by default, but exceptions are thrown directly in the default implementation?

In fact, this is a way to implement the interface. Another way is to set drive () to abstract. I think the two implementation methods are the same in terms of function, but different in terms of class design.

For the implementation in the following code, I refer to Java util. The design of the add (int location, e object) method in abstractlist < E > is described in the document:

public abstract class AbstractCar implements Drivable {
    public abstract Engine getEngine();

    public abstract Wheel getWheel();

    @Override
    public void drive(){
        throw new UnsupportedOperationException();
    }
    // 省略其他方法和属性
}

Drive () in the above code can be understood as:

Take the list in the Java container as an example

Go to the source code and you will find that the top level of the inheritance relationship of list < E > is iteratable, which means that list can be traversed, and it will generate an iterator interface object. This means that a list can be traversed through this iterator.

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

From layer to layer, classes become more specific.

Finally

Why can interfaces inherit?

In fact, the principle is very simple. Because there is always a most essential agreement to restrict everyone. For example, all vehicles can be driven, and all ease can be traversed. Then the agreement will gradually become more specific:

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

From the bottom up, it is more and more abstract.

As I said at the beginning of the article,

Note:

There should be many places where I am not thoughtful. You are welcome to correct and discuss