Le sottoclassi ereditano i campi privati?

Questa è una domanda per l'intervista.

Le sottoclassi ereditano i campi privati?

Ho risposto "No", perché non possiamo accedervi usando il "normale modo OOP". Ma l'intervistatore pensa che siano ereditati, perché possiamo accedere a tali campi indirettamente o usando la riflessione ed esistono ancora nell'oggetto.

Dopo essere tornato, ho trovato la seguente citazione nel javadoc :

Membri privati ​​in una super classe

Una sottoclasse non eredita i membri privati ​​della sua classe genitore.

Conosci qualche argomento per l'opinione dell'intervistatore?

La maggior parte della confusione nella domanda / risposta qui circonda la definizione di Eredità.

Ovviamente, come spiega @DigitalRoss, un OGGETTO di una sottoclasse deve contenere i campi privati ​​della sua superclasse. Come afferma, non avere accesso a un membro privato non significa che non ci sia.

Però. Questo è diverso dalla nozione di eredità per una classe. Come nel caso del mondo Java, dove esiste una questione di semantica, l'arbitro è la specifica del linguaggio Java (attualmente terza edizione).

Come afferma JLS ( https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.2 ):

I membri di una classe dichiarati privati ​​non sono ereditati da sottoclassi di quella classe. Solo i membri di una classe dichiarati protetti o pubblici sono ereditati da sottoclassi dichiarate in un pacchetto diverso da quello in cui è dichiarata la classe.

Questo affronta l'esatta domanda posta dall'intervistatore: "i sotto CLASSI ereditano i campi privati". (enfasi aggiunta da me)

La risposta è No. Non lo fanno. OGGETTI di sottoclassi contengono campi privati ​​delle loro superclassi. La sottoclasse stessa NON ha alcuna nozione di campi privati ​​della sua superclasse.

È una semantica di natura pedante? Sì. È una domanda utile per l'intervista? Probabilmente no. Ma JLS stabilisce la definizione per il mondo Java e lo fa (in questo caso) in modo inequivocabile.

EDITED (rimossa una citazione parallela da Bjarne Stroustrup che a causa delle differenze tra java e c ++ probabilmente aggiunge solo confusione. Lascerò la mia risposta sul JLS :)

sì

È importante rendersi conto che mentre ci sono due classi, c'è un solo oggetto.

Quindi sì, ovviamente ha ereditato i campi privati. Presumibilmente, sono essenziali per la corretta funzionalità dell'oggetto e mentre un oggetto della classe genitore non è un oggetto della classe derivata, un'istanza della classe derivata è per lo più sicuramente un'istanza della classe genitore. Non potrebbe essere che senza tutti i campi.

No, non puoi accedervi direttamente. Sì, sono ereditati. Essi devono essere.

È una buona domanda

Aggiornare:

Err, "No"

Bene, immagino che tutti abbiamo imparato qualcosa. Poiché la JLS ha originato l'esatta frase "non ereditata", è corretto rispondere "no" . Poiché la sottoclasse non può accedere o modificare i campi privati, in altre parole, non vengono ereditati. Ma c'è davvero è solo un oggetto, in realtà contiene i campi privati, e quindi se qualcuno prende i JLS e la formulazione esercitazione nel modo sbagliato, sarà molto difficile da capire OOP, oggetti Java, e ciò che sta realmente accadendo.

Aggiorna per aggiornare:

La controversia qui implica un'ambiguità fondamentale: di cosa si discute esattamente? L' oggetto? O stiamo parlando in qualche modo della classe stessa? Molta latitudine è consentita quando si descrive la classe al contrario dell'oggetto. Quindi la sottoclasse non eredita i campi privati, ma un oggetto che è un'istanza della sottoclasse certamente contiene i campi privati.

No. I campi privati ​​non sono ereditati ... ed è per questo che è stato inventato Protected . È di progettazione. Immagino che ciò abbia giustificato l'esistenza di un modificatore protetto.

Ora veniamo ai contesti. Cosa intendi per ereditato - se è presente nell'oggetto creato dalla classe derivata? sì.

Se vuoi dire può essere utile per la classe derivata. Beh no.

Ora, quando si arriva alla programmazione funzionale, il campo privato della superclasse non viene ereditato in modo significativo per la sottoclasse . Per la sottoclasse, un campo privato di superclasse è uguale a un campo privato di qualsiasi altra classe.

Funzionalmente, non è ereditato. Ma idealmente lo è.

OK, ho appena visto il tutorial Java che citano questo:

Membri privati ​​in una super classe

Una sottoclasse non eredita i membri privati ​​della sua classe genitore. Tuttavia, se la superclasse ha metodi pubblici o protetti per accedere ai suoi campi privati, questi possono essere utilizzati anche dalla sottoclasse.

consultare: http://download.oracle.com/javase/tutorial/java/IandI/subclasses.html

Sono d'accordo, il campo è lì. Ma la sottoclasse non ottiene alcun privilegio su quel campo privato. Per una sottoclasse, il campo privato è uguale a qualsiasi campo privato di qualsiasi altra classe.

Credo che sia puramente una questione di punti di vista. Puoi modellare l'argomento su entrambi i lati. È meglio giustificare in entrambi i modi.

Dipende dalla tua definizione di "eredità". La sottoclasse ha ancora i campi in memoria? Decisamente. Può accedervi direttamente? No. Sono solo sottigliezze della definizione; il punto è capire cosa sta realmente accadendo.

Dimostrerò il concetto con il codice. Le sottoclassi ereditano ATTUALMENTE le variabili private della superclasse. L'unico problema è che non sono accessibili agli oggetti figlio a meno che non vengano forniti getter e setter pubblici per le variabili private nella superclasse.

Considera due classi nel pacchetto Dump. Il figlio estende il genitore.

Se ricordo bene, un oggetto figlio in memoria è costituito da due regioni. Uno è solo la parte genitore e l'altro è solo la parte figlio. Un figlio può accedere alla sezione privata nel codice del suo genitore solo tramite un metodo pubblico nel genitore.

Pensare in questo modo. Boltok, padre di Borat, ha una cassaforte contenente $ 100.000. Non vuole condividere la sua variabile "privata" sicura. Quindi, non fornisce una chiave per la sicurezza. Borat eredita la cassaforte. Ma a che serve se non riesce nemmeno ad aprirlo? Se solo suo padre avesse fornito la chiave.

Genitore -

package Dump;

public class Parent {

    private String reallyHidden;
    private String notReallyHidden;

    public String getNotReallyHidden() {
        return notReallyHidden;
    }

    public void setNotReallyHidden(String notReallyHidden) {
        this.notReallyHidden = notReallyHidden;
    }

}//Parent

Bambino -

package Dump;

public class Child extends Parent {

    private String childOnly;

    public String getChildOnly() {
        return childOnly;
    }

    public void setChildOnly(String childOnly) {
        this.childOnly = childOnly;
    }

    public static void main(String [] args){

        System.out.println("Testing...");
        Child c1 = new Child();
        c1.setChildOnly("childOnly");
        c1.setNotReallyHidden("notReallyHidden");

        //Attempting to access parent's reallyHidden
            c1.reallyHidden;//Does not even compile

    }//main

}//Child

No. Non lo ereditano.

Il fatto che un'altra classe possa usarla indirettamente non dice nulla sull'ereditarietà, ma sull'incapsulamento.

Per esempio:

class Some { 
   private int count; 
   public void increment() { 
      count++;
   }
   public String toString() { 
       return Integer.toString( count );
   }
}

class UseIt { 
    void useIt() { 
        Some s = new Some();
        s.increment();
        s.increment();
        s.increment();
        int v = Integer.parseInt( s.toString() );
        // hey, can you say you inherit it?
     }
}

Puoi anche ottenere il valore di countdentro UseIttramite la riflessione. Non significa che lo erediti.

AGGIORNARE

Anche se il valore è presente, non viene ereditato dalla sottoclasse.

Ad esempio una sottoclasse definita come:

class SomeOther extends Some { 
    private int count = 1000;
    @Override
    public void increment() { 
        super.increment();
        count *= 10000;
    }
}

class UseIt { 
    public static void main( String ... args ) { 
        s = new SomeOther();
        s.increment();
        s.increment();
        s.increment();
        v = Integer.parseInt( s.toString() );
        // what is the value of v?           
     }
}

Questa è esattamente la stessa situazione del primo esempio. L'attributo countè nascosto e non ereditato dalla sottoclasse. Tuttavia, come sottolinea DigitalRoss, il valore è presente, ma non per eredità.

Detto così. Se tuo padre è ricco e ti dà una carta di credito, puoi ancora comprare qualcosa con i suoi soldi, ma non significa che hai ereditato tutti quei soldi, vero?

Altro aggiornamento

È molto interessante, però, sapere perché l'attributo è presente.

Francamente non ho il termine esatto per descriverlo, ma è la JVM e il modo in cui funziona che carica anche la definizione genitore "non ereditata".

Potremmo effettivamente cambiare il genitore e la sottoclasse funzionerà comunque.

Per esempio :

//A.java
class A {
   private int i;
   public String toString() { return ""+ i; }
}
// B.java
class B extends A {}
// Main.java
class Main {
   public static void main( String [] args ) {
      System.out.println( new B().toString() );
    }
}
// Compile all the files
javac A.java B.java Main.java
// Run Main
java Main
// Outout is 0 as expected as B is using the A 'toString' definition
0

// Change A.java
class A {
   public String toString() {
      return "Nothing here";
   }
}
// Recompile ONLY A.java
javac A.java
java Main
// B wasn't modified and yet it shows a different behaviour, this is not due to 
// inheritance but the way Java loads the class
Output: Nothing here

Immagino che il termine esatto possa essere trovato qui: le specifiche della macchina virtuale JavaTM

Bene, la mia risposta alla domanda dell'intervistatore è: i membri privati ​​non sono ereditati in sottoclassi ma sono accessibili all'oggetto della sottoclasse o della sottoclasse solo tramite metodi di getter o setter pubblici o qualsiasi metodo appropriato della classe originale. La pratica normale è di mantenere i membri privati ​​e accedervi usando metodi getter e setter che sono pubblici. Quindi qual è il punto di ereditare i metodi getter e setter solo quando il membro privato con cui hanno a che fare non è disponibile per l'oggetto? Qui "ereditato" significa semplicemente che è disponibile direttamente nella sottoclasse per giocare con i metodi appena introdotti nella sottoclasse.

Salvare il file seguente come ParentClass.java e provarlo da soli ->

public class ParentClass {
  private int x;

  public int getX() {
    return x;
  }

  public void setX(int x) {
    this.x = x;
  }
}

class SubClass extends ParentClass {
  private int y;

  public int getY() {
    return y;
  }

  public void setY(int y) {
    this.y = y;
  }

  public void setXofParent(int x) {
    setX(x); 
  }
}

class Main {
  public static void main(String[] args) {
    SubClass s = new SubClass();
    s.setX(10);
    s.setY(12);
    System.out.println("X is :"+s.getX());
    System.out.println("Y is :"+s.getY());
    s.setXofParent(13);
    System.out.println("Now X is :"+s.getX());
  }
}

Output:
X is :10
Y is :12
Now X is :13

Se proviamo a utilizzare la variabile privata x di ParentClass nel metodo di SubClass, allora non è direttamente accessibile per eventuali modifiche (significa non ereditato). Ma x può essere modificato in SubClass tramite il metodo setX () della classe originale come fatto nel metodo setXofParent () O può essere modificato usando l'oggetto ChildClass usando il metodo setX () o il metodo setXofParent () che alla fine chiama setX (). Quindi qui setX () e getX () sono tipi di porte per il membro privato x di una ParentClass.

Un altro semplice esempio è la superclasse di Clock con ore e minuti come membri privati ​​e metodi getter e setter appropriati come pubblici. Quindi arriva DigitalClock come una sottoclasse di Clock. Qui se l'oggetto DigitalClock non contiene membri di ore e minuti, le cose vengono rovinate.

Ok, questo è un problema molto interessante che ho studiato molto e sono giunto alla conclusione che i membri privati ​​di una superclasse sono effettivamente disponibili (ma non accessibili) negli oggetti della sottoclasse. Per dimostrarlo, ecco un codice di esempio con una classe genitore e una classe figlio e sto scrivendo un oggetto classe figlio in un file txt e leggendo un membro privato chiamato "bhavesh" nel file, quindi dimostrando che è effettivamente disponibile nel figlio classe ma non accessibile a causa del modificatore di accesso.

import java.io.Serializable;
public class ParentClass implements Serializable {
public ParentClass() {

}

public int a=32131,b,c;

private int bhavesh=5555,rr,weq,refw;
}

import java.io.*;
import java.io.Serializable;
public class ChildClass extends ParentClass{
public ChildClass() {
super();
}

public static void main(String[] args) {
ChildClass childObj = new ChildClass();
ObjectOutputStream oos;
try {
        oos = new ObjectOutputStream(new FileOutputStream("C:\\MyData1.txt"));
        oos.writeObject(childObj); //Writing child class object and not parent class object
        System.out.println("Writing complete !");
    } catch (IOException e) {
    }


}
}

Apri MyData1.txt e cerca il membro privato chiamato "bhavesh". Per favore fatemi sapere cosa ne pensate ragazzi.

Sembrerebbe che una sottoclasse erediti i campi privati ​​in quanto questi stessi campi sono utilizzati nei meccanismi interni della sottoclasse (filosoficamente parlando). Una sottoclasse, nel suo costruttore, chiama il costruttore della superclasse. I campi privati ​​della superclasse sono ovviamente ereditati dalla sottoclasse che chiama il costruttore della superclasse se il costruttore della superclasse ha inizializzato questi campi nel suo costruttore. Questo è solo un esempio. Ma ovviamente senza metodi di accesso la sottoclasse non può accedere ai campi privati ​​della superclasse (è come non poter aprire il pannello posteriore di un iPhone per estrarre la batteria per ripristinare il telefono ... ma la batteria è ancora lì).

PS Una delle molte definizioni di eredità che ho incontrato: "Eredità - una tecnica di programmazione che consente a una classe derivata di estendere la funzionalità di una classe base, ereditando tutto il suo STATO (l'enfasi è mia) e il comportamento".

I campi privati, anche se non accessibili dalla sottoclasse, sono lo stato ereditato della superclasse.

Dovrei rispondere che i campi privati ​​in Java sono ereditati. Mi permetta di dimostrare:

public class Foo {

    private int x; // This is the private field.

    public Foo() {
        x = 0; // Sets int x to 0.
    }

    //The following methods are declared "final" so that they can't be overridden.
    public final void update() { x++; } // Increments x by 1.
    public final int getX() { return x; } // Returns the x value.

}


public class Bar extends Foo {

    public Bar() {

        super(); // Because this extends a class with a constructor, it is required to run before anything else.

        update(); //Runs the inherited update() method twice
        update();
        System.out.println(getX()); // Prints the inherited "x" int.

    }

}

Se esegui un programma Bar bar = new Bar();, vedrai sempre il numero "2" nella casella di output. Poiché il numero intero "x" è incapsulato con i metodi update()e getX(), è possibile dimostrare che il numero intero è ereditato.

La confusione è che, poiché non è possibile accedere direttamente all'intero "x", le persone sostengono che non è ereditato. Tuttavia, ogni cosa non statica in una classe, sia essa campo o metodo, viene ereditata.

I bit di padding / Allineamento e l'inclusione della classe di oggetti in VTABLE non sono considerati. Quindi l'oggetto della sottoclasse ha un posto per i membri privati ​​della classe Super. Tuttavia, non è possibile accedervi dagli oggetti della sottoclasse ...

No , i campi privati ​​non vengono ereditati. L'unica ragione è che la sottoclasse non può accedervi direttamente .

Credo che la risposta dipenda totalmente dalla domanda che è stata posta. Voglio dire, se la domanda è

Possiamo accedere direttamente al campo privato della superclasse dalla loro sottoclasse?

Quindi la risposta è No , se esaminiamo i dettagli dell'identificatore di accesso , viene menzionato, i membri privati ​​sono accessibili solo all'interno della classe stessa.

Ma, se la domanda è

Possiamo accedere al campo privato della superclasse dalla loro sottoclasse?

Ciò significa che non importa cosa farai per accedere al membro privato. In tal caso, possiamo rendere il metodo pubblico nella superclasse e puoi accedere al membro privato. Quindi, in questo caso, stai creando un'interfaccia / bridge per accedere al membro privato.

Altri linguaggi OOP come C ++ hanno il friend functionconcetto, tramite il quale possiamo accedere al membro privato di un'altra classe.

Possiamo semplicemente affermare che quando una superclasse viene ereditata, i membri privati ​​della superclasse diventano effettivamente membri privati ​​della sottoclasse e non possono essere ulteriormente ereditati o non sono accessibili agli oggetti della sottoclasse.

Un membro o costruttore della classe privata è accessibile solo all'interno del corpo della classe di livello superiore ( §7.6 ) che racchiude la dichiarazione del membro o del costruttore. Non è ereditato da sottoclassi. https://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#jls-6.6

Una sottoclasse non eredita i membri privati ​​della sua classe genitore. Tuttavia, se la superclasse ha metodi pubblici o protetti per accedere ai suoi campi privati, questi possono essere utilizzati anche dalla sottoclasse.

I membri privati ​​(stato e comportamento) sono ereditati. Possono (possono) influenzare il comportamento e le dimensioni dell'oggetto che viene istanziato dalla classe. Per non parlare del fatto che sono molto ben visibili alle sottoclassi attraverso tutti i meccanismi di interruzione dell'incarnazione disponibili o che possono essere assunti dai loro implementatori.

Sebbene l'ereditarietà abbia una definizione di "defacto", sicuramente non ha alcun collegamento con gli aspetti di "visibilità", che vengono assunti dalle risposte "no".

Quindi, non è necessario essere diplomatici. A questo punto JLS ha torto.

Qualsiasi supposizione che non siano "ereditati" è pericolosa e pericolosa.

Quindi tra due definizioni defacto (parzialmente) contrastanti (che non ripeterò), l'unica che dovrebbe essere seguita è quella più sicura (o sicura).