Java8: почему запрещено определять метод по умолчанию для метода из java.lang.Object

Методы по умолчанию - отличный новый инструмент в нашем наборе инструментов Java. Однако я попытался написать интерфейс, определяющий defaultверсию toStringметода. Java сообщает мне, что это запрещено, поскольку методы, объявленные в, java.lang.Objectнельзя defaultредактировать. Почему это так?

Я знаю, что существует правило «базовый класс всегда побеждает», поэтому по умолчанию (каламбур;) любая defaultреализация Objectметода в Objectлюбом случае будет перезаписана этим методом . Однако я не вижу причин, по которым не должно быть исключения для методов из Objectспецификации. Особенно для toStringэтого может быть очень полезно иметь реализацию по умолчанию.

Итак, в чем причина, по которой разработчики Java решили не разрешать defaultметоды, замещающие методы Object?

Это еще одна проблема языкового дизайна, которая кажется «очевидно хорошей идеей», пока вы не начнете копать и не поймете, что это на самом деле плохая идея.

В этом письме много на эту тему (и на другие темы тоже). Было несколько дизайнерских сил, которые объединились, чтобы привести нас к текущему дизайну:

• Желание сохранить простую модель наследования;
• Тот факт, что, пропустив очевидные примеры (например, превращение AbstractListв интерфейс), вы поймете, что наследование equals / hashCode / toString сильно привязано к одиночному наследованию и состоянию, а интерфейсы наследуются многократно и не имеют состояния;
• Это потенциально открыло дверь для некоторых неожиданных поступков.

Вы уже затронули цель «сохранить простоту»; правила наследования и разрешения конфликтов спроектированы так, чтобы быть очень простыми (классы имеют приоритет над интерфейсами, производные интерфейсы преобладают над суперинтерфейсами, и любые другие конфликты разрешаются реализующим классом). Конечно, эти правила можно настроить, чтобы сделать исключение, но Я думаю, вы обнаружите, когда начнете тянуть за эту веревку, что возрастающая сложность не так мала, как вы думаете.

Конечно, есть определенные преимущества, которые оправдывают большую сложность, но в данном случае их нет. Здесь мы говорим о методах equals, hashCode и toString. Все эти методы по сути связаны с состоянием объекта, и именно класс, которому принадлежит состояние, а не интерфейс, находится в лучшем положении, чтобы определить, что равенство означает для этого класса (тем более, что контракт на равенство довольно сильный; см. Java для некоторых удивительных последствий); писатели интерфейсов слишком далеко ушли.

AbstractListПример легко вытащить ; было бы прекрасно, если бы мы могли избавиться от AbstractListповедения и перенести его в Listинтерфейс. Но как только вы отойдете от этого очевидного примера, вы не сможете найти много других хороших примеров. В корневом каталоге AbstractListпредназначен для одиночного наследования. Но интерфейсы должны быть предназначены для множественного наследования.

Далее представьте, что вы пишете этот класс:

class Foo implements com.libraryA.Bar, com.libraryB.Moo { 
    // Implementation of Foo, that does NOT override equals
}

В Fooписатель смотрит на супертипах, не видит реализации равных, и приходят к выводу , что , чтобы получить равенство ссылок, все , что ему нужно сделать , это наследовать равно от Object. Затем, на следующей неделе, сопровождающий библиотеки Bar «услужливо» добавляет equalsреализацию по умолчанию . По электронной почте Ой! Теперь семантика Fooбыла нарушена интерфейсом в другом домене обслуживания «услужливо» добавлением значения по умолчанию для общего метода.

Значения по умолчанию должны быть значениями по умолчанию. Добавление значения по умолчанию к интерфейсу там, где его не было (где-либо в иерархии), не должно влиять на семантику конкретных реализующих классов. Но если бы значения по умолчанию могли «переопределить» методы объекта, это было бы неправдой.

Таким образом, хотя это кажется безобидной функцией, на самом деле она довольно вредна: она добавляет много сложности для небольшой дополнительной выразительности и делает слишком легким для благих намерений, безобидно выглядящих изменений отдельно скомпилированные интерфейсы, чтобы подорвать предполагаемая семантика реализации классов.

Запрещено определять методы по умолчанию в интерфейсах для методов в java.lang.Object, поскольку методы по умолчанию никогда не будут «достижимыми».

Методы интерфейса по умолчанию могут быть перезаписаны в классах, реализующих интерфейс, и реализация метода класса имеет более высокий приоритет, чем реализация интерфейса, даже если метод реализован в суперклассе. Поскольку все классы наследуются от java.lang.Object, методы в java.lang.Objectинтерфейсе будут иметь приоритет перед методом по умолчанию и будут вызываться вместо этого.

Брайан Гетц из Oracle предоставляет еще несколько подробностей о дизайнерском решении в этом сообщении списка рассылки .

Я не вникаю в головы авторов языка Java, поэтому можно только догадываться. Но я вижу много причин и полностью согласен с ними в этом вопросе.

Основная причина введения методов по умолчанию - это возможность добавлять новые методы в интерфейсы без нарушения обратной совместимости старых реализаций. Методы по умолчанию также могут использоваться для предоставления «удобных» методов без необходимости определять их в каждом из реализующих классов.

Ничего из этого не применимо к toString и другим методам Object. Проще говоря, методы по умолчанию были разработаны для обеспечения поведения по умолчанию там, где нет другого определения. Не предоставлять реализации, которые будут «конкурировать» с другими существующими реализациями.

Правило «базовый класс всегда побеждает» также имеет свои веские причины. Предполагается, что классы определяют реальные реализации, а интерфейсы определяют реализации по умолчанию , которые несколько слабее.

Кроме того, введение ЛЮБЫХ исключений из общих правил вызывает ненужные сложности и вызывает другие вопросы. Объект (более или менее) является классом, как и любой другой, так почему он должен вести себя иначе?

В общем, предлагаемое вами решение принесет больше минусов, чем плюсов.

Рассуждения очень просты, потому что Object является базовым классом для всех классов Java. Таким образом, даже если у нас есть метод объекта, определенный как метод по умолчанию в каком-либо интерфейсе, он будет бесполезен, потому что метод объекта всегда будет использоваться. Вот почему, чтобы избежать путаницы, у нас не может быть методов по умолчанию, которые переопределяют методы класса Object.

Чтобы дать очень педантичный ответ, запрещено определять defaultметод только для общедоступного метода из java.lang.Object. Необходимо рассмотреть 11 методов, которые можно разделить на три категории, чтобы ответить на этот вопрос.

1. Шесть из Objectметодов не может иметь defaultметоды , потому что они finalи не могут быть переопределены на всех: getClass(), notify(), notifyAll(), wait(), wait(long), и wait(long, int).
2. Три из Objectметодов не может иметь defaultметоды по причинам , указанным выше Брайан Гетц: equals(Object), hashCode(), и toString().

3. Два Objectметода могут иметь defaultметоды, хотя ценность таких значений по умолчанию в лучшем случае сомнительна: clone()и finalize().

   public class Main {
       public static void main(String... args) {
           new FOO().clone();
           new FOO().finalize();
       }
   
       interface ClonerFinalizer {
           default Object clone() {System.out.println("default clone"); return this;}
           default void finalize() {System.out.println("default finalize");}
       }
   
       static class FOO implements ClonerFinalizer {
           @Override
           public Object clone() {
               return ClonerFinalizer.super.clone();
           }
           @Override
           public void finalize() {
               ClonerFinalizer.super.finalize();
           }
       }
   }