Czy podklasy dziedziczą pola prywatne?

To pytanie do wywiadu.

Czy podklasy dziedziczą pola prywatne?

Odpowiedziałem „Nie”, ponieważ nie możemy uzyskać do nich dostępu w „normalny sposób OOP”. Jednak ankieter uważa, że ​​są one dziedziczone, ponieważ możemy uzyskać dostęp do takich pól pośrednio lub za pomocą odbicia i nadal istnieją w obiekcie.

Po powrocie znalazłem w javadoc następujący cytat :

Członkowie prywatni w nadklasie

Podklasa nie dziedziczy prywatnych członków swojej klasy nadrzędnej.

Czy znasz jakieś argumenty za opinią ankietera?

Większość zamieszania w tym pytaniu / odpowiedzi otacza definicję dziedziczenia.

Oczywiście, jak wyjaśnia @DigitalRoss, OBIEKT podklasy musi zawierać prywatne pola swojej nadklasy. Jak twierdzi, brak dostępu do prywatnego członka nie oznacza, że ​​go tam nie ma.

Jednak. To różni się od pojęcia dziedziczenia dla klasy. Tak jak ma to miejsce w świecie java, gdzie jest kwestia semantyki, arbitrem jest specyfikacja języka Java (obecnie 3. edycja).

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

Członkowie klasy, którzy zostali zadeklarowani jako prywatni, nie są dziedziczeni przez podklasy tej klasy. Tylko członkowie klasy, które są zadeklarowane jako chronione lub publiczne, są dziedziczone przez podklasy zadeklarowane w pakiecie innym niż ten, w którym klasa jest zadeklarowana.

Te adresy dokładny pytanie postawione przez ankietera: „Czy sub ZAJĘCIA dziedziczyć pól prywatnych”. (podkreślenie dodane przeze mnie)

Odpowiedź brzmi: nie. Nie. OBIEKTY podklas zawierają prywatne pola ich nadklas. Sama podklasa NIE MA POJĘĆ prywatnych pól swojej nadklasy.

Czy to semantyka o charakterze pedantycznym? Tak. Czy to przydatne pytanie do rozmowy kwalifikacyjnej? Prawdopodobnie nie. Ale JLS ustanawia definicję świata Java i robi to (w tym przypadku) jednoznacznie.

ZMIENIONO (usunięto równoległy cytat z Bjarne Stroustrup, który ze względu na różnice między Javą i c ++ prawdopodobnie tylko zwiększa zamieszanie. Pozwolę mojej odpowiedzi spoczywać na JLS :)

tak

Ważne jest, aby zdać sobie sprawę, że choć są dwie klasy, istnieje tylko jeden obiekt.

Tak, oczywiście, że odziedziczył prywatne pola. Przypuszczalnie są one niezbędne dla prawidłowej funkcjonalności obiektu i chociaż obiekt klasy nadrzędnej nie jest obiektem klasy pochodnej, instancja klasy pochodnej jest zdecydowanie zdecydowanie instancją klasy nadrzędnej. Nie byłoby tak dobrze bez wszystkich pól.

Nie, nie możesz uzyskać do nich bezpośredniego dostępu. Tak, są dziedziczone. One mają być.

To dobre pytanie!

Aktualizacja:

Err, „Nie”

Cóż, chyba wszyscy się czegoś nauczyliśmy. Ponieważ JLS wywodzi się z dokładnego sformułowania „nie odziedziczone”, prawidłowa jest odpowiedź „nie” . Ponieważ podklasa nie może uzyskać dostępu do pól prywatnych ani modyfikować ich, innymi słowy nie są one dziedziczone. Ale tak naprawdę jest tylko jeden obiekt, to naprawdę zawiera prywatne pola, więc jeśli ktoś źle zrozumie JLS i samouczek, bardzo trudno będzie zrozumieć OOP, obiekty Java i to, co się naprawdę dzieje.

Zaktualizuj, aby zaktualizować:

Kontrowersje wiążą się z podstawową dwuznacznością: co dokładnie jest omawiane? Obiekt? Czy mówimy w pewnym sensie o samej klasie? Dozwolona jest duża swoboda przy opisywaniu klasy, a nie obiektu. Podklasa nie dziedziczy więc pól prywatnych, ale obiekt będący instancją podklasy z pewnością zawiera pola prywatne.

Nie. Prywatne pola nie są dziedziczone ... i dlatego wymyślono Protected . To jest z założenia. Myślę, że to uzasadnia istnienie chronionego modyfikatora.

Teraz dochodzę do kontekstów. Co rozumiesz przez odziedziczony - jeśli istnieje w obiekcie utworzonym z klasy pochodnej? Tak to jest.

Jeśli masz na myśli, czy może być użyteczne dla klasy pochodnej. Więc nie.

Jeśli chodzi o programowanie funkcjonalne, prywatne pole superklasy nie jest dziedziczone w znaczący sposób dla podklasy . W przypadku podklasy prywatne pole superklasy jest takie samo jak pole prywatne dowolnej innej klasy.

Funkcjonalnie nie jest dziedziczony. Ale idealnie jest.

OK, właśnie przejrzałem samouczek Java, cytują to:

Członkowie prywatni w nadklasie

Podklasa nie dziedziczy prywatnych członków swojej klasy nadrzędnej. Jeśli jednak nadklasa ma publiczne lub chronione metody dostępu do swoich prywatnych pól, mogą one być również używane przez podklasę.

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

Zgadzam się, że pole jest na miejscu. Ale podklasa nie ma żadnych uprawnień w tym prywatnym polu. W przypadku podklasy pole prywatne jest takie samo, jak każde pole prywatne dowolnej innej klasy.

Uważam, że jest to wyłącznie kwestia punktu widzenia. Możesz uformować argument po obu stronach. Lepiej to uzasadnić w obie strony.

To zależy od twojej definicji „dziedziczenia”. Czy podklasa nadal ma pola w pamięci? Zdecydowanie. Czy może uzyskać do nich bezpośredni dostęp? Nie. To tylko subtelności definicji; chodzi o to, aby zrozumieć, co się naprawdę dzieje.

Zaprezentuję koncepcję za pomocą kodu. Podklasy RZECZYWISTY dziedziczą prywatne zmienne nadklasy. Jedynym problemem jest to, że nie są one dostępne dla obiektów potomnych, chyba że podasz publiczne obiekty pobierające i ustawiające dla zmiennych prywatnych w superklasie.

Rozważ dwie klasy w pakiecie Zrzut. Dziecko przedłuża rodzica.

Jeśli dobrze pamiętam, obiekt potomny w pamięci składa się z dwóch regionów. Jeden jest tylko częścią nadrzędną, a drugi tylko częścią podrzędną. Dziecko może uzyskać dostęp do sekcji prywatnej w kodzie swojego rodzica tylko za pomocą publicznej metody w rodzicu.

Pomyśl o tym w ten sposób. Ojciec Borata, Boltok, ma sejf o wartości 100 000 $. Nie chce udostępniać swojej „prywatnej” zmiennej sejf. Nie zapewnia więc klucza do sejfu. Borat dziedziczy sejf. Ale co to za korzyść, jeśli nawet nie może go otworzyć? Gdyby tylko jego ojciec dostarczył klucz.

Rodzic -

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

Dziecko -

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

Nie. Nie dziedziczą tego.

Fakt, że niektóre inne klasy mogą z niego korzystać pośrednio, nie mówi nic o dziedziczeniu, ale o enkapsulacji.

Na przykład:

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?
     }
}

Możesz także uzyskać wartość countwnętrza UseItpoprzez odbicie. To nie znaczy, że odziedziczysz to.

AKTUALIZACJA

Mimo że wartość istnieje, nie jest dziedziczona przez podklasę.

Na przykład podklasa zdefiniowana jako:

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?           
     }
}

Jest to dokładnie taka sama sytuacja jak w pierwszym przykładzie. Atrybut countjest ukryty i wcale nie jest dziedziczony przez podklasę. Mimo to, jak wskazuje DigitalRoss, wartość istnieje, ale nie w przypadku dziedziczenia.

To w ten sposób. Jeśli twój ojciec jest bogaty i daje ci kartę kredytową, nadal możesz kupić coś za jego pieniądze, ale to nie znaczy, że odziedziczyłeś te pieniądze, prawda?

Inna aktualizacja

To bardzo interesujące, aby wiedzieć, dlaczego istnieje ten atrybut.

Szczerze mówiąc, nie mam dokładnego terminu, aby to opisać, ale jest to JVM i sposób, w jaki działa, który ładuje również definicję rodzica „nie odziedziczoną”.

Możemy faktycznie zmienić element nadrzędny, a podklasa będzie nadal działać.

Na przykład :

//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

Myślę, że dokładny termin można znaleźć tutaj: Specyfikacja wirtualnej maszyny JavaTM

Cóż, moja odpowiedź na pytanie ankietera brzmi - członkowie prywatni nie są dziedziczeni w podklasach, ale są dostępni do podklasy lub obiektu podklasy tylko za pomocą publicznych metod pobierających lub ustawiających lub dowolnych odpowiednich metod klasy oryginalnej. Normalną praktyką jest utrzymywanie członków w tajemnicy i dostęp do nich za pomocą metod pobierających i ustawiających, które są publiczne. Jaki jest więc sens dziedziczenia metod pobierających i ustawiających tylko wtedy, gdy prywatny członek, z którym mają do czynienia, nie jest dostępny dla obiektu? Tutaj „odziedziczony” oznacza po prostu, że jest dostępny bezpośrednio w podklasie, aby bawić się nowymi metodami w podklasie.

Zapisz poniższy plik jako ParentClass.java i spróbuj sam ->

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

Jeśli spróbujemy użyć zmiennej prywatnej x ParentClass w metodzie SubClass, nie będzie ona bezpośrednio dostępna dla żadnych modyfikacji (oznacza, że ​​nie jest dziedziczona). Ale x można zmodyfikować w SubClass za pomocą metody setX () oryginalnej klasy, tak jak w metodzie setXofParent () LUB można go zmodyfikować za pomocą obiektu ChildClass za pomocą metody setX () lub metody setXofParent (), która ostatecznie wywołuje setX (). Zatem setX () i getX () są jakby bramami do prywatnego członka x klasy ParentClass.

Innym prostym przykładem jest to, że nadklasa zegara ma godziny i minuty jako prywatni członkowie oraz odpowiednie metody pobierające i ustawiające jako publiczne. Potem pojawia się DigitalClock jako podklasa zegara. Tutaj, jeśli obiekt DigitalClock nie zawiera godzin i członków min, wtedy wszystko jest popsute.

Ok, to jest bardzo interesujący problem, który dużo badałem i doszedłem do wniosku, że prywatni członkowie nadklasy są rzeczywiście dostępni (ale nie dostępni) w obiektach tej podklasy. Aby to udowodnić, oto przykładowy kod z klasą nadrzędną i klasą podrzędną. Piszę obiekt klasy podrzędnej do pliku txt i czytam w nim prywatnego członka o nazwie „bhavesh”, co dowodzi, że jest on rzeczywiście dostępny w podrzędnym pliku klasa, ale niedostępna z powodu modyfikatora dostępu.

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) {
    }


}
}

Otwórz MyData1.txt i wyszukaj prywatnego członka o nazwie „bhavesh”. Daj mi znać, co myślicie.

Wydaje się, że podklasa dziedziczy pola prywatne, ponieważ te właśnie pola są wykorzystywane w wewnętrznych działaniach podklasy (mówiąc filozoficznie). Podklasa w swoim konstruktorze wywołuje konstruktor nadklasy. Prywatne pola nadklasy są oczywiście dziedziczone przez podklasę wywołującą konstruktor nadklasy, jeśli konstruktor nadklasy zainicjował te pola w swoim konstruktorze. To tylko przykład. Ale oczywiście bez metod akcesoryjnych podklasa nie może uzyskać dostępu do prywatnych pól nadklasy (to tak, jakby nie móc wysunąć tylnego panelu iPhone'a, aby wyjąć baterię, aby zresetować telefon ... ale bateria wciąż tam jest).

PS Jedna z wielu definicji dziedziczenia, z którymi się zetknąłem: „Dziedziczenie - technika programowania, która pozwala klasie pochodnej rozszerzyć funkcjonalność klasy podstawowej, dziedzicząc cały jej STAN (nacisk jest mój) i zachowanie”.

Pola prywatne, nawet jeśli nie są dostępne dla podklasy, są dziedziczonym stanem nadklasy.

Musiałbym odpowiedzieć, że prywatne pola w Javie są dziedziczone. Pozwól mi zademonstrować:

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.

    }

}

Jeśli uruchomisz program Bar bar = new Bar();, zawsze zobaczysz cyfrę „2” w polu wyjściowym. Ponieważ całkowita „X” jest zamknięty z metodami update()i getX(), po czym można wykazać, że liczba całkowita jest dziedziczona.

Problem polega na tym, że ponieważ nie można uzyskać bezpośredniego dostępu do liczby całkowitej „x”, ludzie twierdzą, że nie jest ona dziedziczona. Jednak każda niestatyczna rzecz w klasie, czy to pole, czy metoda, jest dziedziczona.

Bity wypełniające / wyrównanie oraz włączenie klasy obiektu do VTABLE nie jest brane pod uwagę. Zatem przedmiot tej podklasy ma miejsce dla prywatnych członków klasy Super. Jednak nie można uzyskać do niego dostępu z obiektów podklasy ...

Nie , pola prywatne nie są dziedziczone. Jedynym powodem jest to, że podklasa nie ma do nich bezpośredniego dostępu .

Uważam, że odpowiedź jest całkowicie zależna od postawionego pytania. Mam na myśli, jeśli pytanie jest

Czy możemy bezpośrednio uzyskać dostęp do prywatnego pola superklasy z jej podklasy?

Zatem odpowiedź brzmi Nie , jeśli przejdziemy przez szczegóły dotyczące specyfikatora dostępu , wspomniano, że członkowie prywatni są dostępni tylko w obrębie samej klasy.

Ale jeśli pytanie jest

Czy możemy uzyskać dostęp do prywatnego pola superklasy z jej podklasy?

Co oznacza, że ​​nie ma znaczenia, co zrobisz, aby uzyskać dostęp do członka prywatnego. W takim przypadku możemy wprowadzić metodę publiczną w superklasie i uzyskać dostęp do członka prywatnego. W takim przypadku tworzysz jeden interfejs / most, aby uzyskać dostęp do członka prywatnego.

Inne języki OOP, takie jak C ++, mają friend functionkoncepcję, dzięki której możemy uzyskać dostęp do prywatnego członka innej klasy.

Możemy po prostu stwierdzić, że kiedy dziedziczona jest nadklasa, wówczas prywatni członkowie nadklasy faktycznie stają się prywatnymi członkami podklasy i nie mogą być dalej dziedziczeni lub są niedostępni dla obiektów tej podklasy.

Członek lub konstruktor klasy prywatnej jest dostępny tylko w treści klasy najwyższego poziomu ( §7.6 ), która zawiera deklarację członka lub konstruktora. Nie jest dziedziczony przez podklasy. https://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#jls-6.6

Podklasa nie dziedziczy prywatnych członków swojej klasy nadrzędnej. Jeśli jednak nadklasa ma publiczne lub chronione metody dostępu do swoich prywatnych pól, mogą one być również używane przez podklasę.

Członkowie prywatni (stan i zachowanie) są dziedziczeni. Mogą (mogą) wpływać na zachowanie i rozmiar obiektu, który jest tworzony przez klasę. Nie wspominając już o tym, że są one bardzo dobrze widoczne dla podklas za pośrednictwem wszystkich mechanizmów łamania kodowania, które są dostępne lub mogą zostać przyjęte przez ich implementatorów.

Mimo że dziedziczenie ma definicję „defacto”, zdecydowanie nie ma powiązania z aspektami „widoczności”, które przyjmują odpowiedzi „nie”.

Tak więc nie ma potrzeby być dyplomatą. W tym momencie JLS się myli.

Każde założenie, że nie są „odziedziczone”, jest niebezpieczne i niebezpieczne.

Tak więc wśród dwóch definicji defacto (częściowo) sprzecznych (których nie powtórzę), jedyną, którą należy zastosować, jest ta, która jest bezpieczniejsza (lub bezpieczna).