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

246

Ceci est une question d'entrevue.

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

J'ai répondu "Non", car nous ne pouvons pas y accéder en utilisant la "voie OOP normale". Mais l'intervieweur pense qu'ils sont hérités, car on peut accéder à ces champs indirectement ou en utilisant la réflexion et ils existent toujours dans l'objet.

Après mon retour, j'ai trouvé la citation suivante dans le javadoc :

Membres privés dans une superclasse

Une sous-classe n'hérite pas des membres privés de sa classe parente.

Connaissez-vous des arguments pour l'opinion de l'intervieweur?

Stan Kurilin
la source
33
J'étais dans une situation similaire une fois et j'ai réalisé que je ne voulais même pas travailler pour une entreprise où l'intervieweur en sait moins sur Java que moi. :)
biziclop
48
Un intervieweur sera parfois en désaccord avec vous même s'il sait que vous avez raison. Un bon intervieweur essaiera d'en savoir plus sur vous que vos connaissances techniques.
Andy Thomas
4
@DigitalRoss La spécification du langage Java est-elle également mal écrite? Voir la réponse RD01: stackoverflow.com/questions/4716040/…
OscarRyz
9
@Andy Thomas-Cramer Je ne voudrais pas non plus travailler avec des gens qui mentent délibérément pour tester ma réaction.
biziclop
4
Eh bien, je pense que nous devons d'abord comprendre la signification de «l'héritage» en Java. La sous-classe n'a pas de champ privé et la sous-classe a le champ privé mais ne peut y accéder sont différents, lequel fait référence à la signification exacte de l'héritage en Java?
MengT

Réponses:

238

La plus grande partie de la confusion dans les questions / réponses entoure la définition de l'héritage.

Évidemment, comme l'explique @DigitalRoss, un OBJET d'une sous-classe doit contenir les champs privés de sa superclasse. Comme il le déclare, ne pas avoir accès à un membre privé ne signifie pas qu'il n'est pas là.

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

Comme l'indique le JLS ( https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.2 ):

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

Cela répond à la question exacte posée par l'intervieweur: "les sous- classes héritent-elles des champs privés". (emphase ajoutée par moi)

La réponse est non. Ce n'est pas le cas. Les OBJETS des sous-classes contiennent des champs privés de leurs superclasses. La sous-classe elle-même n'a AUCUNE NOTION de champs privés de sa superclasse.

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

EDITED (suppression d'une citation parallèle de Bjarne Stroustrup qui, en raison des différences entre java et c ++, ne fait qu'ajouter à la confusion. Je vais laisser ma réponse reposer sur le JLS :)

robert_x44
la source
3
@digital pourquoi le soupir. Je comprends que vous croyez avoir raison. Je ne suis pas en désaccord avec vous que l'héritage d'objet est ce que la plupart des programmeurs apprennent / pensent. Mais la définition JLS s'applique directement à la question d'origine. C'est de la sémantique oui, mais le JLS détermine la définition, pas vous ou moi.
robert_x44
4
Une façon de concilier tout cela est de simplement reconnaître que le mot "hériter" est utilisé de deux manières très différentes pour décrire la relation des classes dérivée et parent, au moins dans le monde Java. Oui, le JSL fait autorité. Oui, cela signifie que vous pouvez utiliser "hériter" de cette façon malheureuse. Mais il est toujours manifestement vrai que les sous-classes froggle (parce que maintenant nous n'avons pas un mot) les champs privés de leur classe parente.
DigitalRoss
1
@digital Ils sont dans l'objet de la classe. pas la classe elle-même. Simula les a appelés objets concaténés. Lorsqu'un objet d'une sous-classe était créé, il était composé d '«objets préfixes» concaténés. L'objet superclasse était un objet préfixe qui pouvait lui-même contenir d'autres objets préfixes. Je pense qu'il est arrogant de dire que le JLS a "clairement une mauvaise formulation". Quant au mot que nous utilisons, l'héritage bien sûr. Il n'y a rien de mal à utiliser une terminologie légèrement ambiguë. Cela arrive tout le temps. Mais cela ne signifie pas qu'il n'y a pas de définition précise.
robert_x44
1
@digital Nous pouvons certainement convenir que le mot est utilisé de différentes manières. :) Nous pouvons aussi probablement convenir qu'une question d'entrevue qui dépend d'un terme ambigu n'est probablement pas une bonne question.
robert_x44
2
Quelqu'un a une référence de Java / Oracle pour "Les objets de la sous-classe contiennent les champs privés de leurs super-classes"? Je suis d'accord avec cela, mais je ne trouve aucun document officiel le disant.
MengT
78

Oui

Il est important de réaliser que s'il existe deux classes, il n'y a qu'un seul objet.

Donc, oui, bien sûr, il a hérité des champs privés. Ils sont, vraisemblablement, essentiels pour une fonctionnalité d'objet appropriée, et bien qu'un objet de la classe parent ne soit pas un objet de la classe dérivée, une instance de la classe dérivée est surtout définitivement une instance de la classe parent. Ça ne pourrait pas être très bien sans tous les champs.

Non, vous ne pouvez pas y accéder directement. Oui, ils sont hérités. Ils doivent l' être.

C'est une bonne question!


Mettre à jour:

Euh, "non"

Eh bien, je suppose que nous avons tous appris quelque chose. Étant donné que le JLS est à l'origine du libellé exact "non hérité", il est correct de répondre "non" . Étant donné que la sous-classe ne peut pas accéder ou modifier les champs privés, en d'autres termes, ils ne sont pas hérités. Mais il vraiment est juste un objet, il a vraiment fait contenir les champs privés, et donc si quelqu'un prend les JLS et formulation tutoriel dans le mauvais sens, il sera assez difficile de comprendre la POO, les objets Java, et ce qui se passe réellement.

Mettre à jour pour mettre à jour:

La controverse implique ici une ambiguïté fondamentale: de quoi s'agit-il exactement? L' objet? Ou parlons-nous dans un certain sens de la classe elle-même? Une grande latitude est permise lors de la description de la classe par opposition à l'objet. Ainsi, la sous-classe n'hérite pas de champs privés, mais un objet qui est une instance de la sous-classe contient certainement les champs privés.

DigitalRoss
la source
2
@ Ma99uS. Bien sûr, ils sont réutilisés. C'est tout le point de l'héritage. Sans eux, le type dérivé ne serait pas et ne pourrait pas être une instance du type parent. La POO n'aurait aucun sens. Les types polymorphes cesseraient de fonctionner . Comprendre qu'il n'y a qu'un seul objet et que vous ÊTES une instance du type parent est crucial pour comprendre la POO. Vous devez dépasser ce problème pour le comprendre.
DigitalRoss
2
Je ne suis pas sûr que l'exemple du père soit très bon, car un champ peut être hérité pendant que la classe parent vit toujours et possède également ce champ. Si l'héritage fonctionnait de cette façon, je pourrais hériter de l'argent de mon père de son vivant et il pourrait aussi garder le même argent. Mes enfants auraient chacun son argent et mon argent.
Peter Lawrey
2
@Peter Lawrey ne discute pas ou quoi que ce soit, mais voici ce que je pense. Le parent en avait un car, il le gardait dans un privatecasier dont l'enfant n'a pas la clé. Vous héritez en effet du carmais c'est inutile pour vous. Donc, pratiquement, vous ne bénéficiez pas de l'héritage.
Nishant
1
@DigitalRoss. Je comprends ton point de vue. Mhh, nous pourrions dire que la valeur est là car la définition parent non héritée est également chargée. :) Je pense que la spécification JVM aurait la bonne réponse pour ce "NO WORD" que nous recherchons. java.sun.com/docs/books/jvms
OscarRyz
5
-1, la spécification du langage Java indique clairement qu'elles ne sont pas héritées. Pas de si, pas de mais. Ils ne le sont tout simplement pas. Toute autre définition de l'héritage est erronée dans le contexte de Java.
biziclop
21

Non. Les champs privés ne sont pas hérités ... et c'est pourquoi Protected a été inventé. C'est par conception. Je suppose que cela justifiait l'existence d'un modificateur protégé.


Venons-en maintenant aux contextes. Qu'entendez-vous par hérité - s'il se trouve dans l'objet créé à partir d'une classe dérivée? Oui, ça l'est.

Si vous voulez dire, peut-il être utile pour une classe dérivée. Et bien non.

Maintenant, lorsque vous arrivez à la programmation fonctionnelle, le domaine privé de la super classe n'est pas hérité de manière significative pour la sous-classe . Pour la sous-classe, un champ privé de super classe est identique à un champ privé de toute autre classe.

Fonctionnellement, ce n'est pas hérité. Mais idéalement , ça l'est.


OK, je viens de regarder le tutoriel Java, ils citent ceci:

Membres privés dans une superclasse

Une sous-classe n'hérite pas des membres privés de sa classe parente. Cependant, si la superclasse a des méthodes publiques ou protégées pour accéder à ses champs privés, celles-ci peuvent également être utilisées par la sous-classe.

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

Je suis d'accord, que le champ est là. Mais, la sous-classe n'obtient aucun privilège sur ce champ privé. Pour une sous-classe, le champ privé est identique à tout champ privé de toute autre classe.

Je pense que c'est uniquement une question de point de vue. Vous pouvez modeler l'argument de chaque côté. Il vaut mieux justifier dans les deux sens.

 

Nishant
la source
2
Ce n'est pas correct. Vous ne pouvez pas y accéder, c'est exact. Mais ils doivent être hérités comme je l'ai expliqué.
DigitalRoss
1
excellente réponse !!! +1 pour I believe it's purely matter of point-of-view.etjustified the existence of protected modifier.
Ravi
14

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.

user541686
la source
Correct. Mais je pense que dans une telle question de base, il devrait y avoir des réponses communes)
Stan Kurilin
Je pense que c'est la définition Java de l'héritage.
OscarRyz
Ou bien cela dépend de votre définition du "champ". Définir un champ entier "foo", c'est louer un casier de stockage de taille entière et y mettre un signe "foo". Si le champ est déclaré privé, la classe dérivée hérite d'un casier de stockage de taille entière sans étiquette. Le fait que la classe dérivée hérite ou non du "champ" dépend de si l'on appelle ce casier de stockage non étiqueté un "champ".
supercat
10

Je vais démontrer le concept avec du code. Les sous-classes héritent en fait des variables privées de la super classe. Le seul problème est qu'ils ne sont pas accessibles aux objets enfants à moins que vous ne fournissiez des getters et setters publics pour les variables privées dans la super classe.

Considérez deux classes dans le paquetage Dump. L'enfant étend le parent.

Si je me souviens bien, un objet enfant en mémoire se compose de deux régions. L'un est la partie parent uniquement et l'autre est la partie enfant uniquement. Un enfant peut accéder à la section privée dans le code de son parent uniquement via une méthode publique dans le parent.

Pense-y de cette façon. Le père de Borat, Boltok, a un coffre-fort contenant 100 000 $. Il ne veut pas partager son coffre à variables "privé". Donc, il ne fournit pas de clé pour le coffre-fort. Borat hérite du coffre-fort. Mais à quoi ça sert s'il ne peut même pas l'ouvrir? Si seulement son père avait fourni la clé.

Parent -

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

Enfant -

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
Erran Morad
la source
10

Non, ils n'en héritent pas.

Le fait qu'une autre classe puisse l'utiliser indirectement ne dit rien sur l'héritage, mais sur 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 l' countintérieur UseItvia la réflexion. Cela ne signifie pas que vous en héritez.

METTRE À JOUR

Même si la valeur est là, elle 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 countest masqué et n'est pas hérité du tout de la sous-classe. Pourtant, comme le souligne DigitalRoss, la valeur est là, mais pas par héritage.

Mets le comme ça. Si votre père est riche et vous donne une carte de crédit, vous pouvez toujours acheter quelque chose avec son argent, mais cela ne signifie pas que vous avez hérité de tout cet argent, n'est-ce pas?

Autre mise à jour

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

Franchement, je n'ai pas le terme exact pour le décrire, mais c'est la machine virtuelle Java et la façon dont elle fonctionne qui charge également la définition parent "non héritée".

Nous pourrions en fait changer le parent et la sous-classe fonctionnera toujours.

Par exemple :

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

Je suppose que le terme exact pourrait être trouvé ici: La spécification de la machine virtuelle JavaTM

OscarRyz
la source
:) La prochaine fois, vous pourrez saisir la chance d'expliquer à votre interlocuteur où il se trompe, ce qui peut vous donner des points supplémentaires;) Évidemment, vous devez le faire de manière diplomatique correcte.
OscarRyz
1
Ils doivent être hérités pour que les types polymorphes aient une quelconque signification. Voir mon explication. C'est vrai qu'on ne peut pas jouer avec eux, mais ils sont là. Ils doivent l' être.
DigitalRoss
Il n'y a pas de mots-clés d'héritage (étend / implémente) dans votre code donc ce n'est pas un exemple d'héritage.
fmucar
1
Euh, s'ils sont là, comment y sont-ils arrivés? Parce que la sous-classe les a définis? Non. Parce qu'ils étaient, euh, hmm, euh, hérités ?
DigitalRoss
1
Grand point sur encapsulationvs inherit, je suppose que cette réponse mérite un vote plus élevé.
Eric Wang
6

Eh bien, ma réponse à la question de l'intervieweur est - Les membres privés ne sont pas hérités dans les sous-classes mais ils sont accessibles à la sous-classe ou à l'objet de la sous-classe uniquement via des méthodes getter ou setter publiques ou toute autre méthode appropriée de classe originale. La pratique normale est de garder les membres privés et d'y accéder en utilisant des méthodes getter et setter qui sont publiques. Quel est donc l'intérêt de n'hériter des méthodes getter et setter que lorsque le membre privé avec lequel ils traitent n'est pas disponible pour l'objet? Ici, «hérité» signifie simplement qu'il est disponible directement dans la sous-classe pour jouer avec les méthodes nouvellement introduites dans la sous-classe.

Enregistrez le fichier ci-dessous sous ParentClass.java et essayez-le vous-même ->

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

Si nous essayons d'utiliser la variable privée x de ParentClass dans la méthode de SubClass, elle n'est pas directement accessible pour toute modification (signifie non héritée). Mais x peut être modifié dans SubClass via la méthode setX () de la classe d'origine comme dans la méthode setXofParent () OU il peut être modifié en utilisant l'objet ChildClass en utilisant la méthode setX () ou la méthode setXofParent () qui appelle finalement setX (). Donc, ici setX () et getX () sont en quelque sorte des portes vers le membre privé x d'une ParentClass.

Un autre exemple simple est Clock superclass a des heures et des minutes en tant que membres privés et des méthodes getter et setter appropriées en tant que public. Vient ensuite DigitalClock en tant que sous-classe d'horloge. Ici, si l'objet de DigitalClock ne contient pas de membres heures et minutes, les choses sont foutues.

dganesh2002
la source
2
Selon Oracle doc - Une sous-classe n'hérite pas des membres privés de sa classe parente. Cependant, si la superclasse a des méthodes publiques ou protégées pour accéder à ses champs privés, celles-ci peuvent également être utilisées par la sous-classe.
dganesh2002
4

Ok, c'est un problème très intéressant. J'ai fait beaucoup de recherches et suis arrivé à la conclusion que les membres privés d'une superclasse sont en effet disponibles (mais pas accessibles) dans les objets de la sous-classe. Pour le prouver, voici un exemple de code avec une classe parent et une classe enfant et j'écris un objet de classe enfant dans un fichier txt et je lis un membre privé nommé 'bhavesh' dans le fichier, prouvant ainsi qu'il est effectivement disponible dans l'enfant mais pas accessible en raison du modificateur d'accès.

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


}
}

Ouvrez MyData1.txt et recherchez le membre privé nommé «bhavesh». Faites-moi savoir ce que vous en pensez.

Bhavesh Agarwal
la source
3

Il semblerait qu'une sous-classe hérite des champs privés dans la mesure où ces mêmes champs sont utilisés dans le fonctionnement interne de la sous-classe (philosophiquement parlant). Une sous-classe, dans son constructeur, appelle le constructeur de la superclasse. Les champs privés de superclasse sont évidemment hérités par la sous-classe appelant le constructeur de superclasse si le constructeur de superclasse a initialisé ces champs dans son constructeur. Ce n'est qu'un exemple. Mais bien sûr, sans méthodes d'accesseur, la sous-classe ne peut pas accéder aux champs privés de la superclasse (c'est comme ne pas pouvoir ouvrir le panneau arrière d'un iPhone pour retirer la batterie pour réinitialiser le téléphone ... mais la batterie est toujours là).

PS L'une des nombreuses définitions de l'héritage que j'ai rencontrées: "Héritage - une technique de programmation qui permet à une classe dérivée d'étendre les fonctionnalités d'une classe de base, héritant de tous ses STATE (c'est moi qui souligne) et de son comportement."

Les champs privés, même s'ils ne sont pas accessibles par la sous-classe, sont l'état hérité de la superclasse.

Flanker
la source
1

Je dois répondre que les champs privés de Java sont hérités. Permettez-moi de démontrer:

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.

    }

}

Si vous exécutez dans un programme Bar bar = new Bar();, vous verrez toujours le nombre "2" dans la boîte de sortie. Parce que l'entier "x" est encapsulé avec les méthodes update()et getX(), alors il peut être prouvé que l'entier est hérité.

La confusion est que parce que vous ne pouvez pas accéder directement à l'entier "x", les gens soutiennent qu'il n'est pas hérité. Cependant, chaque élément non statique d'une classe, que ce soit un champ ou une méthode, est hérité.

Légal paresseux
la source
3
"Contient" ne signifie pas "hérite";)
Stan Kurilin
1

Disposition de la mémoire en Java vis-à-vis de l'héritage

entrez la description de l'image ici

Les bits de remplissage / alignement et l'inclusion de la classe d'objets dans la VTABLE ne sont pas pris en compte. L'objet de la sous-classe a donc une place pour les membres privés de la classe Super. Cependant, il n'est pas accessible à partir des objets de la sous-classe ...

somenath mukhopadhyay
la source
1

Non , les champs privés ne sont pas hérités. La seule raison est que la sous-classe ne peut pas y accéder directement .

joooohnli
la source
0

Je pense que la réponse dépend totalement de la question qui a été posée. Je veux dire, si la question est

Peut-on accéder directement au domaine privé de la super-classe depuis sa sous-classe?

Ensuite, la réponse est non , si nous passons par les détails du spécificateur d'accès , il est mentionné, les membres privés ne sont accessibles que dans la classe elle-même.

Mais, si la question est

Peut-on accéder au domaine privé de la super-classe depuis sa sous-classe?

Ce qui signifie, peu importe, ce que vous ferez pour accéder au membre privé. Dans ce cas, nous pouvons rendre la méthode publique dans la super-classe et vous pouvez accéder au membre privé. Donc, dans ce cas, vous créez une interface / un pont pour accéder au membre privé.

D'autres langages OOP comme C ++, ont le friend functionconcept, par lequel nous pouvons accéder au membre privé d'une autre classe.

Ravi
la source
0

Nous pouvons simplement déclarer que lorsqu'une superclasse est héritée, les membres privés de la superclasse deviennent en fait des membres privés de la sous-classe et ne peuvent plus être hérités ou sont inaccessibles aux objets de la sous-classe.

Aamir wani
la source
-1

Une sous-classe n'hérite pas des membres privés de sa classe parente. Cependant, si la superclasse a des méthodes publiques ou protégées pour accéder à ses champs privés, celles-ci peuvent également être utilisées par la sous-classe.

suprinder
la source
-2

Les membres privés (état et comportement) sont hérités. Ils peuvent (peuvent) affecter le comportement et la taille de l'objet qui est instancié par la classe. Sans oublier qu'ils sont très bien visibles pour les sous-classes via tous les mécanismes de rupture d'encapsulation qui sont disponibles, ou peuvent être assumés par leurs implémenteurs.

Bien que l'héritage ait une définition «de facto», il n'a certainement aucun lien avec les aspects de «visibilité», qui sont assumés par les réponses «non».

Il n'est donc pas nécessaire d'être diplomatique. JLS a tout simplement tort à ce stade.

Toute supposition selon laquelle ils ne sont pas "hérités" est dangereuse et dangereuse.

Ainsi, parmi deux définitions de facto (partiellement) contradictoires (que je ne répéterai pas), la seule qui devrait être suivie est celle qui est plus sûre (ou sûre).

gkakas
la source
1
-1. Le JLS définit le langage, il est impossible que le JLS soit "faux". De plus, s'il existe des mécanismes qui interrompent l'encapsulation, cela ne signifie pas que le champ est hérité; simplement qu'il existe des mécanismes qui subvertissent l'encapsulation.
SL Barth - Rétablir Monica
Une définition peut être erronée en elle-même de plusieurs manières. Ce n'est pas mon intention d'en discuter plus avant. L'argument ici n'est pas sur les mécanismes qui cassent l'encapsulation (dieu ou mauvais qu'ils soient) mais sur le fait que le champ / la méthode est là, affectant le comportement et l'état de votre sous-classe. Il est donc "hérité". On pourrait utiliser un tableau d'octets privé de 100 Ko dans une classe et supposer simplement que ses descendants (jumbo) n'en héritent pas. Ne manquez pas le point et jugez cela comme une bonne ou une mauvaise pratique (l'exagération aide à faire valoir un point): c'est une action prévue et légitime. Les membres privés SONT "hérités".
gkakas