什么时候应该使用缺省方法的接口，什么时候应该使用 抽象类被使用?

向后兼容性: 想象一下，你的接口是由数百个类实现的，修改这个接口将迫使所有用户实现新添加的方法，即使它对于实现你的接口的许多其他类来说可能不是必需的。另外，它允许你的接口成为一个功能接口

事实与限制:

1-只能在接口中声明，而不能在类或 抽象类。

2 .必须提供一个主体

它不像接口中使用的其他常规方法那样被认为是抽象的。

虽然这是一个老问题，但让我也谈谈我的看法。

abstract class: Inside abstract class we can declare instance variables, which are required to the child class Interface: Inside interface every variables is always public static and final we cannot declare instance variables abstract class: Abstract class can talk about state of object Interface: Interface can never talk about state of object abstract class: Inside Abstract class we can declare constructors Interface: Inside interface we cannot declare constructors as purpose of constructors is to initialize instance variables. So what is the need of constructor there if we cannot have instance variables in interfaces. abstract class: Inside abstract class we can declare instance and static blocks Interface: Interfaces cannot have instance and static blocks. abstract class: Abstract class cannot refer lambda expression Interfaces: Interfaces with single abstract method can refer lambda expression abstract class: Inside abstract class we can override OBJECT CLASS methods Interfaces: We cannot override OBJECT CLASS methods inside interfaces.

最后，我要指出:

Default method concepts/static method concepts in interface came just to save implementation classes but not to provide meaningful useful implementation. Default methods/static methods are kind of dummy implementation, "if you want you can use them or you can override them (in case of default methods) in implementation class" Thus saving us from implementing new methods in implementation classes whenever new methods in interfaces are added. Therefore interfaces can never be equal to abstract classes.

每当我们在抽象类和接口之间做出选择时，我们总是(几乎)选择默认方法(也称为防御器或虚拟扩展)。

Default methods have put an end to classic pattern of interface and a companion class that implements most or all of the methods in that interface. An example is Collection and AbstractCollection. Now we should implement the methods in the interface itself to provide default functionality. The classes which implement the interface has choice to override the methods or inherit the default implementation. Another important use of default methods is interface evolution. Suppose I had a class Ball as: public class Ball implements Collection { ... }

现在在Java 8中引入了一个新特性流。我们可以通过使用添加到接口的stream方法来获取流。如果stream不是默认方法，那么Collection接口的所有实现都将中断，因为它们不会实现这个新方法。向接口添加非默认方法与源不兼容。

但是假设我们不重新编译这个类，而是使用一个包含这个类Ball的旧jar文件。如果没有这个缺失的方法，类将很好地加载，可以创建实例，似乎一切都在正常工作。但是如果程序在Ball实例上调用stream方法，我们将得到AbstractMethodError。因此，使方法默认解决了这两个问题。

Java 9甚至在接口中提供了私有方法，可以用来封装提供默认实现的接口方法中使用的公共代码逻辑。

关于你对…

那么什么时候应该使用默认方法的接口，什么时候应该使用抽象类?抽象类在这种情况下仍然有用吗?

Java文档提供了完美的答案。

抽象类与接口的比较:

Abstract classes are similar to interfaces. You cannot instantiate them, and they may contain a mix of methods declared with or without an implementation. However, with abstract classes, you can declare fields that are not static and final, and define public, protected, and private concrete methods. With interfaces, all fields are automatically public, static, and final, and all methods that you declare or define (as default methods) are public. In addition, you can extend only one class, whether or not it is abstract, whereas you can implement any number of interfaces.

它们各自的用例已经在下面的SE帖子中解释了:

接口和抽象类的区别是什么?

抽象类在这种情况下仍然有用吗?

是的。它们仍然有用。它们可以包含非静态的、非最终的方法和属性(受保护，除了公共之外还有私有)，这即使是Java-8接口也不可能实现。

这两个是完全不同的:

默认方法是在不改变现有类状态的情况下向其添加外部功能。

抽象类是一种普通的继承类型，它们是用于扩展的普通类。

从业务用例上下文中，接口可用于定义特定的业务规则，其中抽象类将定义启动业务的公共结构。

假设某个企业所有者希望与Amazon和Walmart合作，那么这里定义的接口将是WalmartPartner, AmazonPartner将定义特定的业务规则，抽象类BusinessSetup将获得特定区域的业务设置。

// Interfaces
 
public interface WalmartPartner {
    public static boolean signUpForWalmartBusinessAccount(String BusinessId){
        System.out.println("Setting up Walmart Business Partner");
        return true;
    }
    public default  void  getWalmartDeals(){
        System.out.println("Default walmart deal executed !");
    }
    public abstract void setupShopifyForWalmart();
    public abstract  void setupWalmartProducts();

public interface AmazonPartner {
    public static boolean signUpAsAmazonServicePartner(String BusinessId){
        System.out.println("Setting up Amazon Business Partner");
        return true;
    }
    public default  void  paymentPlatformSetup(){
        System.out.println(" Amazon default payment platform is setup");
    }
    public abstract void setupPrimeMemberDealsByRegion();
    public abstract  void setupPrimeDeals();
}

 // Abstract class 

public abstract class BusinessSetup {
    String businessId ;
    public BusinessSetup(String businessId){
        this.businessId = businessId;
        System.out.println("1. Initial Business setup for BusienssID: "+this.businessId+" is Complete");
    }
    public final boolean getBusinessRegisteredInRegion(String region){
        System.out.println("2. Business got registered in "+region+ "!");
        return true;
    }
    public abstract void setupCustomerPlatform(String customerId);
    public abstract void setupVendorPlatform(String vendorId);

}

// Concrete Class 
public class WalMartPartnerImpl extends BusinessSetup implements WalmartPartner {
    public WalMartPartnerImpl(String businessId) {
        super(businessId);
    }
    @Override
    public void setupCustomerPlatform(String customerId) {
    }

    @Override
    public void setupVendorPlatform(String vendorId) {
    }

    @Override
    public void setupShopifyForWalmart() {
    }

    @Override
    public void setupWalmartProducts() {
    }
    public static void main(String args[]){
        WalMartPartnerImpl walMartPartner = new WalMartPartnerImpl("wal8989");
        walMartPartner.getBusinessRegisteredInRegion("california");
        walMartPartner.getWalmartDeals();
        walMartPartner.setupCustomerPlatform("wal8989");

    }
}