Czy podklasy dziedziczą pola prywatne?

Tak

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

Aktualizacja:

Err, " Nie "

Update to update:

Kontrowersja tutaj wiąże się z fundamentalną dwuznacznością: o czym dokładnie się dyskutuje? obiekt?Czy mówimy w jakimś sensie o samej klasie? duża szerokość geograficzna jest dozwolona podczas opisywania klasy w przeciwieństwie do obiektu. Tak więc podklasa nie dziedziczy prywatnych pól, ale obiekt będący instancją podklasy z pewnością zawiera prywatne pola.

Nie. Pola prywatne nie są dziedziczone... i dlatego wynaleziono Protected. Jest z założenia. To chyba uzasadniało istnienie chronionego modyfikatora.

Teraz do kontekstu. Co masz na myśli przez dziedziczenie -- jeśli jest tam w obiekcie utworzonym z klasy pochodnej? tak.

Jeśli masz na myśli, czy może być przydatna Klasa pochodna. Nie.

Teraz, kiedy przejdziesz do programowania funkcyjnego prywatne pole super klasy nie jest dziedziczone w znacząca droga dla podklasy . Dla podklasy, prywatne pole super klasy jest takie samo jak prywatne pole każdej innej klasy.

funkcjonalnie nie jest dziedziczona. Ale najlepiej , jest.

OK, po prostu zajrzałem do samouczka Javy cytują to:

Użytkownicy prywatni w Superklasie

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

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

Zgadzam się, że pole tam jest. Ale podklasa nie ma żadnych przywilejów na tym prywatnym polu. W podklasie pole prywatne jest takie samo jak każde pole prywatne innej klasy.

uważam, że to kwestia punktu widzenia. Możesz uformować argument po obu stronach. It ' s better justify w obie strony.

To zależy od twojej definicji "dziedziczyć". Czy podklasa nadal ma pola w pamięci? Zdecydowanie. Czy ma do nich bezpośredni dostęp? Nie. Chodzi o to, żeby zrozumieć, co się naprawdę dzieje.

Zademonstruję tę koncepcję kodem. Podklasy faktycznie dziedziczą prywatne zmienne super klasy. Jedynym problemem jest to, że nie są one dostępne dla obiekty potomne, chyba że udostępnisz publiczne gettery i settery dla zmiennych prywatnych w super klasie.

Rozważmy dwie klasy w zrzucie pakietów. Dziecko rozszerza rodzica.

Jeśli dobrze pamiętam, obiekt potomny w pamięci składa się z dwóch regionów. Jedna jest tylko częścią nadrzędną, a druga to tylko część dziecięca. Dziecko ma dostęp do prywatnego sekcja w kodzie rodzica tylko za pomocą publicznej metody w rodzicu.

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 odziedziczą go.

Fakt, że inna klasa może go używać 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 również uzyskać wartość count wewnątrz UseIt poprzez odbicie. To nie znaczy, że dziedziczysz.

UPDATE

Mimo że wartość jest tam, 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?           
     }
}

To jest dokładnie to samo sytuacja jako pierwszy przykład. Atrybut {[3] } jest ukryty i nie jest dziedziczony przez podklasę w ogóle. Mimo to, jak wskazuje DigitalRoss, wartość jest tam, ale nie w drodze dziedziczenia.

Inne update

To jest bardzo interesujące, choć, aby wiedzieć, dlaczego atrybut tam jest.

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

Możemy zmienić rodzica i podklasa nadal będzie 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 maszyny Wirtualnej JavaTM

Cóż, moja odpowiedź na pytanie ankietera brzmi - prywatne członkowie nie są dziedziczone w podklasach, ale są dostępne dla podklasy lub obiektu podklasy tylko za pomocą publicznych metod getter lub setter lub dowolnych odpowiednich metod oryginalnej klasy. normalną praktyką jest zachowanie prywatności członków i dostęp do nich przy użyciu metod getter i setter, które są publiczne. Więc jaki jest sens dziedziczyć tylko metody getter i setter, gdy prywatny członek, z którym mają do czynienia, nie jest dostępne dla obiektu? Tutaj 'dziedziczenie' oznacza po prostu, że jest dostępne bezpośrednio w podklasie, aby bawić się nowo wprowadzonymi 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ć prywatnej zmiennej x Klasy ParentClass w metodzie podklasy, to nie jest ona bezpośrednio dostępna dla żadnych modyfikacji (czyli nie dziedziczona). Ale x można modyfikować w podklasie za pomocą metody setX() oryginalnej klasy, tak jak to robi się w setXofParent() metoda lub może być modyfikowana przy użyciu obiektu klasy potomnej przy użyciu metody setX() lub metody setXofParent (), która ostatecznie wywołuje setX (). Tak więc setX () i getX() są rodzajami bram do prywatnego członka x Klasy ParentClass.

Innym prostym przykładem jest Clock superclass ma godziny i minuty jako członków prywatnych i odpowiednie metody getter i setter jako publiczne. Następnie jest DigitalClock jako podklasa zegara. Tutaj jeśli obiekt DigitalClock nie zawiera członków hours and mins, to rzeczy są nawaliło.

Ok, jest to bardzo interesujący problem, który zbadałem i doszedłem do wniosku, że prywatni członkowie superklasy są rzeczywiście dostępni (ale niedostępni) w obiektach podklasy. Aby to udowodnić, oto przykładowy kod z klasą rodzica i klasą potomną i piszę obiekt klasy potomnej do pliku txt i czytam prywatnego członka o nazwie 'bhavesh' w pliku, udowadniając tym samym, że jest on rzeczywiście dostępny w klasie potomnej, ale nie jest dostępny ze względu na dostęp modyfikator.

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 imieniu 'bhavesh'. Dajcie mi znać, co myślicie.

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

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

Pola prywatne, nawet jeśli nie dostępne przez podklasę, są dziedziczonym stanem klasy nadrzędnej.

Wypełnienie bitów/wyrównanie i włączenie klasy obiektu do VTABLE nie jest brane pod uwagę. Więc obiekt podklasy ma miejsce dla prywatnych członków Super klasy. Nie można jednak uzyskać do niego dostępu z obiektów podklasy...

Uważam, że odpowiedź jest całkowicie zależna od pytania, które zostało zadane. Jeśli pytanie jest

Czy możemy bezpośrednio uzyskać dostęp do prywatnego pola super-klasy z ich podklasa ?

Wtedy odpowiedź brzmi No , jeśli przejdziemy przez szczegóły specyfikacji dostępu , to jest wspomniane, że członkowie prywatni są dostępni tylko wewnątrz samej klasy.

Ale jeśli pytanie jest

Czy możemy uzyskać dostęp do prywatnego pola super klasa z ich podklasa ?

Co oznacza, że nie ma znaczenia, co zrobisz, aby uzyskać dostęp do prywatnego członka. W takim przypadku możemy zrobić metodę publiczną w super-klasie i możesz uzyskać dostęp do prywatnego członka. Tak więc, w tym przypadku tworzysz jeden interfejs / most, aby uzyskać dostęp do prywatnego członka.

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

Możemy po prostu stwierdzić, że gdy superklasa jest dziedziczona, to prywatne członkowie superklasy faktycznie stają się prywatnymi członkami podklasy i nie mogą być dalej dziedziczone lub są nieaktywne dla obiektów podklasy.

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

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 liczbę " 2 " w polu wyjściowym. Ponieważ liczba całkowita " x " jest zamknięta za pomocą metod update() i getX(), można udowodnić, że liczba całkowita jest dziedziczona.

Zamieszanie polega na tym, że ponieważ nie możesz bezpośrednio uzyskać dostępu do liczby całkowitej "x", ludzie twierdzą, że nie jest ona dziedziczona. Jednak każdy nie statyczny rzecz w klasie, czy to pole czy metoda, jest dziedziczona.

Prywatny członek klasy lub konstruktor jest dostępny tylko w ciele klasy najwyższego poziomu (§7.6) w załączeniu deklaracja członka lub konstruktora. Nie jest dziedziczona przez podklasy. https://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#jls-6.6

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

Podklasa nie dziedziczy prywatnych członków swojej klasy macierzystej. Jednakże, jeśli Klasa nadrzędna 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ą dziedziczone. Mogą one 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 poprzez wszystkie dostępne mechanizmy łamania enkaptulacji lub mogą być zakładane przez ich implementatorów.

Chociaż dziedziczenie ma definicję "defacto", zdecydowanie nie ma związku z aspektami" widoczności", które są zakładane przez odpowiedzi" nie".

Więc nie ma trzeba być dyplomatycznym. JLS się myli.

Każde założenie, że nie są "dziedziczone", jest niebezpieczne i niebezpieczne.

Tak więc wśród dwóch (częściowo) sprzecznych definicji defacto (których Nie będę powtarzał), jedyną, która powinna być przestrzegana, jest ta, która jest bezpieczniejsza (lub bezpieczna).