276 votes

Les sous-classes héritent-elles des champs privés?

C'est une question d'entrevue.

Ne les sous-classes héritent privé les champs?

J'ai répondu "Non", parce que nous ne pouvons pas accéder à l'aide de "normal POO". Mais intervieweur pense, que leurs hérite, parce que nous pouvons accéder à ces champs ou indirectement ou encore de l'utilisation de la réflexion et qu'ils sont toujours dans l'objet...

Après je suis rentré, j'ai trouvé dans la javadoc suivant devis

Les Membres privés dans une super-classe

Un sous-classe n'hérite pas de la privée les membres de sa classe parente.

Connaissez-vous des arguments pour protéger l'enquêteur et de l'opinion?

256voto

RD1 Points 4458

La plupart de la confusion dans la question/réponses ici entoure la définition de l'Héritage.

Évidemment, comme @DigitalRoss explique un OBJET d'une sous-classe doit contenir sa superclasse, champs privés. Comme il a les etats, de ne pas avoir accès à un membre privé ne veut pas dire son n'y est pas.

Cependant. C'est différent de la notion d'héritage d'une classe. Comme c'est le cas dans le monde java, où il est question de sémantique de l'arbitre est la Java Language Specification (actuellement 3e édition).

Comme JLS états (http://docs.oracle.com/javase/specs/jls/se5.0/html/classes.html#8.2):

Les membres d'une catégorie qui sont déclarées privé ne sont pas héritées par les sous-classes de cette classe. Seuls les membres d'une classe qui sont déclarées protégées ou le public sont héritées par les sous-classes déclaré dans un emballage autre que le celui dans lequel la classe est déclarée.

Cela répond à la question exacte posée par l'enquêteur: "ne sous*CLASSES* hériter des champs privés". (italiques ajoutés par moi)

La réponse est Non. Ils ne le font pas. Les OBJETS des sous-classes contiennent des champs privés de leurs super-classes. La sous-classe elle-même n'a AUCUNE NOTION de champs privés de sa super-classe.

Est-il de la sémantique d'un pédant de la nature? Oui. Est-il utile à une question d'entrevue? Probablement pas. Mais le SÉMINAIRE établit la définition pour le monde Java, et il le fait (dans ce cas) sans ambiguïté.

ÉDITÉ (supprimé en parallèle une citation de Bjarne Stroustrup qui, en raison des différences entre java et c++ probablement qu'ajouter à la confusion. Je vais laisser ma réponse reste sur le JLS :)

87voto

DigitalRoss Points 80400

Oui

Il est important de réaliser que, bien que se sont deux classes, il y a un seul objet.

Donc, oui, bien sûr, elle a hérité le champs privés. Ils sont, sans doute, essentiel pour le bon fonctionnalités de l'objet, et alors que d'un objet de la classe parent n'est pas un objet de la classe dérivée, une instance de la classe dérivée est la plupart du temps certainement une instance de la classe parent. Il n'a pas pu être bien que sans tous les champs.

Non, vous ne pouvez pas accéder directement à eux. Oui, ils sont hérités. Ils ont pour être.

C'est une bonne question!


Mise à jour:

Err, "Non"

Eh bien, je suppose que nous avons tous appris quelque chose. Depuis le JLS origine exacte de "pas hérité" libellé, il est correct de répondre "non". Mais il y a vraiment est juste un objet, il vraiment ne contenir les champs privés, et donc, si quelqu'un prend la JLS et tutoriel libellé littéralement, il sera très difficile de comprendre la programmation orientée objet, les objets Java, et ce qui se passe vraiment.

23voto

Nishant Points 22758

Pas de. Champs privés ne sont pas héréditaire... et c'est pourquoi Protégées a été inventé. C'est par la conception. Je suppose que ce qui a justifié l'existence d'protégé modificateur.


Maintenant, venir à les contextes. Ce que vous entendez par héritée -- si c'est là, dans l'objet créé à partir de la classe dérivée? oui, il est.

Si vous voulez dire peut-il être utile à la classe dérivée. Eh bien, non.

Maintenant, quand vous venez à la programmation fonctionnelle, le domaine privé de la super-classe n'est pas hérité d'une façon significative pour la sous-classe. Pour la sous-classe, un champ privé od super classe même comme un champ privé de toute autre classe.

Fonctionnellement, ce n'est pas héréditaire. Mais idéalement, il est.


OK, juste regardé en Java tutoriel ils le cite:

Les Membres privés dans une super-classe

Une sous-classe n'hérite pas de la les membres privés de la classe parente. Toutefois, si la superclasse a public ou protégé méthodes pour accéder aux champs privés, ceux-ci peuvent également être utilisés par la sous-classe.

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

Je suis d'accord, que le champ est là. Mais, sous-classe ne reçoit pas de privilège sur ce domaine privé. Pour une sous-classe, le domaine privé est le même que dans tout domaine privé de toute autre classe.

Je crois que c'est purement question de point de vue. Vous pouvez moule de l'argument de chaque côté. Il est préférable de justifier à la fois.

17voto

Mehrdad Points 70493

Cela dépend de votre définition de "hériter". La sous-classe a-t-elle toujours les champs en mémoire? Absolument. Peut-il y accéder directement? Non, ce ne sont que des subtilités de la définition; il s'agit de comprendre ce qui se passe réellement.

11voto

OscarRyz Points 82553

Pas de. Ils n'héritent pas.

Le fait que certaines autres classes peuvent utiliser indirectement ne dit rien à propos de l'héritage, mais à propos de l'encapsulation.

Par exemple:

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

Vous pouvez également obtenir la valeur de count à l'intérieur d' UseIt via la réflexion. Il n'a pas les moyens, vous en hériter.

Mise à JOUR

Même si la valeur est là, il n'est pas héritée par la sous-classe.

Par exemple, une sous-classe définie comme:

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

C'est exactement la même situation que le premier exemple. L'attribut count est caché et pas héritées par la sous-classe. Encore, comme DigitalRoss points, la valeur est là, mais pas par la voie de l'héritage.

Mettre de cette façon. Si votre père est riche, et vous donne une carte de crédit, vous pouvez toujours acheter des chose avec son argent, mais cela ne signifie pas que vous avez hérité de tout ce que l'argent, n'est ce pas?

Autres mise à jour

C'est très intéressant, cependant, de savoir pourquoi l'attribut est là.

Franchement, je n'ai pas le terme exact pour décrire ça, mais c'est la JVM et la façon dont il fonctionne, qui se charge aussi de la "pas hérité" parent définition.

On pourrait effectivement changer le parent et le sous-classe ne fonctionnent toujours.

Par exemple:

C:\java>more > A.java
class A {
   private int i;
   public String toString() { return ""+ i; }
}^C
C:\java>more > B.java
class B extends A {
}^C
C:\java>more > Main.java
class Main {
   public static void main( String [] args ) {
      System.out.println( new B().toString() );
    }
}^C
C:\java>javac A.java B.java Main.java
C:\java>java Main
0
C:\java>more > A.java
class A {
   public String toString() {
      return "Nothing here";
   }
}^C
C:\java>javac A.java
C:\java>java Main
Nothing here

Je crois que le terme exact pourrait être trouvé ici: La Java Virtual Machine Spécification

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X