抽象类作为功能接口 [英] Abstract class as functional interface

问题描述

在java 8中，只有一个抽象方法的抽象类不是一个功能接口（ JSR 335
$ b

这个界面是一个功能界面：

  public interface MyFunctionalInterface {
 public abstract void myAbstractMethod（）; 
 public void method（）{
 myAbstractMethod（）; 
 
 
  

但是这个抽象类不是：

  public abstract class MyFunctionalAbstractClass {
 public abstract void myAbstractMethod（）; 
 public void method（）{
 myAbstractMethod（）; 
 
 
 
 
 $ b $ p 
 
 
所以我不能使用抽象类作为lambda表达式和方法引用的目标。
  public class Lambdas {
 public static void main（String [] args ）{
 MyFunctionalAbstractClass functionalAbstractClass =（） - > {}; 
 
 
 
 
 $ b $ p $编译错误是：这个表达式的目标类型必须是一个函数接口。
 
 
 
为什么语言设计者强加此限制？
 
解决方案
自从Lambda项目成立以来，这一直是一个重要的话题，并受到了很多的关注。首席Java语言架构师Brian Goetz强烈支持将lambda视为函数，而不是对象。 Quote： 
 
 
 
 
我相信，发展Java的最佳方向是
鼓励更实用的编程风格。 Lambda的作用是
主要用于支持开发和消费更多
类似功能的库
 
 
 
我对Java的未来感到乐观，但对向前推进，我们有时需要放弃一些舒适的想法。 Lambdas-are-functions打开
门。 Lambdas-are-objects关闭了它们。我们希望看到这些门打开
。
 
 这里是引用来源和这里是Brian最近发表的一篇文章，它重申了相同的哲学观点，并用更多更实际的论点重申了他们的观点： 
 
 
 
 
使模型变得更简单打开各种VM 
优化的大门。 （Jettisoning身份是关键。）函数是
值。将它们建模为对象使得它们比它们需要的更重，更复杂，
。 
 
 
在公共汽车下抛出这个用例之前，我们做了一些语料库分析
以发现与接口
 SAM相比，抽象类SAM的使用频率。我们发现，在该语料库中，只有3％的lambda候选
内部类实例具有抽象类作为它们的目标。而其中大部分
都适用于简单的重构，您在其中添加了一个
的构造函数/工厂，它接受了一个以接口为目标的lambda。 
 
 
 
In java 8, an abstract class with only one abstract method is not a functional interface (JSR 335).

This interface is a functional interface:
public interface MyFunctionalInterface {
    public abstract void myAbstractMethod();
    public default void method() {
        myAbstractMethod();
    }
}
but this abstract class is not:
public abstract class MyFunctionalAbstractClass {
    public abstract void myAbstractMethod();
    public void method() {
        myAbstractMethod();
    }
}
So i can't use the abstract class as a target for a lambda expressions and method references.
public class Lambdas {
    public static void main(String[] args) {
        MyFunctionalAbstractClass functionalAbstractClass = () -> {};
    }
}
The compilation error is: The target type of this expression must be a functional interface.

Why the language designers imposed this restriction ?
解决方案
This has been an important topic since the very inception of the Lambda project and has received a lot of thought. Brian Goetz, the chief Java Language architect, strongly supports the view of lambda as a function, not an object. Quote:

  
It is my belief that the best direction for evolving Java is to 
  encourage a more functional style of programming.  The role of Lambda is 
  primarily to support the development and consumption of more 
  functional-like libraries
  
  
I am optimistic about Java's future, but to move forward we sometimes 
  have to let go of some comfortable ideas.  Lambdas-are-functions opens 
  doors.  Lambdas-are-objects closes them.  We prefer to see those doors 
  left open.
Here is a link to the quote's source and here is Brian's more recent post which reiterates the same phylosophical points and reaffirms them with additional, more practical arguments:

  
Making the model simpler opens doors to all sorts of VM 
  optimizations.  (Jettisoning identity is key here.)  Functions are 
  values.  Modeling them as objects makes them heavier, and more complex, 
  than they need to be.
  
  
Before throwing this use case under the bus, we did some corpus analysis 
  to found how often abstract class SAMs are used compared to interface 
  SAMs.  We found that in that corpus, only 3% of the lambda candidate 
  inner class instances had abstract classes as their target.  And most of 
  them were amenable to simple refactorings where you added a 
  constructor/factory that accepted a lambda that was interface-targeted. 


                        
这篇关于抽象类作为功能接口的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！