Associazione dinamica Java e sostituzione del metodo

Ieri ho avuto un colloquio telefonico tecnico di due ore (che ho superato, woohoo!), Ma ho completamente smorzato la seguente domanda riguardante l'associazione dinamica in Java. Ed è doppiamente sconcertante perché insegnavo questo concetto agli studenti universitari quando ero un assistente tecnico alcuni anni fa, quindi la prospettiva di aver dato loro informazioni sbagliate è un po 'inquietante ...

Ecco il problema che mi è stato dato:

/* What is the output of the following program? */

public class Test {

  public boolean equals( Test other ) {
    System.out.println( "Inside of Test.equals" );
    return false;
  }

  public static void main( String [] args ) {
    Object t1 = new Test();
    Object t2 = new Test();
    Test t3 = new Test();
    Object o1 = new Object();

    int count = 0;
    System.out.println( count++ );// prints 0
    t1.equals( t2 ) ;
    System.out.println( count++ );// prints 1
    t1.equals( t3 );
    System.out.println( count++ );// prints 2
    t3.equals( o1 );
    System.out.println( count++ );// prints 3
    t3.equals(t3);
    System.out.println( count++ );// prints 4
    t3.equals(t2);
  }
}

Ho affermato che l'output avrebbe dovuto essere due istruzioni print separate all'interno del equals()metodo sovrascritto : at t1.equals(t3)e t3.equals(t3). Il secondo caso è abbastanza ovvio e con il primo caso, anche se t1ha un riferimento di tipo Object, viene istanziato come tipo Test, quindi l'associazione dinamica dovrebbe chiamare la forma sovrascritta del metodo.

Apparentemente no. Il mio intervistatore mi ha incoraggiato a eseguire il programma da solo, ed ecco, c'era solo un singolo output dal metodo sovrascritto: in linea t3.equals(t3).

La mia domanda quindi è: perché? Come ho già detto, anche se t1è un riferimento di tipo Object (quindi l'associazione statica richiama il equals()metodo di Object ), l'associazione dinamica dovrebbe occuparsi di invocare la versione più specifica del metodo in base al tipo di riferimento istanziato. Cosa mi sto perdendo?

Java utilizza l'associazione statica per i metodi sovraccaricati e l'associazione dinamica per quelli sovrascritti. Nel tuo esempio, il metodo equals è sovraccarico (ha un tipo di parametro diverso da Object.equals ()), quindi il metodo chiamato è associato al tipo di riferimento in fase di compilazione.

Qualche discussione qui

Il fatto che sia il metodo dell'uguaglianza non è realmente rilevante, a parte il fatto che è un errore comune sovraccaricarlo invece di sovrascriverlo, di cui sei già a conoscenza in base alla tua risposta al problema nell'intervista.

Modifica: anche una buona descrizione qui . Questo esempio mostra invece un problema simile relativo al tipo di parametro, ma causato dallo stesso problema.

Credo che se l'associazione fosse effettivamente dinamica, ogni caso in cui il chiamante e il parametro fossero un'istanza di Test comporterebbe la chiamata del metodo sovrascritto. Quindi t3.equals (o1) sarebbe l'unico caso che non verrebbe stampato.

Il equalsmetodo di Testnon sovrascrive il equalsmetodo di java.lang.Object. Guarda il tipo di parametro! La Testclasse si sta sovraccaricando equalscon un metodo che accetta un file Test.

Se il equalsmetodo ha lo scopo di sovrascrivere, dovrebbe usare l'annotazione @Override. Ciò causerebbe un errore di compilazione per segnalare questo errore comune.

È interessante notare che, nel codice Groovy (che potrebbe essere compilato in un file di classe), tutte le chiamate tranne una eseguono l'istruzione print. (Quello che confronta un test con un oggetto chiaramente non chiama la funzione Test.equals (Test).) Questo perché groovy FA una digitazione completamente dinamica. Ciò è particolarmente interessante perché non ha variabili tipizzate in modo dinamico in modo esplicito. Ho letto in un paio di posti che questo è considerato dannoso, poiché i programmatori si aspettano che groovy faccia la cosa java.

Java non supporta la covarianza nei parametri, solo nei tipi restituiti.

In altre parole, mentre il tipo restituito in un metodo sovrascritto può essere un sottotipo di ciò che era nell'override, ciò non è vero per i parametri.

Se il tuo parametro per uguale in Object è Object, mettere un uguale a qualsiasi altra cosa in una sottoclasse sarà un metodo sovraccarico, non sovrascritto. Quindi, l'unica situazione in cui verrà chiamato quel metodo è quando il tipo statico del parametro è Test, come nel caso di T3.

Buona fortuna per il colloquio di lavoro! Mi piacerebbe essere intervistato presso un'azienda che pone questo tipo di domande invece delle solite domande di algo / strutture dati che insegno ai miei studenti.

Penso che la chiave risieda nel fatto che il metodo equals () non è conforme allo standard: accetta un altro oggetto Test, non l'oggetto Object e quindi non sovrascrive il metodo equals (). Ciò significa che in realtà l'hai solo sovraccaricato per fare qualcosa di speciale quando gli viene fornito l'oggetto Test mentre gli viene assegnato l'oggetto Object chiama Object.equals (Object o). Guardando quel codice attraverso qualsiasi IDE dovresti mostrare due metodi equals () per Test.

Il metodo viene sovraccaricato anziché sovrascritto. Equals accetta sempre un oggetto come parametro.

btw, hai un oggetto su questo nell'efficace java di Bloch (che dovresti possedere).

Alcune note in Dynamic Binding (DD) e Static Binding (SB) dopo aver cercato per un po ':

1.Timing eseguire : (Ref.1)

• DB: in fase di esecuzione
• SB: tempo del compilatore

2.Utilizzato per :

• DB: override
• SB: sovraccarico (statico, privato, finale) (Rif.2)

Riferimento:

1. Eseguire il risolutore medio quale metodo preferisce utilizzare
2. Perché non è possibile sovrascrivere il metodo con modificatore statico, privato o finale
3. http://javarevisited.blogspot.com/2012/03/what-is-static-and-dynamic-binding-in.html

Se viene aggiunto un altro metodo che esegue l'override invece di sovraccaricare, spiegherà la chiamata di binding dinamico in fase di esecuzione.

/ * Qual è l'output del seguente programma? * /

public class DynamicBinding {
    public boolean equals(Test other) {
        System.out.println("Inside of Test.equals");
        return false;
    }

    @Override
    public boolean equals(Object other) {
        System.out.println("Inside @override: this is dynamic binding");
        return false;
    }

    public static void main(String[] args) {
        Object t1 = new Test();
        Object t2 = new Test();
        Test t3 = new Test();
        Object o1 = new Object();

        int count = 0;
        System.out.println(count++);// prints 0
        t1.equals(t2);
        System.out.println(count++);// prints 1
        t1.equals(t3);
        System.out.println(count++);// prints 2
        t3.equals(o1);
        System.out.println(count++);// prints 3
        t3.equals(t3);
        System.out.println(count++);// prints 4
        t3.equals(t2);
    }
}

Ho trovato un articolo interessante sull'associazione dinamica e statica. Viene fornito con una parte di codice per la simulazione dell'associazione dinamica. Ha reso il mio codice più leggibile.

https://sites.google.com/site/jeffhartkopf/covariance

La risposta alla domanda "perché?" è così che viene definito il linguaggio Java.

Per citare l' articolo di Wikipedia su covarianza e controvarianza :

La covarianza del tipo restituito è implementata nella versione del linguaggio di programmazione Java J2SE 5.0. I tipi di parametro devono essere esattamente gli stessi (invarianti) per l'override del metodo, altrimenti il ​​metodo viene invece sovraccaricato con una definizione parallela.

Le altre lingue sono diverse.

È molto chiaro che qui non esiste il concetto di override. È il sovraccarico del metodo. il Object()metodo della classe Object prende il parametro di riferimento di tipo Object e questo equal()metodo prende il parametro di riferimento di tipo Test.

Cercherò di spiegarlo attraverso due esempi che sono le versioni estese di alcuni degli esempi che ho trovato online.

public class Test {

    public boolean equals(Test other) {
        System.out.println("Inside of Test.equals");
        return false;
    }

    @Override
    public boolean equals(Object other) {
        System.out.println("Inside of Test.equals ot type Object");
        return false;
    }

    public static void main(String[] args) {
        Object t1 = new Test();
        Object t2 = new Test();
        Test t3 = new Test();
        Object o1 = new Object();

        int count = 0;
        System.out.println(count++); // prints 0
        o1.equals(t2);

        System.out.println("\n" + count++); // prints 1
        o1.equals(t3);

        System.out.println("\n" + count++);// prints 2
        t1.equals(t2);

        System.out.println("\n" + count++);// prints 3
        t1.equals(t3);

        System.out.println("\n" + count++);// prints 4
        t3.equals(o1);

        System.out.println("\n" + count++);// prints 5
        t3.equals(t3);

        System.out.println("\n" + count++);// prints 6
        t3.equals(t2);
    }
}

Qui, per le righe con valori di conteggio 0, 1, 2 e 3; abbiamo riferimento di Object per o1 e t1 sul equals()metodo. Pertanto, in fase di compilazione, il equals()metodo dal file Object.class verrà limitato.

Tuttavia, anche se il riferimento di t1 è Object , ha l' inizializzazione della classe Test .
Object t1 = new Test();.
Pertanto, in fase di esecuzione chiama il public boolean equals(Object other)che è un file

metodo ignorato

.

Ora, per contare i valori come 4 e 6, è di nuovo semplice che t3 che ha il riferimento e l' inizializzazione di Test sta chiamando il equals()metodo con parametro come riferimenti a oggetti ed è un

metodo sovraccarico

OK!

Ancora una volta, per capire meglio quale metodo chiamerà il compilatore, è sufficiente fare clic sul metodo ed Eclipse evidenzierà i metodi di tipo simile che pensa chiamerà al momento della compilazione. Se non viene chiamato in fase di compilazione, questi metodi sono un esempio di override del metodo.