interfaces vs abstract classes

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/wangbingfengf98/article/details/85378303

There are a number of situations in software engineering when it is important for disparate groups of programmers to agree to a "contract" that spells out how their software interacts. Each group should be able to write their code without any knowledge of how the other group's code is written. Generally speaking, interfaces are such contracts.

An abstract class is a class that is declared abstract—it may or may not include abstract methods. Abstract classes cannot be instantiated, but they can be subclassed.

When an abstract class is subclassed, the subclass usually provides implementations for all of the abstract methods in its parent class. However, if it does not, then the subclass must also be declared abstract.

Note: Methods in an interface (see the Interfaces section) that are not declared as default or static are implicitly abstract, so the abstract modifier is not used with interface methods. (It can be used, but it is unnecessary.)

Perhaps the most notable difference between an interface and an abstract class is the idiomatic ways the two are used. An interface typically suggests a “type of class” or an adjective, like Runnable , or Serializable , whereas an abstract class is usually part of your class hierarchy and is a “type of thing,” like String or ActionHero.
 

Java 8 interfaces vs abstract classes distinction table:

Feautre	Interfaces	Abstract Classes
Combinations	Can combine Multiple interfaces in a new class.	Can only inherit from a single abstract class.
State	Cannot contain fields (except static fields, which do not support object state).	Can contain fields. Non-abstract methods may refer to these fields.
default methods & abstract methods	default methods need not be implemented in subtypes. default methods can only refer to other interface methods (not fields).	abstract methods must be implemented in subtypes.
Constructor	Cannot have a constructor.	Can have a constructor.
Visibility	Implicitly public.	Can be protected or "friendly."

---

A rule of thumb is to "be as abstract as possible ——within reason." Thus, prefer interfaces over abstract classes. You'll know when you must use an abstract class. And don't use either one unless you must. Most of the time, a regular class will do the trick, and when it doesn't, you can move to an interface or abstract class.

Which should you use, abstract classes or interfaces?

• Consider using abstract classes if any of these statements apply to your situation:

1. You want to share code among several closely related classes.
2. You expect that classes that extend your abstract class have many common methods or fields, or require access modifiers other than public (such as protected and private).
3. You want to declare non-static or non-final fields. This enables you to define methods that can access and modify the state of the object to which they belong.

• Consider using interfaces if any of these statements apply to your situation:

1. You expect that unrelated classes would implement your interface. For example, the interfaces Comparable and Cloneable are implemented by many unrelated classes.
2. You want to specify the behavior of a particular data type, but not concerned about who implements its behavior.
3. You want to take advantage of multiple inheritance of type.

references:

1. On Java 8 - Bruce Eckel

2. https://docs.oracle.com/javase/tutorial/java/IandI/abstract.html