Java 8:虚拟扩展方法与抽象类

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/18198517/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-11 23:13:32  来源:igfitidea点击:

Java 8: virtual extension methods vs abstract class

javainterfacejava-8abstract-class

提问by Kong

I'm looking at the new virtual extension methods in Java 8 interfaces:

我正在查看 Java 8 接口中新的虚拟扩展方法:

public interface MyInterface {
   default String myMethod() { 
      return "myImplementation"; 
   }
}

I get their purpose in allowing an interface to evolve over time, and the multiple inheritance bit, but they look awfully like an abstract class to me.

我明白他们的目的是允许接口随着时间的推移而发展,还有多重继承位,但对我来说它们看起来非常像一个抽象类。

If you're doing new work are abstract classes prefered over extension methods to provide implementation to an "interface" or are these two approaches conceptually equivalent?

如果您正在做新工作,抽象类比扩展方法更受欢迎,以提供“接口”的实现,或者这两种方法在概念上是否等效?

采纳答案by arshajii

One primary purpose of such constructs is to preserve backwards compatibility. The addition of closures to the Java language is quite a major alteration, and things need to be updated to fully take advantage of this. For example, Collectionin Java 8 will have methods such as forEach()which work in conjunction with lambdas. Simply adding such methods to the pre-existing Collectioninterface would not be feasible, since it would break backwards compatibility. A class I wrote in Java 7 implementing Collectionwould no longer compile since it would lack these methods. Consequently, these methods are introduced with a "default" implementation. If you know Scala, you can see that Java interfaces are becoming more like Scala traits.

这种构造的一个主要目的是保持向后兼容性。向 Java 语言添加闭包是一个相当大的改变,需要更新一些东西以充分利用这一点。例如,Collection在 Java 8 中将有诸如forEach()which 与 lambdas 结合使用的方法。简单地将这些方法添加到预先存在的Collection接口中是不可行的,因为它会破坏向后兼容性。我在 Java 7 中编写的类实现Collection将不再编译,因为它缺少这些方法。因此,这些方法是通过“默认”实现引入的。如果您了解 Scala,就会发现 Javainterface越来越像 Scala trait

As for interfaces vs abstract classes, the two are still differentin Java 8; you still can't have a constructor in an interface, for example. Hence, the two approaches are not "conceptually equivalent" per se. Abstract classes are more structured and can have a state associated with them, whereas interfaces can not. You should use whichever makes more sense in the context of your program, just like you would do in Java 7 and below.

至于接口和抽象类,两者在 Java 8中还是有区别的;例如,您仍然不能在接口中有构造函数。因此,这两种方法本身并不是“概念上等价的”。抽象类更结构化,可以有一个与其相关联的状态,而接口则不能。您应该使用在您的程序上下文中更有意义的那个,就像您在 Java 7 及更低版本中所做的那样。

回答by aepurniet

  1. Abstract classescannot be root classes of lambda expressions, while interfaceswith virtual extension methods can be.
  2. Abstract classescan have constructors and member variables, while interfaces cannot. I believe its the execution of a possible constructor, and the possible throwing of a checked exception that prohibits abstract classes from being the root of a lambda expression.
  1. 抽象类不能是 lambda 表达式的根类,而具有虚拟扩展方法的接口可以。
  2. 抽象类可以有构造函数和成员变量,而接口不能。我相信它是一个可能的构造函数的执行,并且可能抛出一个检查异常,禁止抽象类成为 lambda 表达式的根。

If you want to write an API that allows the user to use lambda expressions, you should use interfaces instead.

如果要编写允许用户使用 lambda 表达式的 API,则应改用接口。

回答by user541686

Abstract classes hold state(instance fields), in order to provide some common behavior (methods).
You don't typically (ever?) see an abstract class without state.

抽象类持有状态(实例字段),以提供一些常见的行为(方法)。
您通常(永远?)看不到没有状态的抽象类。

Interfaces specify functionality. They are meant to declare behavior as a contract, not implement it.
Thus any methods that are specified as part of an interface are "helper" methods -- they don't affect the implementation.

接口指定功能。它们旨在将行为声明为契约,而不是实现它。
因此,任何被指定为接口一部分的方法都是“辅助”方法——它们不会影响实现。

回答by Ravindra babu

Abstract classesscores over java-8interfaces in below areas.

抽象类java-8在以下领域的接口上得分。

  1. 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

  2. Mutable statecan be shared/modified with child classes unlike interface which have only constants

  3. Abstract class can be used to implement Template_method_pattern: It defines the program skeleton of an algorithm in an operation, deferring some steps to sub-classes.
  4. Abstract class can be used to implement Decorator_pattern: A design pattern that allows behaviuor to be added to an individual object, either statically or dynamically, without affecting the behaviour of other objects from the same class.
  1. 使用抽象类,您可以声明非静态和最终的字段,并定义公共、受保护和私有的具体方法使用接口,所有字段自动为 public、static 和 final,并且您声明或定义的所有方法(作为默认方法)都是 public

  2. 与只有常量的接口不同,可变状态可以与子类共享/修改

  3. 抽象类可用于实现Template_method_pattern:它定义了一个操作中算法的程序框架,将一些步骤推迟到子类中。
  4. 抽象类可用于实现Decorator_pattern:一种设计模式,允许静态或动态地将行为添加到单个对象,而不会影响来自同一类的其他对象的行为。

回答by Akhilesh

Difference between Abstract class & functional interface are many like all the difference between a normal interface and abstract class but measure difference is we can have default methods in functional interface but not in abstract class, this changes and helped all the collection implementation in java 8 foreach() and other performance method with use of lambda

抽象类和函数式接口之间的区别很多,就像普通接口和抽象类之间的所有区别一样,但衡量的区别是我们可以在函数式接口中使用默认方法,但在抽象类中没有,这改变并帮助了 java 8 foreach 中的所有集合实现() 和其他使用 lambda 的性能方法

package com.akhi;
public abstract class AbstractDemo {
abstract void letsRun(); // abstract valid
public String toString(); // invalid but valid in interface or functional interface

public boolean equals(Object o); // invalid but valid in interface or functional interface

public int concrete() { // Concrete is invalid in interface
    return 1;
}

public default int getMult(int a, int b) // default invalid but valid in case of functional
{
    return a * b;
}

public static int getSum(int a, int b) // static allowed
{
    return a + b;
}
}
package com.akhi;
public abstract class AbstractDemo {
abstract void letsRun(); // abstract valid
public String toString(); // invalid but valid in interface or functional interface

public boolean equals(Object o); // invalid but valid in interface or functional interface

public int concrete() { // Concrete is invalid in interface
    return 1;
}

public default int getMult(int a, int b) // default invalid but valid in case of functional
{
    return a * b;
}

public static int getSum(int a, int b) // static allowed
{
    return a + b;
}
}