Czy podklasy dziedziczą pola prywatne?


245

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?


33
Byłem kiedyś w podobnej sytuacji i zdałem sobie sprawę, że nawet nie chcę pracować dla firmy, w której ankieter wie mniej o Javie niż ja. :)
biziclop,

48
Ankieter czasami nie zgadza się z tobą, nawet jeśli wie, że masz rację. Dobry ankieter spróbuje dowiedzieć się o Tobie więcej niż wiedzy technicznej.
Andy Thomas,

4
@DigitalRoss Czy specyfikacja języka Java jest również źle napisana? Zobacz odpowiedź RD01: stackoverflow.com/questions/4716040/…
OscarRyz

9
@Andy Thomas-Cramer Nie chciałbym też pracować z ludźmi, którzy celowo kłamią, aby przetestować moją reakcję.
biziclop

4
Cóż, myślę, że powinniśmy najpierw zrozumieć znaczenie „dziedziczenia” w Javie. Podklasa nie ma pola prywatnego, a podklasa ma pole prywatne, ale dostęp do niego nie jest różny, które odnoszą się do dokładnego znaczenia dziedziczenia w Javie?
MengT

Odpowiedzi:


238

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 :)


3
@ cyfrowy dlaczego westchnienie. Rozumiem, że uważasz, że masz rację. Nie zgadzam się z tobą, że dziedziczenie obiektów jest tym, o czym uczy się większość programistów. Ale definicja JLS dotyczy bezpośrednio pierwotnego pytania. To semantyka tak, ale JLS określa definicję, a nie ty lub ja.
robert_x44,

4
Jednym ze sposobów na pogodzenie tego wszystkiego jest po prostu uznanie, że słowo „dziedziczenie” jest używane na dwa bardzo różne sposoby do opisania relacji klas pochodnych i nadrzędnych, przynajmniej w świecie Java. Tak, JSL jest autorytatywny. Tak, oznacza to, że możesz używać „dziedziczenia” w ten niefortunny sposób. Ale nadal jest oczywiście prawdą, że podklasy żabią (bo teraz nie mamy słowa) prywatne pola ich klasy nadrzędnej.
DigitalRoss,

1
@digital Są przedmiotem zajęć. nie sama klasa. Simula nazywała je konkatenowanymi obiektami. Kiedy utworzono obiekt podklasy, składał się on z połączonych „obiektów przedrostków”. Obiekt nadklasy był obiektem przedrostka, który sam mógł zawierać inne obiekty przedrostków. Myślę, że arogancją jest powiedzieć, że JLS ma „wyraźnie złe sformułowanie”. Jeśli chodzi o to, jakiego słowa używamy, dziedziczenie oczywiście. Nie ma nic złego w stosowaniu nieco dwuznacznej terminologii. To się zdarza cały czas. Ale to nie znaczy, że nie ma dokładnej definicji.
robert_x44

1
@digital Z pewnością możemy zgodzić się, że słowo to jest używane na różne sposoby. :) Prawdopodobnie możemy się również zgodzić, że pytanie, które zależy od dwuznacznego terminu, prawdopodobnie nie jest dobre.
robert_x44

2
Czy ktoś ma odniesienie z Java / Oracle dla „Obiekty podklasy zawierają prywatne pola ich nadklas”? Zgadzam się z tym, ale nie mogę znaleźć żadnych oficjalnych dokumentów mówiących o tym.
MengT

78

tak

Ważne jest, aby zdać sobie sprawę, że choć 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.


2
@ Ma99uS. Oczywiście są ponownie wykorzystywane. To jest cały punkt dziedziczenia. Bez nich typ pochodny nie byłby i nie mógłby być instancją typu nadrzędnego. OOP byłby bez znaczenia. Typy polimorficzne przestałyby działać . Zrozumienie, że istnieje tylko jeden obiekt i JESTEŚ wystąpienie typu nadrzędnego, jest kluczowe dla zrozumienia OOP. Musisz obejść ten problem, aby go w ogóle zrozumieć.
DigitalRoss,

2
Nie jestem pewien, czy przykład ojca jest bardzo dobry, ponieważ pole może być dziedziczone, podczas gdy klasa nadrzędna wciąż żyje i ma również to pole. Gdyby dziedziczenie działało w ten sposób, mógłbym odziedziczyć pieniądze mojego ojca, gdy on żyje, i on mógł zatrzymać te same pieniądze. Moje dzieci będą miały swoje pieniądze i moje pieniądze.
Peter Lawrey,

2
@Peter Lawrey nie kłócił się ani nic, ale oto, co myślę. Rodzic miał car, trzymał go w privateszafce, której dziecko nie ma klucza. Rzeczywiście dziedziczysz, carale jest to dla ciebie bezużyteczne. Tak więc praktycznie nie czerpiesz korzyści z dziedziczenia.
Nishant,

1
@DigitalRoss. Wiem o co ci chodzi. Mhh, moglibyśmy powiedzieć, że wartość tam jest, ponieważ załadowana jest również nie odziedziczona definicja rodzica . :) Myślę, że specyfikacja JVM miałaby poprawną odpowiedź na to „NO WORD”, którego szukamy. java.sun.com/docs/books/jvms
OscarRyz

5
-1, specyfikacja języka Java wyraźnie określa, że ​​nie są one dziedziczone. Nie, jeśli, nie ma ale. Po prostu nie są. Każda inna definicja dziedziczenia jest niepoprawna w kontekście Java.
biziclop

21

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.

 


2
To nie jest poprawne. Nie masz do nich dostępu, to prawda. Ale muszą zostać odziedziczone, jak wyjaśniłem.
DigitalRoss,

1
doskonała odpowiedź !!! +1 za I believe it's purely matter of point-of-view.ijustified the existence of protected modifier.
Ravi

14

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.


Poprawny. Ale myślę, że w takim podstawowym pytaniu powinny być wspólne odpowiedzi)
Stan Kurilin

Myślę, że jest to Java definicja dziedziczenia.
OscarRyz 17.01.11

Albo zależy to od twojej definicji „pola”. Aby zdefiniować pole liczb całkowitych „foo”, należy wynająć szafkę do przechowywania liczb całkowitych i umieścić na niej znak „foo”. Jeśli pole zostanie uznane za prywatne, klasa pochodna dziedziczy szafkę pamięci o rozmiarze całkowitym bez etykiety. To, czy klasa pochodna dziedziczy „pole”, zależy od tego, czy nazywa się to nieznakowane urządzenie do przechowywania danych „polem”.
supercat

10

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

10

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


:) Następnym razem można skorzystać z szansy, aby wyjaśnić swój wywiad, gdzie jest on / ona źle, a to może dać Ci dodatkowe punkty;) Oczywiście należy zrobić to w dyplomatyczny sposób poprawny.
OscarRyz 17.01.11

1
Oni mają być dziedziczone przez typy polimorficzne mieć żadnego znaczenia. Zobacz moje wyjaśnienie. To prawda, że ​​nie możesz się nimi bawić, ale oni tam są. One mają być.
DigitalRoss,

W kodzie nie ma słów kluczowych dotyczących dziedziczenia (rozszerzenia / implementacji), więc nie jest to przykład dziedziczenia.
fmucar,

1
Jeśli tam są, to jak się tam dostali? Ponieważ podklasa je zdefiniowała? Nie. Ponieważ byli odziedziczeni ?
DigitalRoss,

1
Świetna uwaga w encapsulationporównaniu inherit, myślę, że ta odpowiedź zasługuje na więcej głosów.
Eric Wang,

6

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.


2
Zgodnie z dokumentem Oracle - 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ę.
dganesh2002

4

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.


3

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.


1

Musiałbym odpowiedzieć, że prywatne pola w Javie 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.


3
„Zawiera” nie znaczy „dziedziczy”;)
Stan Kurilin

1

Układ pamięci w Javie względem dziedziczenia

wprowadź opis zdjęcia tutaj

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


1

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


0

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.


0

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.



-1

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ę.


-2

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).


1
-1. JLS definiuje język, nie jest możliwe, aby JLS był „zły”. Ponadto, jeśli istnieją mechanizmy, które przerywają enkapsulację, nie oznacza to, że pole jest dziedziczone; tylko że istnieją mechanizmy, które podważają enkapsulację.
SL Barth - Przywróć Monikę

Definicja może sama w sobie być niepoprawna na kilka sposobów. Dalsze omawianie tego nie jest moim zamiarem. Argument tutaj nie dotyczy mechanizmów, które niszczą enkapsulację (boga lub złego, jakie mogą być), ale faktu, że pole / metoda istnieje, wpływając na zachowanie i stan twojej podklasy. Jest więc „odziedziczony”. Można użyć prywatnej tablicy bajtów 100 kb w klasie i założyć, że jego potomkowie (jumbo) nie dziedziczą jej. Nie przegap tego i oceniaj to jako dobrą lub złą praktykę (przesada pomaga w zrozumieniu sprawy): jest to przewidywane, uzasadnione działanie. Członkowie prywatni są „odziedziczeni”.
gkakas
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.