The enmity between interface and abstract class

Interfaces and abstract classes are two very important roles in object-oriented programming, each of which plays a very important role. But many novice friends often have a great deal of confusion about using interfaces or abstract classes. On my own little experience, to publish a humble opinion. Some of the object-oriented reviews:
There is an ancient rule in the object-oriented World: the principle of interface isolation, which is to not centralize multiple functions in one interface. Interface implementation of a relatively simple function, derived from the other can be a conclusion: the implementation of a group or a series of functions, as far as possible to define a single relatively small module to achieve this set of functions. This is actually decoupling and the embodiment.
So what does this have to do with our interfaces and abstract classes? That's another rule: rely on the inverted principle, programming for interfaces rather than implementation.
Speaking of which, there will be a new problem to pop out, this is a paradox, since to programming for the interface and how to abstract class why? We often say that object-oriented, object-oriented is derived from life.  Is that people want to apply a series of methodologies in the real world to program design. We can try to figure this out from the introduction of the concept of object. There are many objects in human society, people, cars, objects. Unfortunately, using programs to implement these objects is a lot harder than defining objects conceptually.
(If you can reach this consensus, you can continue to look down, otherwise please reader you move to the message discussion bar)
Ms's advice to developers is to use abstract classes to implement interfaces. The subclass inherits the base class again.
Example Description:
Why do you suggest that? OK, let's try to explain the problem with reality. We're going to build a car. The car has a basic attribute of being able to move and have to have wheels. So we're going to design an interface.
1public Interface ICar
2 {
3 String Wheel
4 {
5 get;
6 set;
7}
8 void Move ();
9}
10

The next thing is to achieve it. You can make any car, just inherit it. With the development of science and technology, our car wants to fly. At this point, of course, can not modify this interface, because to follow the opening and closing principle. Why to follow? We can think about it, people on the plane can fly to the sky. But I don't see anyone who thinks they can fly this feature. That's fine, don't change it, I'll add an interface.

1interface iflyable
2 {
3 void Fly ();
4}
5 Good, our flying car should end up like this.
1class Flycar:icar,iaerocraft
2 {
3 private String wheel = string. Empty;
4
5 public void Fly ()
6 {
7 Console.WriteLine ("{0} vehicle flew up", This.wheel);
8}
9 public string Engine
10 {
One get
12 {
return wheel;
14}
Set
16 {
Wheel = value;
18}
19}
20
public void Move ()
22 {
Console.WriteLine ("{0} wheeled vehicles in the Walk", This.wheel);
24}
25}
26 looks very good, the car can fly to go. So is it his ancestor now or the vehicle? Let us debate ourselves in our hearts. It is not easy to argue clearly.
As we said before, object-oriented thinking comes from real life. If you introduce this group of examples into the real world, build a flying car. Be sure to work on the original car. Like you put on a jet device, or you put wings on it. This is only an extension function, not an inherited base class. But the above example shows clearly that our flying car has become a hybrid breed. Can't tell whether it's a car or a flying machine. Here you can see why both C # and Java do not support multiple inheritance base classes. Avoid hybridization and reduce coupling.
It's not perfect to define a car as an interface, and we know that a normal car can definitely move. This is innate nature and does not require any realization. But it also requires subclasses to implement this functionality. In fact, many problems can be derived from this point. We don't do much discussion here.
Redesign the system. We can think of moving and flying as an act. Our car itself has the act of move, which is the basic element that makes up the vehicle base class.

1interface imoveable
2 {
3 void Move ();
4}
5 Interface Iflyable
6 {
7 void Fly ();
8}
9public Abstract class Car:imoveable
10 {
One public abstract string Wheel
12 {
The Get;
Set;
15}
Public virtual void Move ()
17 {
Console.WriteLine ("Car Moved");
19}
20}
public sealed class Flycar:car,iflyable
22 {
The private string wheel = string. Empty;
public override string Wheel
25 {
Num get
27 {
return wheel;
29}
Set
31 {
Wheel = value;
33}
34}
35
The public void Fly ()
37 {
Base. Move ();
Console.WriteLine ("Car Take-off success!");
40}
41}
42//It's easy to apply any mode here.
static void Main (string[] args)
44 {
Flycar C = new Flycar ();
((iflyable) c). Fly ();
(car) c. Move ();
48}
49

Summary: In fact, similar examples are ubiquitous in our. NET library, for example, the control class inherits from component and many other interfaces, and their base class is MarshalByRefObject. Because they are attributed to the end and belong to the Reference object.

From the above description, we can draw the conclusion that:
Interface: An abstraction of a type of behavior or function. It's a switch or a contract. So it is very clear from the literal understanding that there are many stories in western mythology that make a pact with the devil to elevate one's power. You have to set the contract to get the strength you want.
Abstract class: The highest abstraction of a specific object, which has its own most basic characteristics.
So, as a whole, abstract classes and interfaces are essentially the highest abstractions of the system. In fact, the abstract objects are different, which leads to the difference in their application.