Java8: Perché è vietato definire un metodo predefinito per un metodo da java.lang.Object

I metodi predefiniti sono un bel nuovo strumento nella nostra casella degli strumenti Java. Tuttavia, ho provato a scrivere un'interfaccia che definisce una defaultversione del toStringmetodo. Java mi dice che questo è proibito, poiché i metodi dichiarati injava.lang.Object potrebbero non essere modificati default. Perché è così?

So che esiste la regola "la classe base vince sempre", quindi per impostazione predefinita (gioco di parole), qualsiasi defaultimplementazione di un Objectmetodo verrebbe sovrascritta dal metodo in Objectogni caso. Tuttavia, non vedo alcun motivo per cui non ci dovrebbe essere un'eccezione per i metodi Objectnelle specifiche. Soprattutto toStringperché potrebbe essere molto utile avere un'implementazione predefinita.

Quindi, qual è la ragione per cui i progettisti Java hanno deciso di non consentire i defaultmetodi che hanno la precedenza sui metodi Object?

Questo è un altro di quei problemi di design del linguaggio che sembra "ovviamente una buona idea" fino a quando non inizi a scavare e ti rendi conto che in realtà è una cattiva idea.

Questa mail ha molto sull'argomento (e anche su altri argomenti). Ci sono state diverse forze di progettazione che sono confluite per portarci al design attuale:

• Il desiderio di mantenere semplice il modello ereditario;
• Il fatto che una volta esaminati gli esempi ovvi (ad esempio, trasformandosi AbstractListin un'interfaccia), ti rendi conto che ereditare equals / hashCode / toString è fortemente legato alla singola eredità e stato e che le interfacce sono moltiplicate ereditate e apolidi;
• Che potenzialmente ha aperto la porta ad alcuni comportamenti sorprendenti.

Hai già toccato l'obiettivo "Keep it simple"; le regole di ereditarietà e risoluzione dei conflitti sono progettate per essere molto semplici (le classi vincono sulle interfacce, le interfacce derivate vincono sulle superinterfacce e qualsiasi altro conflitto è risolto dalla classe di implementazione.) Naturalmente queste regole potrebbero essere modificate per fare un'eccezione, ma Penso che scoprirai quando inizi a tirare quella stringa, che la complessità incrementale non è così piccola come potresti pensare.

Certo, c'è un certo grado di beneficio che giustificherebbe una maggiore complessità, ma in questo caso non è lì. I metodi di cui stiamo parlando sono uguali, hashCode e toString. Questi metodi sono tutti intrinsecamente relativi allo stato dell'oggetto, ed è la classe che possiede lo stato, non l'interfaccia, che si trova nella posizione migliore per determinare cosa significhi l'uguaglianza per quella classe (specialmente perché il contratto per l'uguaglianza è abbastanza forte; vedi Efficace Java per alcune conseguenze sorprendenti); gli scrittori di interfacce sono troppo lontani.

È facile estrarre l' AbstractListesempio; sarebbe bello se potessimo sbarazzarci di AbstractListe mettere il comportamento Listnell'interfaccia. Ma una volta superato questo ovvio esempio, non ci sono molti altri buoni esempi da trovare. Alla radice, AbstractListè progettato per singola eredità. Ma le interfacce devono essere progettate per l'ereditarietà multipla.

Inoltre, immagina di scrivere questa lezione:

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

Lo Fooscrittore osserva i supertipi, non vede l'implementazione di uguali e conclude che per ottenere l'uguaglianza di riferimento, tutto ciò che deve fare è ereditare uguali Object. Quindi, la settimana prossima, il manutentore della libreria per la barra "utile" aggiunge equalsun'implementazione predefinita . Ops! Ora la semantica di Fooè stata interrotta da un'interfaccia in un altro dominio di manutenzione "utile" aggiungendo un valore predefinito per un metodo comune.

I valori predefiniti dovrebbero essere predefiniti. L'aggiunta di un valore predefinito a un'interfaccia in cui non era presente (in qualsiasi punto della gerarchia) non dovrebbe influire sulla semantica delle classi di implementazione concrete. Ma se i valori predefiniti potessero "sovrascrivere" i metodi Object, ciò non sarebbe vero.

Quindi, sebbene sembri una funzionalità innocua, in realtà è piuttosto dannosa: aggiunge molta complessità per una piccola espressività incrementale e lo rende troppo facile per modifiche minacciose e dall'aspetto innocuo di interfacce compilate separatamente per minare la semantica prevista delle classi di attuazione.

È vietato definire metodi predefiniti nelle interfacce per i metodi in java.lang.Object, poiché i metodi predefiniti non sarebbero mai "raggiungibili".

I metodi di interfaccia predefiniti possono essere sovrascritti nelle classi che implementano l'interfaccia e l'implementazione della classe del metodo ha una precedenza più alta rispetto all'implementazione dell'interfaccia, anche se il metodo è implementato in una superclasse. Poiché tutte le classi ereditano da java.lang.Object, i metodi in java.lang.Objectavrebbero la precedenza sul metodo predefinito nell'interfaccia e sarebbero invece invocati.

Brian Goetz di Oracle fornisce alcuni dettagli in più sulla decisione di progettazione in questo post della mailing list .

Non vedo nella testa degli autori del linguaggio Java, quindi possiamo solo immaginare. Ma vedo molte ragioni e sono assolutamente d'accordo con loro in questo numero.

Il motivo principale per l'introduzione di metodi predefiniti è di poter aggiungere nuovi metodi alle interfacce senza interrompere la retrocompatibilità delle implementazioni precedenti. I metodi predefiniti possono anche essere utilizzati per fornire metodi di "convenienza" senza la necessità di definirli in ciascuna delle classi di attuazione.

Nessuno di questi si applica a String e ad altri metodi di Object. In poche parole, i metodi predefiniti sono stati progettati per fornire il comportamento predefinito in cui non esiste altra definizione. Non fornire implementazioni che "competeranno" con altre implementazioni esistenti.

Anche la regola "la classe base vince sempre" ha le sue solide ragioni. Si suppone che le classi definiscano implementazioni reali , mentre le interfacce definiscono l' impostazione predefinita implementazioni , che sono in qualche modo più deboli.

Inoltre, l'introduzione di QUALSIASI eccezione alle regole generali causa complessità inutili e solleva altre domande. L'oggetto è (più o meno) una classe come qualsiasi altra, quindi perché dovrebbe avere un comportamento diverso?

Tutto sommato, la soluzione che proporresti probabilmente porterebbe più svantaggi che vantaggi.

Il ragionamento è molto semplice, è perché Object è la classe base per tutte le classi Java. Quindi, anche se abbiamo il metodo Object definito come metodo predefinito in alcune interfacce, sarà inutile perché verrà sempre utilizzato il metodo Object. Ecco perché per evitare confusione, non possiamo avere metodi predefiniti che sovrascrivono i metodi della classe Object.

Per dare una risposta molto pedante, è vietato definire un defaultmetodo per un metodo pubblico da java.lang.Object. Esistono 11 metodi da considerare, che possono essere classificati in tre modi per rispondere a questa domanda.

1. Sei dei Objectmetodi non può avere defaultmetodi perché sono finale non può essere ignorata a tutti: getClass(), notify(), notifyAll(), wait(), wait(long), e wait(long, int).
2. Tre dei Objectmetodi non può avere defaultmetodi per le ragioni sopra esposte da Brian Goetz: equals(Object), hashCode(), e toString().

3. Due dei Objectmetodi possono avere defaultmetodi, sebbene il valore di tali valori predefiniti sia discutibile nella migliore delle ipotesi: clone()e 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();
           }
       }
   }