Interfaces and abstract classes

The role of Interface interface

Interfaces are abstractions of behavior, and the benefits of interfaces in small projects and small designs may not be particularly noticeable, but once the project is large, the advantages of the interface are obvious:

1, for a large project, from the design point of view, the presence of the interface can help clarify the business, the use of interfaces can not only tell developers need to implement what business, but also the naming specification is limited, so that the developer can not be named so that the project group developers do not understand:

Interface studentoperate{    intboolean deletestudent (intvoidBoolean updatestudent ( int Age , String phone);}       

So define the interface, meaning that this interface must follow this specification, interface what to use, interface inside what functions, beforehand has the manager clear business, just did not realize it. Whether it is an in-project call or a layered call to a distributed system, it is equivalent to specifying a specification according to the specified interface name, interface request, and interface response.

2, make up the Java class single inheritance deficiency, this is very good understanding, the class of multi-implementation:

PublicClass multiclass<e>implements cloneable, Serializable, Iterator<e>private static final Span style= "color: #0000ff;" >long serialversionuid = 1l; public boolean Hasnext {return falsepublic E Next () {return nullpublic void remove () {} } 

Similarly, interfaces can inherit multiple:

Extends Cloneable, Serializable, iterator<e>{    }

Thus, the implementation class is the subclass of all the parent interfaces.

3, reduce the coupling of the code. Because of the Java polymorphic Nature, the interface reference is a subclass object that can be accepted, and can be overridden by an interface by invoking a subclass of the declared interface with the implemented subclass. That is, the place where the interface is called, and the implementation of the interface is irrelevant, adding or removing the interface, do not need to change the calling interface, which greatly reduces the amount of code, increase the extensibility of the code, flexibility, such as when there is no interface when we write:

Class classa{    void print () {}

Class classb{    void print () {}}

Class invoke{    voidvoid print (ClassB cb) {cb.print ();}}

This is very cumbersome after the class is more, the Invoke class will reload more print methods, but the interface is much more convenient:

Interface print{    void Print ();

Implements print{    void Print () {}}

Implements print{    void Print () {}}

Class invoke{    void print (print p) {p.print ();}}

This is much more convenient, regardless of how the subclass of print is added, the call to the local invoke print method does not need to make any changes, this is decoupling, which is the role of the interface. Of course, one might say that inheriting a common class or inheriting an abstract class also has this function, yes, but:

(1) The inherited relationship is too dead, not flexible.

(2) A class can implement multiple interfaces, but can inherit only one class

(3) The interface is a complete abstraction, whether it is inherited from ordinary classes or inherited abstract classes do not achieve this feature

The difference between an interface and an abstract class

1. The concept of interfaces and abstract classes is not the same. An interface is an abstraction of an action that represents what the object can do , such as a person can eat, a dog can eat, as long as there is the same behavior, an abstract class is an abstraction of the root, and the object is something , such as a man, a woman, a man.

2, can implement multiple interfaces, can only inherit an abstract class

3, the interface can only define abstract methods, abstract class can have a common method

4, the interface can only have static data members cannot be changed, abstract class can have ordinary data members

These are the differences between the interface and the abstract class from the point of view of syntax and programming, and the following is an analysis of the differences from the perspective of design concepts. Consider an example of the assumption that there is an abstraction about door in our problem area, that the door has two actions open and close, at which point we can define a type that represents an abstract concept by abstracting class or interface. They are defined in the following ways:

Class door{    void open ();  void close ();}     

Interface door{    void open ();    void Close ();}

Specific door types can inherit the abstract class or implement interface. This looks like there is no big difference between using abstract class and interface. However, if the demand for door now also has the function of alarm, how to design it?

Here's a list of possible solutions, and analyze these different scenarios from the design concept level.

Programme I

Simply add a alarm method to the definition of door:

Class door{void void void     Alarm ();}    

Interface door{    void open ();    voidvoid alarm ();}

Then the Alarmdoor with alarm function is defined as follows:

Extends door{    void open () {...}    voidvoid alarm () {...}}

Implements door{    void open () {...}    voidvoid alarm () {...}}

I have to say that this is a bad plan, because it violates a core principle in object-oriented design ISP, in the definition of door the door concept itself inherent behavior method and another concept "alarm" behavior method mixed together, One problem is that modules that rely solely on the concept of door are changed by the concept of "alarms" (such as modifying the parameters of the alarm method) and vice versa.

Programme II

Since open, close and alarm belong to two different concepts, they should be defined separately in an abstract class that represents both concepts, according to the ISP principle. Definitions are as follows:

1. Both concepts are defined by the abstract class

2. These two concepts are defined by interface

3, a concept with an abstract class definition, a concept with interface definition

Obviously, because Java does not support multiple inheritance, it is not feasible for both concepts to be defined in the abstract class way. Some may say oh, let the door of abstract method a inherit the alarm of abstract method B, class again inherit abstract method a not good. The question is, what if I have another door that has a waterproof function? Can abstract method A also inherit the abstract method of alarm d? So the beginning of the said, the way of inheritance is too dead, what is what. Interface is different, because the class can implement multiple interfaces, so can be any combination.

Finished the first way, then the following two ways. The following two methods are feasible, but the choice of them reflects the understanding of the conceptual nature of the problem domain, and whether the response to the design intent is correct or reasonable.

If both concepts are defined in the interface way, two questions are reflected:

1, we may not understand the problem areas clearly, alarmdoor in the concept is essentially door or alarm?

2. If we have no problem with our understanding of the problem areas, we will not be able to properly disclose our design intent when we do so, because the definitions of these two concepts do not reflect the above meanings.

If our understanding of the problem area is that Alarmdoor is inherently door and it has an alarm function, how do we design and implement it to clearly reflect our intentions? As already mentioned, abstract class represents an inheritance relationship in the Java language, whereas an inheritance relationship is essentially a "is a" relationship. So for the concept of door, we should use the abstract class approach to define it. In addition, Alarmdoor also has the alarm function, indicating that it can complete the definition of the alarm concept, so the alarm concept can be defined by the interface way. As follows:

Class door{    voidvoid close ();}

Interface alarm{    void Alarm ();}

Implements alarm{void void void     Alarm () {...}}

This implementation basically clearly reflects our understanding of the problem area and correctly explains our design intent: Alaramdoor is door and it has alarm functions. Of course, this is based on the understanding of the problem areas, such as: if we think alarmdoor in the concept is essentially an alarm (for example, in addition to Alarmdoor, there are Alarmchair, Alaramdesk, alarmbike, etc.), At the same time has the function of door, then the definition of the above will be reversed.

Interfaces and abstract classes