c++ lambda 重载_您会后悔对Lambdas应用重载！

c++ lambda 重载

编写好的API很难。 非常辛苦。 如果您希望用户喜欢您的API，则必须考虑很多事情。 您必须在以下两者之间找到适当的平衡：

1. 用处
2. 易用性
3. 向后兼容
4. 前向兼容性

之前，在我们的文章： 如何设计良好的常规API中，我们已经就此主题进行过博客讨论。 今天，我们将研究如何…

Java 8更改规则

是!

重载是在两个方面提供便利的好工具：

• 通过提供参数类型替代
• 通过提供参数默认值

来自JDK的上述示例包括：

public class Arrays {

    // Argument type alternatives
    public static void sort(int[] a) { ... }
    public static void sort(long[] a) { ... }

    // Argument default values
    public static IntStream stream(int[] array) { ... }
    public static IntStream stream(int[] array, 
        int startInclusive, 
        int endExclusive) { ... }
}

jOOQ API显然充满了这种便利。 由于jOOQ是SQL的DSL ，我们甚至可能会滥用一点：

public interface DSLContext {
    <T1> SelectSelectStep<Record1<T1>> 
        select(SelectField<T1> field1);

    <T1, T2> SelectSelectStep<Record2<T1, T2>> 
        select(SelectField<T1> field1, 
               SelectField<T2> field2);

    <T1, T2, T3> SelectSelectStep<Record3<T1, T2, T3>> s
        select(SelectField<T1> field1, 
               SelectField<T2> field2, 
               SelectField<T3> field3);

    <T1, T2, T3, T4> SelectSelectStep<Record4<T1, T2, T3, T4>> 
        select(SelectField<T1> field1, 
               SelectField<T2> field2, 
               SelectField<T3> field3, 
               SelectField<T4> field4);

    // and so on...
}

诸如Ceylon之类的语言通过声称以上内容是在Java中使用重载的唯一合理原因，将便利性这一概念进一步提高了。 因此，锡兰（Ceylon）的创建者已完全消除了其语言中的重载，将以上内容替换为联合类型和参数的实际默认值。 例如

// Union types
void sort(int[]|long[] a) { ... }

// Default argument values
IntStream stream(int[] array,
    int startInclusive = 0,
    int endInclusive = array.length) { ... }

阅读“我希望在Java中拥有的十大锡兰语言功能” ，以获取有关锡兰的更多信息。

不幸的是，在Java中，我们不能使用联合类型或参数默认值。 因此，我们必须使用重载为API使用者提供便捷的方法。

但是，如果您的方法参数是一个函数接口 ，则在方法重载方面，Java 7和Java 8之间的情况发生了巨大变化。 JavaFX在此给出一个示例。

JavaFX的“不友好”的ObservableList

JavaFX通过使它们“可观察”来增强JDK集合类型。 不要与Observable混淆， Observable是JDK 1.0和Swing之前的恐龙类型。

JavaFX自己的Observable本质上是这样的：

public interface Observable {
  void addListener(InvalidationListener listener);
  void removeListener(InvalidationListener listener);
}

幸运的是，这个InvalidationListener是一个功能接口：

@FunctionalInterface
public interface InvalidationListener {
  void invalidated(Observable observable);
}

这很棒，因为我们可以做以下事情：

Observable awesome = 
    FXCollections.observableArrayList();
awesome.addListener(fantastic -> splendid.cheer());

（请注意，我是如何用更开朗的术语替换foo / bar / baz的。我们都应该这样做。Foo和bar是如此1970 ）

不幸的是，当我们做我们可能要做的事情时，事情变得更加繁琐。 即，与其声明一个Observable ， Observable是一个更加有用的ObservableList ：

ObservableList<String> awesome = 
    FXCollections.observableArrayList();
awesome.addListener(fantastic -> splendid.cheer());

但是现在，我们在第二行收到编译错误：

awesome.addListener(fantastic -> splendid.cheer());
//      ^^^^^^^^^^^ 
// The method addListener(ListChangeListener<? super String>) 
// is ambiguous for the type ObservableList<String>

因为，本质上...

public interface ObservableList<E> 
extends List<E>, Observable {
    void addListener(ListChangeListener<? super E> listener);
}

和…

@FunctionalInterface
public interface ListChangeListener<E> {
    void onChanged(Change<? extends E> c);
}

再一次，在Java 8之前，这两种侦听器类型是完全可区分的，并且仍然是可区分的。 您可以通过传递命名类型来轻松调用它们。 如果我们编写以下代码，我们的原始代码仍然可以使用：

ObservableList<String> awesome = 
    FXCollections.observableArrayList();
InvalidationListener hearYe = 
    fantastic -> splendid.cheer();
awesome.addListener(hearYe);

要么…

ObservableList<String> awesome = 
    FXCollections.observableArrayList();
awesome.addListener((InvalidationListener) 
    fantastic -> splendid.cheer());

甚至…

ObservableList<String> awesome = 
    FXCollections.observableArrayList();
awesome.addListener((Observable fantastic) -> 
    splendid.cheer());

所有这些措施将消除歧义。 但坦率地说，如果您必须显式键入lambda或参数类型，则lambda的性能只有后者的一半。 我们拥有现代化的IDE，它们可以执行自动补全并帮助推断类型，就像编译器本身一样。

想象一下，如果我们真的想调用另一个addListener()方法，它需要一个ListChangeListener。 我们必须写任何

ObservableList<String> awesome = 
    FXCollections.observableArrayList();

// Agh. Remember that we have to repeat "String" here
ListChangeListener<String> hearYe = 
    fantastic -> splendid.cheer();
awesome.addListener(hearYe);

要么…

ObservableList<String> awesome = 
    FXCollections.observableArrayList();

// Agh. Remember that we have to repeat "String" here
awesome.addListener((ListChangeListener<String>) 
    fantastic -> splendid.cheer());

甚至…

ObservableList<String> awesome = 
    FXCollections.observableArrayList();

// WTF... "extends" String?? But that's what this thing needs...
awesome.addListener((Change<? extends String> fantastic) -> 
    splendid.cheer());

必须警惕。

API设计很难。 以前很难，现在变得越来越难。 在Java 8中，如果您的API方法的任何参数是功能接口，请三思而后行重载该API方法。 一旦您确定要继续进行重载，请再次考虑，这是否真的是一个好主意。

不服气吗？ 仔细看一下JDK。 例如java.util.stream.Stream类型。 您看到多少个具有相同数量的功能接口参数的重载方法，而这些接口又采用了相同数量的方法参数（就像我们前面的addListener()示例中一样）？

零。

在重载参数编号不同的地方有重载。 例如：

<R> R collect(Supplier<R> supplier,
              BiConsumer<R, ? super T> accumulator,
              BiConsumer<R, R> combiner);

<R, A> R collect(Collector<? super T, A, R> collector);

调用collect()时，您永远不会有任何歧义。

但是，如果参数编号没有不同，并且参数本身的方法参数编号也没有变化，则方法名称也不同。 例如：

<R> Stream<R> map(Function<? super T, ? extends R> mapper);
IntStream mapToInt(ToIntFunction<? super T> mapper);
LongStream mapToLong(ToLongFunction<? super T> mapper);
DoubleStream mapToDouble(ToDoubleFunction<? super T> mapper);

现在，这在呼叫站点上非常令人讨厌，因为您必须预先考虑必须根据各种相关类型使用哪种方法。

但这确实是解决这一难题的唯一方法。 因此，请记住： 您会为Lambdas应用重载感到遗憾！

翻译自: https://www.javacodegeeks.com/2015/02/you-will-regret-applying-overloading-with-lambdas.html

c++ lambda 重载