Domyślne użycie metody Java

Przez dziesięciolecia to było tak, że interfejsy były tylko tylko (tylko) dla określenia podpisy metod. Powiedziano nam, że to „właściwy sposób na robienie rzeczy”.

Potem pojawiła się Java 8 i powiedziała:

Teraz możesz zdefiniować domyślne metody. Muszę uciekać, pa.

Jestem ciekawy, w jaki sposób jest to trawione zarówno przez doświadczonych programistów Java, jak i tych, którzy zaczęli go ostatnio (w ostatnich latach) rozwijać. Zastanawiam się także, jak to pasuje do ortodoksji i praktyki Java.

Buduję trochę kodu eksperymentalnego i kiedy robiłem trochę refaktoryzacji, skończyłem z interfejsem, który po prostu rozszerza standardowy interfejs (Iterable) i dodaje dwie domyślne metody. I będę szczera, czuję się z tym cholernie dobrze.

Wiem, że jest to trochę otwarte, ale teraz, gdy było już trochę czasu, aby Java 8 mogła być używana w prawdziwych projektach, czy istnieje ortodoksja dotycząca korzystania z domyślnych metod? To, co najczęściej widzę, kiedy są omawiane, dotyczy sposobu dodawania nowych metod do interfejsu bez niszczenia istniejących konsumentów. Ale co z użyciem tego od samego początku, jak w przykładzie podanym powyżej. Czy ktoś napotkał jakiekolwiek problemy z implementacją w swoich interfejsach?

Świetnym przykładem użycia są interfejsy „dźwigniowe”: interfejsy, które mają tylko niewielką liczbę abstrakcyjnych metod (najlepiej 1), ale zapewniają wiele „dźwigni”, ponieważ zapewniają wiele funkcji: tylko Ty trzeba zaimplementować 1 metodę w swojej klasie, ale uzyskać wiele innych metod „za darmo”. Pomyśl o interfejsie zbiórki, na przykład, za pomocą jednego abstrakcyjnego foreachsposobu i defaultmetod, takich jak map, fold, reduce, filter, partition, groupBy, sort, sortBy, itd.

Oto kilka przykładów. Zacznijmyjava.util.function.Function<T, R> . Ma jedną abstrakcyjną metodę R apply<T>. I ma dwie domyślne metody, które pozwalają komponować funkcję z inną funkcją na dwa różne sposoby, przed lub po. Obie te metody kompozycji są implementowane przy użyciuapply :

default <V> Function<V, R> compose(Function<? super V, ? extends T> before) {
    return (V v) -> apply(before.apply(v));
}

default <V> Function<T, V> andThen(Function<? super R, ? extends V> after) {
    return (T t) -> after.apply(apply(t));
}

Możesz także utworzyć interfejs dla porównywalnych obiektów, coś takiego:

interface MyComparable<T extends MyComparable<T>> {
  int compareTo(T other);

  default boolean lessThanOrEqual(T other) {
    return compareTo(other) <= 0;
  }

  default boolean lessThan(T other) {
    return compareTo(other) < 0;
  }

  default boolean greaterThanOrEqual(T other) {
    return compareTo(other) >= 0;
  }

  default boolean greaterThan(T other) {
    return compareTo(other) > 0;
  }

  default boolean isBetween(T min, T max) {
    return greaterThanOrEqual(min) && lessThanOrEqual(max);
  }

  default T clamp(T min, T max) {
    if (lessThan(   min)) return min;
    if (greaterThan(max)) return max;
                          return (T)this;
  }
}

class CaseInsensitiveString implements MyComparable<CaseInsensitiveString> {
  CaseInsensitiveString(String s) { this.s = s; }
  private String s;

  @Override public int compareTo(CaseInsensitiveString other) {
    return s.toLowerCase().compareTo(other.s.toLowerCase());
  }
}

Lub wyjątkowo uproszczona struktura kolekcji, w której zwracane są wszystkie operacje kolekcji Collection, niezależnie od tego, jaki był oryginalny typ:

interface MyCollection<T> {
  void forEach(java.util.function.Consumer<? super T> f);

  default <R> java.util.Collection<R> map(java.util.function.Function<? super T, ? extends R> f) {
    java.util.Collection<R> l = new java.util.ArrayList();
    forEach(el -> l.add(f.apply(el)));
    return l;
  }
}

class MyArray<T> implements MyCollection<T> {
  private T[] array;

  MyArray(T[] array) { this.array = array; }

  @Override public void forEach(java.util.function.Consumer<? super T> f) {
    for (T el : array) f.accept(el);
  }

  @Override public String toString() {
    StringBuilder sb = new StringBuilder("(");
    map(el -> el.toString()).forEach(s -> { sb.append(s); sb.append(", "); } );
    sb.replace(sb.length() - 2, sb.length(), ")");
    return sb.toString();
  }

  public static void main(String... args) {
    MyArray<Integer> array = new MyArray<>(new Integer[] {1, 2, 3, 4});
    System.out.println(array);
    // (1, 2, 3, 4)
  }
}

Staje się to bardzo interesujące w połączeniu z lambdas, ponieważ taki interfejs „dźwigniowy” może być zaimplementowany przez lambda (jest to interfejs SAM).

Jest to ten sam przypadek użycia, dla którego metody C zostały dodane w C♯, ale metody domyślne mają jedną wyraźną zaletę: są to „właściwe” metody instancji, co oznacza, że ​​mają dostęp do prywatnych szczegółów implementacyjnych interfejsu ( privatenadchodzą metody interfejsu w Javie 9), podczas gdy metody rozszerzeń są jedynie cukrem syntaktycznym dla metod statycznych.

Gdyby Java kiedykolwiek otrzymała interfejs wstrzykiwania, pozwoliłaby również na bezpieczne, modułowe, łatanie małp w poprawnym typie. Byłoby to bardzo interesujące dla implementatorów języka na JVM: na przykład JRuby dziedziczy lub otacza klasy Java, aby zapewnić im dodatkową semantykę Ruby, ale idealnie chcą używać tych samych klas. Dzięki interfejsowi wstrzykiwania i metodom domyślnym mogą wstrzykiwać np. RubyObjectInterfejs java.lang.Object, tak aby Java Objecti Ruby Objectbyły dokładnie tym samym .