Чи підзаклади успадковують приватні поля?

Це питання інтерв'ю.

Чи підкласи успадковують приватні поля?

Я відповів "Ні", тому що ми не можемо отримати доступ до них за допомогою "звичайного способу OOP". Але інтерв'юер вважає, що вони успадковуються, оскільки ми можемо отримати доступ до таких полів опосередковано або за допомогою рефлексії, і вони все ще існують в об'єкті.

Після повернення я знайшов таку цитату в javadoc :

Приватні члени в суперкласі

Підклас не успадковує приватних членів свого батьківського класу.

Чи знаєте ви якісь аргументи на думку інтерв'юера?

Більшість плутанини у питанні / відповідях тут оточує визначення спадкування.

Очевидно, як @DigitalRoss пояснює, ОБ'ЄКТ підкласу повинен містити приватні поля його надкласу. За його словами, відсутність доступу до приватного члена не означає, що його там немає.

Однак. Це відрізняється від поняття спадкування для класу. Як і у світі java, де питання про семантику арбітром є специфікація мови Java (на даний момент 3-е видання).

Як зазначає JLS ( https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.2 ):

Члени класу, які оголошені приватними, не успадковуються підкласами цього класу. Тільки члени класу, які оголошені захищеними або загальнодоступними, успадковуються підкласами, оголошеними в пакеті, відмінному від того, в якому оголошено клас.

Це стосується точного питання, яке задає інтерв'юер: " підкази кластери успадковують приватні поля". (акцент додав я)

Відповідь - ні. Вони цього не роблять. ОБ'ЄКТИ підкласів містять приватні поля їхніх суперкласів. Сам підклас НЕ ПОВІДОМЛЯ про приватні поля свого надкласу.

Це семантика педантичного характеру? Так. Це корисне запитання про інтерв'ю? Напевно, ні. Але JLS встановлює визначення для світу Java, і робить це (в даному випадку) однозначно.

ВЕДЕНО (видалено паралельну цитату з Bjarne Stroustrup, яка через різницю між java та c ++, ймовірно, лише додає плутанини. Я дам свою відповідь на JLS :)

Так

Важливо усвідомити, що хоча є два класи, є лише один об’єкт.

Так, так, звичайно, він успадкував приватні поля. Вони, імовірно, є важливими для належної функціональності об'єкта, і хоча об’єкт батьківського класу не є об'єктом похідного класу, екземпляр похідного класу здебільшого є безумовно екземпляром батьківського класу. Не обходиться без усіх полів.

Ні, ви не можете безпосередньо отримати доступ до них. Так, вони передаються у спадок. Вони повинні бути.

Це гарне запитання!

Оновлення:

Помилка, "Ні"

Ну, мабуть, ми всі чомусь навчились. Оскільки в JLS виникли точні формулювання "не успадковані", правильно відповісти "ні" . Оскільки підклас не може отримати доступ або змінити приватні поля, то, іншими словами, вони не успадковуються. Але дійсно є лише один об’єкт, він дійсно містить приватні поля, і тому, якщо хтось сприймає формулювання JLS та підручника неправильно, зрозуміти об'єкти OOP, Java та те, що насправді відбувається, буде досить важко.

Оновити для оновлення:

Суперечка тут передбачає принципову неоднозначність: про що саме йде мова? Об'єкт? Або ми говоримо в якомусь сенсі про сам клас? Дозволяється велика широта при описі класу на відміну від об'єкта. Отже, підклас не успадковує приватні поля, але об'єкт, який є екземпляром підкласу, безумовно, містить приватні поля.

Ні. Приватні поля не успадковуються ... і саме тому було винайдено захищене . Це за дизайном. Я думаю, це виправдало існування захищеного модифікатора.

Зараз підходимо до контекстів. Що ви маєте на увазі під успадкованим - якщо він є в об'єкті, створеному з похідного класу? Так.

Якщо ви маєте на увазі, чи може це бути корисним для похідного класу. Ну, ні.

Тепер, коли ви переходите до функціонального програмування, приватне поле суперкласу не успадковується змістовно для підкласу . Для підкласу приватне поле суперкласу - це те саме, що приватне поле будь-якого іншого класу.

Функціонально це не передається у спадок. Але в ідеалі це так.

Добре, щойно переглянувши підручник Java, вони цитують це:

Приватні члени в суперкласі

Підклас не успадковує приватних членів свого батьківського класу. Однак якщо у суперкласу є загальнодоступні або захищені методи доступу до його приватних полів, вони також можуть використовуватися підкласом.

посилайтеся: http://download.oracle.com/javase/tutorial/java/IandI/subclasses.html

Я згоден, що поле є. Але підклас не отримує жодної привілеї в цьому приватному полі. Для підкласу приватне поле є таким же, як і будь-яке приватне поле будь-якого іншого класу.

Я вважаю, що це суто питання точки зору. Ви можете сформулювати аргумент з будь-якої сторони. Краще виправдати обидві сторони.

Це залежить від вашого визначення поняття "успадковувати". Чи підклас все ще має поля в пам'яті? Безумовно. Чи може він отримати доступ до них безпосередньо? Ні. Це лише тонкощі визначення; справа в тому, щоб зрозуміти, що насправді відбувається.

Я продемонструю концепцію з кодом. Підкласи РОЗУМНО успадковують приватні змінні суперкласу. Єдина проблема полягає в тому, що вони не доступні дочірнім об'єктам, якщо ви не надаєте загальнодоступні геттери та сетери для приватних змінних у суперкласі.

Розглянемо два класу в пакеті Dump. Дитина продовжує батьків.

Якщо я добре пам’ятаю, дочірній об’єкт в пам’яті складається з двох областей. Один є лише батьківською частиною, а другий - лише дочірньою частиною. Дитина може отримати доступ до приватного розділу в коді свого батька лише публічним методом у батьків.

Думай про це так. У батька Бората Болток є сейф, що містить 100 000 доларів. Він не хоче ділитися своєю "приватною" змінною сейфом. Отже, він не дає ключ для сейфу. Борат успадковує сейф. Але яка користь, якщо він навіть не може відкрити його? Якби тільки тато надав ключ.

Батько -

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

Дитина -

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

Ні. Вони не успадковують це.

Те, що деякі інші класи можуть використовувати це опосередковано, говорить не про спадщину, а про інкапсуляцію.

Наприклад:

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

Ви також можете отримати значення countвсередині UseItза допомогою відображення. Це не означає, ти це успадковуєш.

ОНОВЛЕННЯ

Незважаючи на те, що значення є, воно не успадковується підкласом.

Наприклад, підклас, визначений як:

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

Це точно та сама ситуація, що і перший приклад. Атрибут countприхований і зовсім не успадковується підкласом. Однак, як вказує DigitalRoss, цінність є, але не за допомогою спадкування.

Поставте так. Якщо ваш батько заможний і дає вам кредитну карту, ви все одно можете придбати річ за його гроші, але це не означає, що ви успадкували всі ці гроші, чи не так?

Інше оновлення

Дуже цікаво знати, чому атрибут є.

Я, відверто кажучи, не маю точного терміна, щоб описати це, але саме JVM і спосіб його роботи завантажує також "не успадковане" батьківське визначення.

Ми могли фактично змінити батьківський і підклас все ще буде працювати.

Наприклад :

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

Я думаю, що точний термін можна знайти тут: Специфікація віртуальної машини JavaTM

Ну, моя відповідь на запитання інтерв'юера полягає в тому, що - приватні члени не успадковуються в підкласах, але вони доступні для об'єкта підкласу або підкласу лише за допомогою методів загального доступу або сеттера або будь-яких таких відповідних методів оригінального класу. Звичайною практикою є збереження приватних членів та доступ до них за допомогою методів getter та setter, які є загальнодоступними. Тож у чому лише сенс успадковувати методи геттера та сетера, коли приватний член, з яким вони мають справу, недоступний об'єкту? Тут "успадкований" просто означає, що він доступний безпосередньо в підкласі для розігрування нововведеними методами в підкласі.

Збережіть файл нижче як ParentClass.java і спробуйте його самостійно ->

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

Якщо ми спробуємо використати приватну змінну x ParentClass у методі SubClass, то вона не є безпосередньо доступною для будь-яких модифікацій (засоби не успадковуються). Але x може бути змінено в SubClass за допомогою методу setX () оригінального класу, як це зроблено методом setXofParent () АБО його можна змінити, використовуючи об’єкт ChildClass, використовуючи метод setX () або метод setXofParent (), який в кінцевому підсумку викликає setX (). Отже, тут setX () і getX () є свого роду воротами до приватного члена x ParentClass.

Іншим простим прикладом є суперклас Clock, який має години та хвилини як приватних членів та відповідні методи getter та setter як загальнодоступні. Потім DigitalClock постає як підклас Clock. Ось, якщо об’єкт DigitalClock не містить годин та хвилин, то все накручується.

Гаразд, це дуже цікава проблема, яку я багато досліджував і прийшов до висновку, що приватні члени надкласу дійсно доступні (але недоступні) в об'єктах підкласу. Щоб довести це, ось зразок коду з батьківським класом та дочірнім класом, і я записую об’єкт дочірнього класу у файл txt і читаю у файлі приватного члена з назвою "bhavesh", отже, підтверджуючи, що він дійсно доступний дитині клас, але недоступний через модифікатор доступу.

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


}
}

Відкрийте MyData1.txt і знайдіть приватного члена на ім’я "bhavesh". Будь ласка, дайте мені знати, що ви думаєте.

Здавалося б, підклас наслідує приватні поля тим, що ці самі поля використовуються у внутрішній роботі підкласу (філософсько кажучи). Підклас у своєму конструкторі називає конструктор надкласового. Приватні поля суперкласу, очевидно, успадковуються підкласом, що викликає конструктор надкласового класу, якщо конструктор надкласового класу ініціалізував ці поля у своєму конструкторі. Це лише приклад. Але, звичайно, без методів доступу, підклас не може отримати доступ до приватних полів надкласового класу (це як не в змозі вискочити задню панель iPhone, щоб виймати акумулятор, щоб скинути телефон ... але акумулятор все ще є).

PS Одне з численних визначень успадкування, до яких я потрапив: "Спадкування - техніка програмування, яка дозволяє похідному класу розширити функціональність базового класу, успадкувавши всі його СТАТИ (акцент - мій) та поведінку".

Приватні поля, навіть якщо вони не доступні підкласу, є спадковим станом надкласу.

Я б відповісти , що приватні поля в Java є успадковується. Дозвольте мені продемонструвати:

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.

    }

}

Якщо ви запускаєте програму Bar bar = new Bar();, то ви завжди побачите число "2" у вихідному полі. Так як число «х» инкапсулируется за допомогою методів update()і getX(), то воно може бути доведено , що ціле число успадковується.

Плутанина полягає в тому, що оскільки ви не можете отримати прямий доступ до цілого числа "x", люди стверджують, що це не передається у спадок. Однак кожна нестатична річ у класі, будь то поле чи метод, успадковується.

Набивання бітів / Вирівнювання та включення класу об'єктів у VTABLE не враховуються. Таким чином, об’єкт підкласу має місце для приватних членів класу Super. Однак доступ до нього не можна отримати з об'єктів підкласу ...

Ні , приватні поля не успадковуються. Єдина причина - підклас не може отримати доступ до них безпосередньо .

Я вважаю, що відповідь повністю залежить від поставленого питання. Я маю на увазі, якщо питання є

Чи можемо ми безпосередньо отримати доступ до приватного поля суперкласу зі свого підкласу?

Тоді відповідь - ні , якщо ми переглянемо деталі специфікатора доступу , це згадується, приватні члени доступні лише в межах самого класу.

Але, якщо питання є

Чи можемо ми отримати доступ до приватного поля суперкласу зі свого підкласу?

Це означає, що не має значення, що ви зробите для доступу до приватного члена. У такому випадку ми можемо опублікувати публічний метод у суперкласі, і ви можете отримати доступ до приватного члена. Отже, у цьому випадку ви створюєте один інтерфейс / міст для доступу до приватного члена.

Інші мови OOP, такі як C ++, мають friend functionконцепцію, за допомогою якої ми можемо отримати доступ до приватного члена іншого класу.

Ми можемо просто констатувати, що коли надклас переходить у спадок, то приватні члени надкласу фактично стають приватними членами підкласу і не можуть бути в подальшому успадкованими або недоступними для об'єктів підкласу.

Член або конструктор приватного класу доступний лише в тілі класу вищого рівня ( § 7.6 ), що додає заяву члена або конструктора. Він не успадковується підкласами. https://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#jls-6.6

Підклас не успадковує приватних членів свого батьківського класу. Однак якщо у суперкласу є загальнодоступні або захищені методи доступу до його приватних полів, вони також можуть використовуватися підкласом.

Приватні члени (стан та поведінка) передаються у спадок. Вони (можуть) впливати на поведінку та розмір об'єкта, який інстанціюється класом. Не кажучи вже про те, що вони дуже добре помітні для підкласів через усі наявні механізми розбиття інкаптуляції, або їх можна припустити їх реалізаторами.

Хоча успадкування має визначення «дефакто», воно, безумовно, не має зв’язку з аспектами «видимості», які припускаються відповідями «ні».

Отже, не потрібно бути дипломатичним. JLS просто помиляється на даний момент.

Будь-яке припущення про те, що вони не «успадковані» є небезпечним та небезпечним.

Тож серед двох дефакто (частково) суперечливих визначень (яких я не повторюватиму) єдиним, якого слід дотримуватися, є те, що є більш безпечним (або безпечним).