Metody domyślne w interfejsach

Hej.
W Javie 8 doszły metody domyślne dla interfejsów. Wg. twórców ma to zapobiec sytuacjom gdy interfejs ma wiele implementacji i zostanie dodana metoda która dla wielu z nich będzie taka sama. Nie trzeba wtedy refaktorować wielu klas i wystarczy dodać metodę domyślną.

I już od bardzo długiego czasu nie daje mi żyć pytanie "dlaczego?". Większość z mian w javie 8 jest na duży plus. Ta mi się szczególnie nie podoba. Kilka powodów.

• Interfejsy powinny być specjalistyczne. W wielu przypadkach powinno się stworzyć nowy interfejs. Generalnie bardzo mało widziałem w życiu żeby to był problem. A nawet jak wystąpił to nie był na tyle uciążliwy żeby robić takie "szpachlowanie".
• Jeżeli interfejs faktycznie ma wiele implementacji i jest rozbudowany to prawdopodobnie ma też klasę abstrakcyjną z wspólną logiką. Tam powinna znaleźć się właśnie ta implementacja.
• Zaciera się granica pomiędzy klasą abstrakcyjną a interfejsem.

Jedyne sensowne wytłumaczenie jakie widzę to próba wprowadzenia wielokrotnego dziedziczenia w tym języku. Ale nawet gdyby to było potrzebne, to czemu po prostu nie zrobili tego na klasach? Nawet robiąc jakieś restrykcje dotyczące pól (np. ich brak) wyszło by to czyściej niż na interfejsach.

Jakie jest wasze zdanie? Może ktoś w ogóle zna prawdziwy cel takiego zabiegu?

Mylisz się ;) Klasycznym przykładem jest interfejs Collection do którego dodano metodę stream(). Interfejs wciąż pozostaje silnie specjalistyczny, ale bez domyślnych metod nie można go już rozszerzyć po opublikowaniu tak aby zachować wsteczną kompatybilność.

Nie zrobili tego na klasach, bo łamało by to podstawowe zasady języka. To co chciano uzyskać to mechanizm podobny do traitów ze scali. Nie jest to typowe wielodziedziczenie, ale bliżej temu do miksinów.

Zresztą daje to całkiem dużo fajnych możliwości.

To akurat jest bardzo fajny feature.

Możesz na przykład definiować metody na podstawie innych metod z interfejsów. W ten sposób liczba metod do zaimplementowania przez użytkownika końcowego maleje:

trait Eq[A] {
  def eq(lhs: A, rhs: A): Boolean =
    !neq(lhs, rhs)

  def neq(lhs: A, rhs: A): Boolean =
    !eq(lhs, rhs)
}

case class IntBox(x: Int)

val IntBoxEq = new Eq[IntBox] {
  override def eq(lhs: IntBox, rhs: IntBox): Boolean = lhs.x == rhs.x
}

def useEq[A](lhs: A, rhs: A, eq: Eq[A]): Unit = {
  println(eq.eq(lhs, rhs))
  println(eq.neq(lhs, rhs))
}

useEq(IntBox(123), IntBox(122), IntBoxEq)

Użytkownik takiego interfejsu może sobie wybrać co zaimplementować (czy metoda eq czy neq), a drugą dostaje w gratisie.

Można też implementować coś z interfejsu bazowego. Na przykład fmap da się zaimplementować przy użyciu bind i unit dla wszystkich monad.

trait Functor[F[_]] {
  def fmap[A, B](f: A => B, fa: F[A]): F[B]
}

trait Monad[M[_]] extends Functor[M]{
  override def fmap[A, B](f: A => B, m: M[A]): M[B] =
    bind[A, B](a => unit(f(a)), m)

  def bind[A, B](f: A => M[B], m: M[A]): M[B]
  def unit[A](a: A): M[A]
}

val ListMonad = new Monad[List] {
  def bind[A, B](f: A => List[B], xs: List[A]): List[B] =
    xs.flatMap(f)

  def unit[A](a: A): List[A] =
    List(a)
}

ListMonad.fmap[Int, Int](x => x * 2, List(1,2,3))

Też w takim przypadku nie widzę sensu nakładać na użytkownika odpowiedzialności implementowania tego.

Z klasami raczej nie da się wszystkiego zrobić, np. lista jest jednocześnie monada i foldable. Jakby to były klasy to by słabo całość wyglądała.

jak się ktoś pyta po co:

http://docs.oracle.com/javase/8/docs/api/java/util/function/Predicate.html
http://docs.oracle.com/javase/8/docs/api/java/util/function/Function.html

tam są metody oznaczone default.

najbardziej sikam na widok compose z Function, lofciam lofciam lofcian : : : :

Ok, trochę mi w głowie pojaśniało.
Dziękuję za odpowiedzi.