- What are the differences between abstract classes and interfaces?
- What problems do abstract classes solve in object-oriented programming?
- What problems do interfaces solve in object-oriented programming?
- How do YOU decide whether to use abstract classes or interfaces?
- What if your language does not support abstract classes and interfaces?
An abstract class
Support for abstract classes and interfaces has been added to most object-oriented programming languages, such as Java, C#, and so on.
Public abstract class Human {// Gender(); // attribute public string Name {get; set; } // method public int GetAge() {return 1; }}Copy the code
The above is a general abstract class definition, specific how to use, Baidu has a lot of results, in fact, in general abstract class mainly has the following characteristics:
- Abstract classes cannot be instantiated, only inherited. That is, if New Human () returns a compile error
- Abstract classes are also classes and can contain properties and methods. Methods can contain implementations or not. Methods without implementations are called abstract methods.
- Subclasses inherit abstract classes and must implement all of the abstract methods defined, otherwise the compiler will report a compilation error.
Abstract classes or class, essentially is just a kind of special class cannot be instantiated, but in the process of object-oriented design plays a very important position, abstract class essentially reflects the is – a relationship, like the abstract classes defined above, the Human type of abstract is Human, if I define a dish dish type to inherit this type
Public class CaiCai: Human {public string Gender() {return "male "; }}Copy the code
The CaiCai class must provide an implementation of abstract methods to compile. Abstract class is an extension of the idea of object-oriented development, a solution to the problem of code reuse, but also a result of code abstraction. The idea of abstract class design is bottom-up, that is, the design should have subclasses first, as the subclasses gradually increase, and then abstract out of common features to produce abstract classes.
At this point, a lot of students will ask, if I don’t have an abstract class as a parent, I can do it. Yes, ordinary classes can certainly take the place of abstract classes. But there are a few things that seem odd
- The parent class can also be instantiated, but the methods to be abstracted from are a bit odder because they are defined only in subclasses. For example, what should Gender () return if Human is changed to a normal type?
- At compile time, if a subclass does not implement a method of the parent class, it will not report an error, which makes troubleshooting more difficult. If you need to rewrite a lot of methods, troubleshooting will be very difficult later
- If an abstract superclass can be instantiated, this essentially violates the idea of object orientation. After all, a superclass is an abstract concept. What does it represent when instantiated
interface
Interface in system design, the most important role is decoupling. You’ve heard the term “interface oriented programming” and dependency inversion more than once, and it’s part of object-oriented design. An interface is essentially the behavior, or contract, of an abstract object. In interface oriented development, callers do not care about the implementation of the interface, but rely on the definition of the interface, the stability of the definition of the interface represents the stability of a system, if a system external interface definition problems, that the system is mostly dead.
Public interface IHuman {// Interface behavior defines void Walk(); }Copy the code
The above is just a simple definition of interface, interface abstraction can be as small as an object behavior abstraction, as large as a service behavior abstraction, more likely is a system behavior abstraction, so interface is a very general concept, but in essence, or reflects the object-oriented design concept. Since an interface is the definition of behavior, it has the following characteristics
- An interface can only define the behavior, and cannot contain the implementation of the behavior
- When a type inherits an interface, it must implement all the behavior of the interface
- Interfaces, unlike classes, cannot contain attributes
Because the interface embodies the code of behavior, it can also use the object-oriented design concept when defining the interface. When multiple different interfaces define the same behavior, it can be considered to abstract the higher-level interface to realize the reuse of behavior.
Write in the last
Abstract classes and interfaces are both generated by the abstract behavior of objects, but the abstract class is more focused on the IS-A relationship, which implements code reuse, while the interface is more focused on the behavior of abstraction (HAS-A). For example, if you design a bird abstraction, how to do? Different birds may have different feather colors. Properties like this can use abstract classes. Different birds may have different flight behaviors.
No matter interface or abstract class, the code level reflects the relationship between the supervisor and the subordinate. Even if a programming language does not provide the definition of interface and abstract class, as long as the relationship between the supervisor and the subordinate can be realized, object-oriented programming can be realized in principle. The abstract thought of programming is always around the top and bottom, inside and outside these dimensions in the rational evolution.
In some languages that do not support interfaces, it makes sense to think of a class that contains only methods as an abstract definition of an interface.
In terms of inheritance level and design process, abstract class is a bottom-up design idea. There are subclasses of code first, and then more and more subclasses will be abstracted from the upper parent class. Interface programming, on the other hand, is a top-down design approach, abstracting the behavior contract first and then implementing it.
More interesting articles
- Distributed large concurrent series
- Architectural Design Series
- Series of interesting algorithms and data structures
- Design Pattern series