C # differences between interfaces and abstract classes-object-oriented concepts

I. abstract class:
Abstract classes are special classes, but they cannot be instantiated. In addition, they have other characteristics of the class. It is important that abstract classes can include abstract methods, which are not supported by common classes. Abstract METHODS can only be declared in abstract classes and do not contain any implementations. The Derived classes must overwrite them. In addition, an abstract class can be derived from an abstract class. It can overwrite the abstract methods of the base class or overwrite them. If not, its derived class must overwrite them.

Ii. interface:
The interface is of reference type. It is similar to a class and has three similarities with the abstract class:
1. It cannot be instantiated;
2. contains an unimplemented method statement;
3. The derived class must implement unimplemented methods. The abstract class is an abstract method, and the interface is all members (not only the methods include other members );

In addition, interfaces have the following features:
In addition to methods, interfaces can also contain attributes, indexers, and events, and these members are defined as common. It cannot contain any other Members, such as constants, fields, constructors, destructor, and static members. A class can directly inherit multiple interfaces, but can only inherit one class (including abstract classes ).

Iii. Differences between abstract classes and interfaces:
1. class is the abstraction of objects. abstract classes can be understood as classes as objects. abstract classes are called abstract classes. the interface is just a behavior specification or provision. Microsoft's custom interface always carries the able field behind it to prove that it represents a class "I can do it... ". Abstract classes are more defined in a series of closely related classes, while interfaces are mostly classes with loose relationships but all implement certain functions.
2. The interface basically does not have any specific characteristics of inheritance. It only promises the methods that can be called;
3. A class can implement several interfaces at a time, but only one parent class can be extended.
4. interfaces can be used to support callback, but inheritance does not.
5. the abstract class cannot be sealed.
6. The specific methods implemented by abstract classes are virtual by default, but the interface methods in the class implementing interfaces are non-virtual by default. Of course, you can also declare them as virtual.
7. Similar to a non-abstract class, an abstract class must provide its own implementation for all the members of the interface listed in the base class list of this class. However, the abstract class is allowed to map interface methods to abstract methods.
8. abstract classes implement a principle in OOP that separates mutable from immutable. Abstract classes and interfaces are defined as immutable classes, while variable class classes are implemented.
9. A good interface definition should be specific and functional, rather than multi-functional, otherwise it will cause interface pollution. If a class only implements a function of this interface and has to implement other methods in the interface, it is called interface pollution.
10. Avoid using inheritance to implement the build function, but use black box multiplexing, that is, object combination. As the hierarchy of inheritance increases, the most direct consequence is that when you call a class in this group, you must load all of them into the stack! The consequences can be imagined (based on the stack principle ). At the same time, some interested friends can note that Microsoft often uses the object combination method when building a class. For example, in Asp.net, the page class has server request and other attributes, but in fact they are all objects of a certain class. This object of the page class is used to call the methods and attributes of other classes. This is a very basic design principle.
11. If an abstract class implements an interface, you can map the methods in the interface to the abstract class as an abstract method without having to implement it. Instead, you can implement the methods in the subclass of the abstract class.

Iv. Use of abstract classes and interfaces:
1. If you want to create multiple versions of a component, create an abstract class. Abstract classes provide simple methods to control component versions.
2. If the created function is used across a wide range of different objects, the interface is used. If you want to design small and concise functional blocks, use interfaces.
3. If you want to design a large functional unit, use the abstract class. If you want to provide general implemented functions among all the implementations of the component, use the abstract class.
4. abstract classes are mainly used for closely related objects. interfaces are suitable for providing general functions for irrelevant classes.

The following are some of the Image metaphors I have seen on the Internet. They are really good:
1. Planes fly and birds fly. They all inherit the same interface "fly". However, f22 belongs to the aircraft abstract class and pigeon belongs to the bird abstract class. (Too incisive ..)
2. just like all doors (abstract class), I can't give you a door (I can't instantiate it), but I can give you a specific door or wooden door (polymorphism ); it can only be a door. You cannot say it is a window (single inheritance); a door can have a lock (Interface) or a doorbell (multiple implementations ). A door (abstract class) defines what you are and an interface (LOCK) specifies what you can do (one interface is best to do only one thing, you cannot require the lock to make sound (interface pollution )).
Let's look at an example:
Suppose there is an abstract concept about the door in our problem field. The door has two actions: open and close, in this case, abstract class or interface can be used to define a type that represents the abstract concept. The definitions are as follows:

Use abstract class to define door:

Abstract class door {

Abstract void open ();

Abstract void close ();

}

Use the interface method to define the door:

Interface door {

Void open ();

Void close ();

}

For other specific door types, extends can use the door defined in abstract class or implements to use the door defined in interface mode. It seems that there is no big difference between abstract class and interface.

If you want the door to have the alarm function. How can we design the class structure for this example (in this example, we mainly want to demonstrate the differences between abstract class and interface in the design concept, other irrelevant issues are simplified or ignored.) The following describes possible solutions and analyzes these solutions at the design concept layer.

Solution 1:

Add an alarm method to the door definition as follows:

Abstract class door {

Abstract void open ();

Abstract void close ();

Abstract void alarm ();

}

Or

Interface door {

Void open ();

Void close ();

Void alarm ();

}

The alarmdoor with alarm function is defined as follows:

Class alarmdoor extends door {

Void open (){... }

Void close (){... }

Void alarm (){... }

}

Or

Class alarmdoor implements door {

Void open (){... }

Void close (){... }

Void alarm (){... }

}

This method violates a core principle in object-oriented design, ISP (interface segregation priciple ), in the definition of door, the inherent behavior methods of the door concept are mixed with the behavior methods of another concept "alarm. One problem is that the modules that rely solely on the door concept will change due to changes in the concept of "alarm" (for example, modifying the parameters of the alarm method.

Solution 2:

Since open, close, and alarm belong to two different concepts, they should be defined in abstract classes that represent these two concepts according to the ISP principle. The two concepts are defined by abstract class. Both concepts are defined by interface. One is defined by abstract class, and the other is defined by interface.

Obviously, because the Java language does not support multiple inheritance, both concepts are defined using abstract class. The latter two methods are feasible, but their selection reflects the understanding of the concept nature in the problem field, and whether the reflection of the design intent is correct and reasonable. Let's analyze and explain them one by one.

If both concepts are defined using the interface method, two problems are identified:

1. We may not understand the problem. Is alarmdoor actually a door or an alarm?

2. If we have no problem in understanding the problem field, for example, we have found that alarmdoor is essentially consistent with door through analysis of the problem field, therefore, our design intent cannot be correctly revealed during implementation, because the definitions of these two concepts (both using the interface method definition) do not reflect the above meaning.

If our understanding of the problem field is: alarmdoor is essentially a door in concept, it also has the alarm function. How can we design and implement it to clearly reflect what we mean? As mentioned above, abstract class represents an inheritance relation in Java, and the inheritance relation is essentially a "is a" relation. So we should use the Abstarct class method to define the concept of door. In addition, alarmdoor has the alarm function, indicating that it can complete the behaviors defined in the alarm concept. Therefore, the alarm concept can be defined through interface. As follows:

Abstract class door {

Abstract void open ();

Abstract void close ();

}

Interface alarm {

Void alarm ();

}

Class alarmdoor extends door implements alarm {

Void open (){... }

Void close (){... }

Void alarm (){... }

}

This implementation method can clearly reflect our understanding of the problem field and correctly reveal our design intent. Abstract class represents the "is a" relation, and interface represents the "like a" relation. You can use it as a basis for your selection, of course, this is based on the understanding of the problem field. For example, if we think that alarmdoor is essentially an alarm and has the door function, then the above definition method will be reversed.

Abstract class and interface are two methods of defining abstract classes in Java. They have great similarity. However, their choices often reflect the understanding of the concept nature in the problem field, and whether the reflection of the design intent is correct and reasonable, because they represent different relationships between concepts (although they all implement the required functions ). This is actually a common use of language. I hope readers can understand it in detail.