Подклассы наследуют частные поля?

Это вопрос интервью.

Подклассы наследуют частные поля?

Я ответил «Нет», потому что мы не можем получить к ним доступ «обычным способом ООП». Но интервьюер считает, что они наследуются, потому что мы можем получить доступ к таким полям косвенно или с помощью отражения, и они все еще существуют в объекте.

После того, как я вернулся, я нашел следующую цитату в Javadoc :

Частные Члены в Суперклассе

Подкласс не наследует частные члены своего родительского класса.

Знаете ли вы какие-либо аргументы для мнения интервьюера?

Большая часть путаницы в вопросе / ответах здесь связана с определением Наследования.

Очевидно, что @DigitalRoss объясняет ОБЪЕКТ подкласса должен содержать закрытые поля своего суперкласса. Как он утверждает, отсутствие доступа к частному члену не означает, что его там нет.

Тем не мение. Это отличается от понятия наследования для класса. Как и в случае с Java, где существует вопрос семантики, арбитром является спецификация языка Java. (в настоящее время 3-е издание).

Как говорится в JLS ( https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.2 ):

Члены класса, которые объявлены закрытыми, не наследуются подклассами этого класса. Только члены класса, которые объявлены защищенными или общедоступными, наследуются подклассами, объявленными в пакете, отличном от того, в котором объявлен класс.

Этот адрес точный вопрос , заданный интервьюера: «делать суб - КЛАССЫ наследуют частные поля». (акцент добавлен мной)

Ответ - нет. Они этого не делают. ОБЪЕКТЫ подклассов содержат приватные поля своих суперклассов. У самого подкласса нет НЕТ ВИДЕО частных полей своего суперкласса.

Это семантика педантичного характера? Да. Это полезный вопрос для интервью? Возможно нет. Но JLS устанавливает определение для мира Java, и это делает это (в данном случае) однозначно.

EDITED (удалена параллельная цитата из Bjarne Stroustrup, которая из-за различий между java и c ++, вероятно, только усугубляет путаницу. Я оставлю свой ответ на JLS :)

да

Важно понимать , что в то время как там есть два класса, есть только один объект.

Так что да, конечно, он унаследовал частные поля. Они, по-видимому, необходимы для правильной функциональности объекта, и хотя объект родительского класса не является объектом производного класса, экземпляр производного класса в основном определенно является экземпляром родительского класса. Это не может быть очень хорошо без всех полей.

Нет, вы не можете получить к ним прямой доступ. Да, они наследуются. У них есть быть.

Это хороший вопрос!

Обновить:

Ошибка "нет"

Ну, я думаю, мы все чему-то научились. Поскольку в JLS возникла точная «не унаследованная» формулировка, правильно ответить «нет» . Поскольку подкласс не может получить доступ или изменить личные поля, то, другими словами, они не наследуются. Но на самом деле существует только один объект, он действительно содержит приватные поля, и поэтому, если кто-то неправильно использует JLS и учебное пособие, будет довольно сложно понять ООП, объекты Java и то, что на самом деле происходит.

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

Спор здесь включает фундаментальную двусмысленность: что именно обсуждается? Объект? Или мы в каком-то смысле говорим о самом классе? При описании класса в отличие от объекта допускается много возможностей. Таким образом, подкласс не наследует приватные поля, но объект, который является экземпляром подкласса, безусловно, содержит приватные поля.

Нет. Частные поля не наследуются ... и поэтому было создано изобретение Protected . Это по замыслу. Полагаю, это оправдывало существование защищенного модификатора.

Теперь подходит к контексту. Что вы подразумеваете под унаследованным - если он есть в объекте, созданном из производного класса? Да, это так.

Если вы имеете в виду, может ли это быть полезным для производного класса. Ну нет.

Теперь, когда вы переходите к функциональному программированию, приватное поле суперкласса не наследуется значимым образом для подкласса. . Для подкласса приватное поле суперкласса такое же, как приватное поле любого другого класса.

Функционально это не наследуется. Но в идеале это так.

Хорошо, только что посмотрел учебник 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 имеет часы и минуты как частные члены и соответствующие методы получения и установки как публичные. Затем идет DigitalClock как подкласс часов. Здесь, если объект DigitalClock не содержит часов и минут, тогда все испорчено.

Хорошо, это очень интересная проблема. Я много исследовал и пришел к выводу, что частные объекты суперкласса действительно доступны (но не доступны) в объектах подкласса. Чтобы доказать это, вот пример кода с родительским классом и дочерним классом, и я записываю объект дочернего класса в текстовый файл и читаю закрытый член с именем «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 Одно из многих определений наследования, с которыми мне приходилось сталкиваться: «Наследование - метод программирования, который позволяет производному классу расширять функциональные возможности базового класса, наследуя все его состояние STATE (выделено мной) и поведение».

Закрытые поля, даже если они недоступны для подкласса, являются унаследованным состоянием суперкласса.

Я бы ответить , что частные поля в 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» в поле вывода. Поскольку целое число «x» инкапсулировано с методами update()и getX(), то можно доказать, что целое число наследуется.

Путаница заключается в том, что, поскольку вы не можете напрямую получить доступ к целому числу «х», люди утверждают, что оно не наследуется. Однако каждая нестатическая вещь в классе, будь то поле или метод, наследуется.

Заполнение битов / выравнивание и включение класса объекта в VTABLE не рассматривается. Таким образом, объект подкласса имеет место для частных членов класса Super. Однако к нему нельзя получить доступ из объектов подкласса ...

Нет , приватные поля не наследуются. Единственная причина в том, что подкласс не может получить к ним доступ напрямую .

Я считаю, что ответ полностью зависит от вопроса, который был задан. Я имею в виду, если вопрос

Можем ли мы напрямую получить доступ к закрытому полю суперкласса из их подкласса?

Тогда ответ « Нет» , если мы рассмотрим детали спецификатора доступа , упомянуто, частные члены доступны только внутри самого класса.

Но если вопрос

Можем ли мы получить доступ к закрытому полю суперкласса из их подкласса?

Это означает, что не имеет значения, что вы будете делать, чтобы получить доступ к частному члену. В этом случае мы можем сделать публичный метод в суперклассе, и вы сможете получить доступ к приватному члену. Итак, в этом случае вы создаете один интерфейс / мост для доступа к приватному члену.

Другие языки ООП, такие как C ++, имеют friend function концепцию, с помощью которой мы можем получить доступ к закрытому члену другого класса.

Мы можем просто заявить, что когда наследуется суперкласс, тогда частные члены суперкласса фактически становятся частными членами подкласса и не могут быть унаследованы в дальнейшем или недоступны объектам подкласса.

Закрытый член класса или конструктор доступен только в теле класса верхнего уровня ( §7.6 ), который включает в себя объявление члена или конструктора. Он не наследуется подклассами. https://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#jls-6.6

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

Частные члены (состояние и поведение) наследуются. Они (могут) влиять на поведение и размер объекта, который создается классом. Не говоря уже о том, что они очень хорошо видны для подклассов через все механизмы разрушения инкапсуляции, которые доступны или могут быть приняты их исполнителями.

Хотя наследование имеет определение «де-факто», оно определенно не имеет связи с аспектами «видимости», которые предполагаются ответами «нет».

Таким образом, нет необходимости быть дипломатичным. JLS просто не прав в этой точке.

Любое предположение, что они не «унаследованы», небезопасно и опасно.

Таким образом, среди двух де-факто (частично) противоречивых определений (которые я не буду повторять), единственное, которое следует соблюдать, - это более безопасное (или безопасное).