Java interfaces and abstract class differences

1. Overview
A software design is good or bad, I think to a large extent, it depends on its overall structure, and this whole structure is your abstract framework of the entire macro-business business, when the high-level abstraction layer representing business logic is reasonable, your underlying implementation needs to consider only some algorithms and some specific business implementation. When you need to develop another similar project, your previous abstraction layer might be able to use it again. In the face of object design, the emphasis of reuse should be the reuse of abstraction layer, rather than the reuse of a specific code block.

When it comes to abstraction, I can't help but mention the Java interface and Java abstraction classes that have made me headache, which is what I want to say in this article.

Since object-oriented design focuses on abstraction, the Java interface and Java abstract classes have the inevitability of its existence.

The Java Interface (interface) and the Java abstract class represent abstract types, which are the concrete manifestations of the abstraction layer we need to propose. OOP object-oriented programming, if you want to increase the reuse rate of programs, increase the maintainability of the program, extensibility, it must be interface-oriented programming, for abstract programming, the correct use of interfaces, abstract classes, these useful abstract types as the top layer of your hierarchy.

There are so many similarities between Java interfaces and Java abstract classes, and there are so many special places, where exactly is the best place for them? Compare them and you'll find out.

One of the biggest differences between Java interfaces and Java abstract classes is that Java abstract classes can provide partial implementations of some methods, while Java interfaces cannot (that is, only methods can be defined in the interface, but not the implementation of methods, but in the abstract Class can have both the specific implementation of the method, and there is no concrete implementation of the abstract method, which is probably the only advantage of Java abstract class, but this advantage is very useful. If you add a new concrete method to an abstract class, all of its subclasses get the new method all of a sudden, and the Java interface does not do this, and if a new method is added to a Java interface, all classes that implement the interface will fail to compile successfully. Because you have to let every class implement this method again, this is obviously a disadvantage of the Java interface. This is a similar issue in one of my other blog MapReduce new and old API differences, where the new MapReduce API tends to use abstract classes rather than interfaces because it's easier to extend. The reason is that the underlined part says.
The implementation of an abstract class can only be given by subclasses of this abstract class, that is, the implementation is in the hierarchy of inheritance defined by the abstract class, and because of the single inheritance of the Java language, the efficiency of the abstract class as a type definition tool is greatly compromised. At this point, the advantages of the Java interface come out that any class that implements a method specified by a Java interface can have the type of this interface, and a class can implement any number of Java interfaces, so there are many types of this class. (with abstract classes, the subclass type that inherits this abstract class is relatively single, because subclasses can only inherit abstract classes, whereas subclasses can implement multiple interfaces at the same time because the types are more numerous.) Interfaces and abstract classes can define objects, but only their specific implementation classes are instantiated. ）
From the 2nd, it is not difficult to see that Java interfaces are an ideal tool for defining mixed types, and mixed classes indicate that a class does not only have the behavior of one of the main types, but also has other minor behaviors.
Combining the advantages of abstract class and Java interface in 1, 2 points, the design pattern of the refined code comes out: the work of declaring type is still assumed by the Java interface, but at the same time it gives a Java abstract class, and implements this interface, and other specific classes belonging to this abstract type can choose to implement this Java interface , you can also choose to inherit this abstract class, that is, in the hierarchy, the Java interface at the top, followed by the abstract class, the next two of the greatest advantage can be played to the extreme. This mode is "default adaptation mode". This pattern is used in the Java language API, and all follow a certain naming convention: Abstract + interface name. (A extends ABSTRACTB implements INTERFACEC, then a can choose to implement (@Override) interface Interfacec in the method, you can choose not to implement; a you can choose to implement (@Override) Abstract class Abstractb method, can also choose not to implement)
Java interfaces and Java abstract classes exist to be used for the implementation and inheritance of specific classes, and if you are going to write a specific class to inherit another specific class, then your design has a big problem. The Java abstract class exists for inheritance, and its abstract approach is to force subclasses to be implemented.

Use Java interfaces and abstract Java classes for variable type declarations, arguments for type declarations, method return type descriptions, and conversion of data types. Instead of using specific Java classes to declare variable types, arguments are type declarations, method return type descriptions, and data type conversions.
2. Example
Here is a specific interface action, as shown in the code below:

[Java] View plaincopy
Package org.springframework.webflow.execution;
Public interface Action {

public Event execute(RequestContext context) throws Exception;  

}
In this interface, a method with no concrete implementation is defined, the method name is execute (), and the return type is event. As mentioned in the first article above, the methods in the interface are not implemented. The implementation of these methods is given in the class that implements (implements) this interface.
Let's look at an abstract class abstractaction that implements the action interface, as shown in the code below.

[Java] View plaincopy
Package org.springframework.webflow.action;

Import Org.apache.commons.logging.Log;
Import Org.apache.commons.logging.LogFactory;
Import org.springframework.beans.factory.BeanInitializationException;
Import Org.springframework.beans.factory.InitializingBean;
Import Org.springframework.util.ClassUtils;
Import Org.springframework.webflow.core.collection.AttributeMap;
Import org.springframework.webflow.execution.Action;
Import org.springframework.webflow.execution.Event;
Import Org.springframework.webflow.execution.RequestContext;

Public abstract class AbstractAction implements Action, Initializingbean {

Protected final Log logger = Logfactory.getlog (GetClass ());  Public Eventfactorysupport Geteventfactorysupport () {return new Eventfactorysupport ();      } public void Afterpropertiesset () throws Exception {try {initaction (); } catch (Exception ex) {throw new Beaninitializationexception ("Initialization of this Action failed:" + Ex.getm      Essage (), ex); }} protected void Initaction () throws Exception {} protected Event success () {return Geteventfactorysupport ().  Success (this);  } Protected Event Success (Object result) {return Geteventfactorysupport (). Success (this, result);  } protected Event error () {return geteventfactorysupport (). Error (this);  } protected Event Error (Exception e) {return geteventfactorysupport (). Error (this, e);  } protected Event Yes () {return Geteventfactorysupport (). Yes (this);  } protected Event No () {return Geteventfactorysupport (). No (this); } Protected Event Result (Boolean BOOLEANREsult) {return Geteventfactorysupport (). Event (this, booleanresult);  } protected Event result (String eventId) {return Geteventfactorysupport (). Event (this, eventId); } protected Event result (String eventId, AttributeMap resultattributes) {return Geteventfactorysupport (). Event (This  , EventId, resultattributes); } protected Event Result (string eventId, String resultattributename, Object resultattributevalue) {return geteventf  Actorysupport (). Event (this, EventId, Resultattributename, Resultattributevalue);      Public final Event Execute (requestcontext context) throws Exception {Event result = Dopreexecute (context);          if (result = = null) {result = Doexecute (context);      Dopostexecute (context); } else {if (logger.isinfoenabled ()) {logger.info ("Action execution disallowed;          Pre-execution result is ' "+ result.getid () +" ' ");  }} return result;    } protected String getactionnameforlogging () {  Return Classutils.getshortname (GetClass ());  } protected Event Dopreexecute (RequestContext context) throws Exception {return null;  }//abstract method protected abstract Event Doexecute (RequestContext context) throws Exception;   protected void Dopostexecute (RequestContext context) throws Exception {}

}
In abstract class AbstractAction, there are methods of concrete implementation, and there is no concrete implementation of abstract methods
[Java] View plaincopy
Abstract methods
Protected abstract Event Doexecute (RequestContext context) throws Exception;
It is important to note that in an abstract class, if the method does not have a concrete implementation (that is, there is no {} after the method), you must add an abstract to declare the method, and the interface does not need to use abstract to declare (the abstract class is called an abstract class because it contains an abstract method.) Classes that contain abstract methods are called abstract classes.

Java interfaces and abstract class differences