First, we declare that this article is based on
Http://dev.yesky.com/436/7581936.shtml
Add the points obtained from other materials.
1. Logically speaking, abstract classes describe the essence of a series of "things.
Interfaces describe the functions that a series of "things" should have, or interfaces are a set of contracts.
In the idea of OOP, any kind in the world can pair a class with it from the ideological perspective, but in turn, not all classes in thinking can find a physical pairing in the real world. (The class mentioned here is also a logical concept, including common classes and abstract class interfaces)
For example, we design a drawing software, where there are various logical concepts such as square triangle, straight line curve, solid line dotted line, and red and blue. Now we only discuss the square triangle domain. By thinking about this domain, we can design a "shape" concept, we can drag a triangle and a square from the sidebar of the drawing software, but we cannot drag a "Current Situation "! Because the concept of "shape" does not exist in our problem domain, it is abstracted. Since it is abstract, it cannot be instantiated!
2. abstract class demo {
Abstract void METH1 ();
Abstract void meth2 ();
}
Interface demo2 {
Void METH1 ();
Void meth2 ();
}
The most basic definition is as follows.
A class can inherit only one class, but can implement many interfaces (how many? It seems that 65535 is enough for us)
Attribute first. abstract classes can have their own data members. The interface can also have data members, but all of them are static final type. In addition, although the interface can have attributes from the syntax perspective, in reality, we do not define attributes in the interface.
Besides, all methods in the interface are abstract (the method body is not allowed), and the default value is public. Methods in abstract classes can have a method body or a method body (Abstract must be specified if there is no method body)
Abstract METHODS in abstract classes (which have abstract modifiers before them) cannot be modified using private, static, synchronized, or native access modifiers. The reason is as follows: abstract methods have no method bodies and are used for inheritance. Therefore, they cannot be modified using private; the static modifier method can access this method through the class name (that is, the method body of this method). The abstract method does not make sense to use static modifier. the synchronized keyword is used to add a lock for this method .. If the keyword is modified using the static method. The lock used is the lock of the class variable. If it is a modifier class method. Use the this variable lock. However, an abstract class cannot instantiate an object because this method is not implemented in this abstract class. Is implemented in its subclass. So. The lock should belong to its subclass. So. The abstract method cannot be modified with the synchronized keyword. Native, this thing is in conflict with the abstract. They are both method declarations, but a method implementation is handed over to the subclass, the other is handed over to the local operating system. If it appears at the same time, it is equivalent to transferring the implementation to the subclass and the implementation to the local operating system. Who will implement the specific method?
Previous reference
Http://blog.sina.com.cn/s/blog_7ffb8dd5010111yu.html
3. At the design level, let's recall the above points.
Abstract classes describe the essence of a series of "things.
Interfaces describe the functions that a series of "things" should have, or interfaces are a set of contracts.
Now we have designed a door, which has the Open and Close functions. We can use abstract classes or interfaces.
What if we have designed another door with the alarm function?
Method 1
We add an alarm method (only one concept) to the original abstract class/interface)
The problem arises. Logically speaking, we have been repeating the essence of a series of things described in abstract classes. Is alarm the essence of the door? It should not be. In addition, from the software perspective, we do have some classes that rely solely on the door class. Now we have added the alarm feature to the door, then the classes that originally only rely on the door open and close have to be modified.
Method 2
The door and alarm are designed into two concepts:
Both door 1 and alarm are abstract classes
Multi-inheritance is not allowed in Java.
Both the two door and the alarm are interfaces.
So what is the logic of Monroe with an alarm? Is it a door or an interface?
The Syntactic Analysis of the "door with an alarm" shows that "door with alarm" is an attribute of "Door" which can be modified. The essence of the door with an alarm is the door. Therefore, we have a 3rd idea.
The third door is an abstract class, and the alarm is an interface.
Obviously, the door is an abstract class, and the alarm is an interface which we need.
All in all, there is no right or wrong thing at the design level. There is only the right or not. In the above problems, if we think that the door with an alarm is essentially a function of both the alarm and the door, then let's design the program into a store interface, and the alarm is an abstract class!
In other words, class inheritance refers to the relationship between "a Ia B" and class implementation refers to the relationship between "A is like B" (a is like B!
Interface and abstract class
