parentés entre classes

bon, je reviens à la charge

Soit c'est un gros trou de sécurité soit c'est moi qui suit un Bleu:aie:
j'expose.
en lisant tjs les tutos, j'ai bien compris qu'une classe interne existe réellement en tant que classe de niveau supérieur.
j'ai même expérimenté la compilation de

Code:

---

1 2 3 4 5

class Toto{ class Titi{ } }

---

à ma grande surprise j'ai vu que le compilateur me créé deux fichiers class un Toto.class et un Toto$Titi.class8O c'est là qu'on voit bien que la classe interne est bien réelle.
Bon supposant et ce qui fait la force d'un langage objet c'est la protection des données par l'encapsulation , right? Comment alors classe internes accède-t-elle à des variables privées? l'encapsulation est elle brisée????? et si qq de l'extérieur partage le même package que moi fait appelle à ma classe interne??? Parce que j'arrive à voir les variables privées.. Comment accède t-elle?????:roll:

J'espere que d'autres corrigeront mes betises ou etendront :

1) Les faits :
Alors :
- Titi a acces a toutes les variables public, protected, package protected et private statiques ou d'instance de Toto
- Une instance de Toto a les meme restrictions d'usage que pour les autres classes quand il s'agit d'acceder aux variables d'une instance de Titi.

Mais :
- Titi est une classe d'instance, elle n'existe/n'est definie que quand une instance de Toto existe. En effet cette classe interne n'est pas statique (dans le cas ou elle le serait elle n'aurai bien sur alors plus acces aux membres d'instance de l'instance de Toto).
- Et comme c'est une classe interne d'instance, on ne peut pas definir de membres statiques dans Titi.

2) Une tentative d'explication :
Une classe (ici Toto) represente un "espace de nommage" (au sens large) similaire a un package ou encore a un bloc ({...}) dans lequel on peut declarer et definir d'autres classes et d'autres variables et celles-ci peuvent acceder aux autres entites definies dans cet espace.

La grosse difference avec un package c'est la possibilite de creer des classes internes d'instance (<=> "locale") ou statiques (<=> "globale") alors que :
- au niveau du package tout est defini de maniere "globale".
- au niveau du bloc tout est defini de maniere "locale".
La classe represente donc un espace de nommage intermediaire entre les deux extremes.

La ou c'est "fun", c'est que pour une raison similaire on peut definir des classes internes statiques dans une interface ; ce qui vient un peu contredire ce que je t'ai dit tantot dans ton autre topic comme quoi il ne pouvait pas y avoir du code dans une interface (il peut y avoir du code dans une classe interne definie dans une interface).

Code:

---

1 2 3 4 5 6 7 8 9

public interface Test { public static class Truc { public void Truc() { } }   public static interface Bidule { } }

---

Et cela devient encore plus "fun" avec Java 5 puisqu'on peut definir des enums dans lesquelles ont peut rajouter ou surcharger des methodes (et en plus on n'est meme pas force de marquer static devant la declaration de l'enum...........................).

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public interface Test { public enum Machin { CHOSE, CHOUETTE;   /** @inheritDoc      */ @Override public String toString() { return super.toString().toLowerCase(); } }   public static enum Titi { TITI1, TITI2 } }

---

3) conclusion :
- Quelqu'un d'avise pensera a mettre en general private et ou final devant la definition de cette classe ou ses constructeurs pour eviter des abus.
- MAIS je ne suis pas sur qu'il soit possible d'etendre une classe interne d'instance. Ou je vois mal comment.
- Pour les classes internes statiques, pas de probleme. On les utilise en considerant leur classe parente comme un package.

PS : tu notteras que les classes anonymes sont egalement generees dans des fichiers separes nommes Toto$1.class, ...

EDIT - J'oubliais, parmis les trucs "fun++" : les implementations concretes qui sont definies a l'interieur de leur propre definition abstraites (qui peuvent etre des interfaces ou des classes abstraites) en utilisant la technique des classes internes statiques. Voir la classe Point2D et ses classes filles concretes Point2D.Float et Point2D.Double... et une bonne partie du package geom est comme ca...

hello,

Très passionnant, et je ne mettrais pas en cause cet exposé mais à ce que MisterTee à soulevé, je vois:

-> je ne sais pas si c'est implémenté dans Java 5 mais les modificateurs de visibilité de classes internes connaissent quelques problèmes.
-> je ne pense pas ( me corriger si j'ai tort ) que les MV implémentent la notion des class private ou protected à l'intérieur d'un pacquetage. Donc que l'on attribue à Titi ( la classe interne) autre visibilité que public n'est qu'une garantie de la compilation....
-> on s'éloigne du cadre d'origine???


@+++

Citation:

---

Envoyé par bouye

- Une instance de Toto a les meme restrictions d'usage que pour les autres classes quand il s'agit d'acceder aux variables d'une instance de Titi.

---

Non, pas tout à fait. Les champs privés sont accessibles par l'un et par l'autre, parce que, à ce que je sais, la visibilité n'est pas relative à une classe, mais à une unité de compilation ; comme une classe interne est dans la même unité de compilation que la classe englobante (c'est à dire, pour parler comme tout le monde, dans le même fichier source), tout le monde dans le fichiers peut voir les champs privés.

Comme au final les classes englobantes et les classes englobées sont séparées, cela oblige le compilateur à une jonglerie qui est considérée par beaucoup comme un trou de sécurité : les champs privés sont discrètements redéfinis en champ package.

Ex :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

class Toto { private String unPrivé;   class Inner { private String innerprive;   private void methodeInterne() { unPrivé = "zorro"; // compile bien. } }   private void methode() { uneInner.innerprive = "sergent garcia"; // compile bien. } }

---

... et dans les classes générées, innerprive et unPrivé ne sont plus des champs à accés privés, mais des champs à accés défaut (package private).

Salut,

Citation:

---

Envoyé par bouye

- Titi est une classe d'instance, elle n'existe/n'est definie que quand une instance de Toto existe.

---

En effet, et il y a deux moyens existant pour créer une nouvelle instance : soit elle est créé dans une des méthodes d'instance de Toto, soit en utilisant une instance de Toto et la syntaxe suivante (très peu utilisée) :

Code:

---

1 2	Toto toto = new Toto(); Toto.Titi titi = toto.new Titi();

---

Citation:

---

Envoyé par bouye

En effet cette classe interne n'est pas statique (dans le cas ou elle le serait elle n'aurai bien sur alors plus acces aux membres d'instance de l'instance de Toto).

---

Une classe interne static conserve bien les mêmes droits d'accès aux membres d'instances de la classe parente... mais comme elle n'est plus fortement lié à une instance spécifique, ce n'est possible qu'avec une instance reçu en paramètre, par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10

class Toto {   private String name;   class Titi { public void method(Toto t) { t.name = "X"; } } }

---

Citation:

---

Envoyé par bouye

(et en plus on n'est meme pas force de marquer static devant la declaration de l'enum...........................).

---

Il me semble qu'une enum est obligatoirement static lorsqu'elle est déclaré à l'intérieur d'une autre classe... Tout simplement parce que ses éléments sont déclaré en static !

Citation:

---

Envoyé par bouye

- Quelqu'un d'avise pensera a mettre en general private et ou final devant la definition de cette classe ou ses constructeurs pour eviter des abus.

---

Heu... Ca dépend de l'utilisation mais ce n'est pas forcément obligatoire... Toutefois c'est vrai que la plupart du temps les classes internes d'instances ne sont instancié que depuis la classe parente...

Citation:

---

Envoyé par bouye

- MAIS je ne suis pas sur qu'il soit possible d'etendre une classe interne d'instance. Ou je vois mal comment.

---

Comme n'importe quel classe avec extends :mouarf:
Plus sérieusement la seule contrainte étant de la définir dans la classe parente ou une de ses classes filles (pour avoir un référence sur la classe parente) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class Toto { class Titi {   }   class Titof extends Titi {   } }   class Tata extends Toto { class Toutou extends Toto.Titof {   } }

---

Citation:

---

Envoyé par MisterTee

Parce que j'arrive à voir les variables privées.. Comment accède t-elle?????

---

Certaines méthodes sont automatiquement générée, et les constructeurs sont modifié.

En effet si on prend le code suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class Toto {   private String name = "toto";   class Titi { Titi(String name) { Toto.this.name = name; System.out.println( Toto.this.name ); } } }

---

En vérité le code généré sera quelque peu modifié par le compilateur pour faire fonctionner le tout :

1. La classe Titi comportera un attribut contenant la référence vers l'instance de la classe parente.
2. Le(s) constructeur(s) de la classe Titi se verront ajouter un paramètre de type Toto représentant l'instance parente.
3. Les accès aux champs private de la classe parente dans la classe fille seront remplacés par des appels à des méthodes static qui effecuera l'accès à l'attribut.

Bien entendu le compilateur se charge de cela implicitement et modifiera correctement le code...

On peut vérifier cela en décompilant le code ou tout simplement en utilisant l'API de reflection :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

System.out.println("Constructeurs de Toto.Titi"); for (Constructor constructor : Toto.Titi.class.getDeclaredConstructors()) { System.out.println("\t" + constructor); }     System.out.println(); System.out.println("Attributs de Toto.Titi"); for (Field field : Toto.Titi.class.getDeclaredFields()) { System.out.println("\t" + field); }     System.out.println(); System.out.println("Méthodes de Toto :"); for (Method method : Toto.class.getDeclaredMethods()) { System.out.println("\t" + method); }

---

Ce qui nous donne dans ce cas :

Code:

---

1 2 3 4 5 6 7 8 9

Constructeurs de Toto.Titi Toto$Titi(Toto,java.lang.String)   Attributs de Toto.Titi final Toto Toto$Titi.this$0   Méthodes de Toto : static void Toto.access$0(Toto,java.lang.String) static java.lang.String Toto.access$1(Toto)

---

On voit bien que le constructeur de Titi a été modifié puisqu'il comporte deux paramètres au lieu d'un, et que la classe comporte un attribut de type Toto...

De même la classe Toto comporte deux méthodes access$0() et access$1() représentant en réalité des méthodes accesseurs/mutateurs statique...



Cela revient en gros à écrire le code suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

class Toto {   private String name = "toto";   static void setName(Toto toto, String name) { toto.name = name; }   static String getName(Toto toto) { return toto.name; } }   class Titi { private final Toto toto; Titi(Toto toto, String name) { this.toto = toto; Toto.setName(this.toto, name); System.out.println( Toto.getName(this.toto) ); } }

---

Citation:

---

Envoyé par Betatesteur

-> je ne sais pas si c'est implémenté dans Java 5 mais les modificateurs de visibilité de classes internes connaissent quelques problèmes.

---

Quels problèmes ???? Pourrais-tu préciser ?

Citation:

---

Envoyé par spekal

... et dans les classes générées, innerprive et unPrivé ne sont plus des champs à accés privés, mais des champs à accés défaut (package private).

---

En prévisualisant j'ai vu ton message... mais ce n'est pas tout à fait ca puisque la visibilité du champs n'est pas modifié, mais des méthodes accesseurs/mutateur sont générés selon les besoins...

a++

Citation:

---

Envoyé par adiGuba

Quels problèmes ???? Pourrais-tu préciser ?

---

Hello, j'avais pas bien détaillé,

les modificateurs de visibilité de classes internes connaissent qques pb parce qu'à ma connaissance (je peux me tromper) les installations actuelles de la machine virtuelle n'implémente pas la notion de la classe private ou protected à l'intérieur d'un paquetage, donc le fait d'attribuer à une classe interne autre chose qu'une visibilité public n'est qu'une garantie de la compilation comme je l'ai dit plus haut.

Merci de me donner plus d'info à ce sujet si qqu'un en sait plus;)


cependant, la classe interne permet au compilateur de contrôler la cohérence de type chose impossible avec un pointeur de méthode.:)

Citation:

---

Envoyé par MisterTee

l'encapsulation est elle brisée?????

---

la réponse est que Le compilateur est obligé de briser l'encapsulation de ton objet et d'insérer une méthode d'accès pour permettre à la classe interne de les atteindres. c'est pour ça que tu vois les variables private!!!


@+++

AdiGuba,

tu as dis quelque chose que je ne comprend pas très bien

Citation:

---

access$0() et access$1() représentant en réalité des méthodes accesseurs/mutateurs statique.

---

finalement il fait quoi le compilo, il brise l'encapsulation? ou et à quel moment il crré ces méthode accesseurs. car en décompilant comme tu l'as fait on ne sait pas comment il procède. parce que les méthodes d'accès disposant d'un accès au niveau paquetage, mon objet est en sécurité dans le paquetage. que se passerait il si des personnes sont autorisées à créer des nouvelles classes à l'intérieur de mon paquetage. Cette différence est énorme pour la sécurité. :(

Citation:

---

Envoyé par Betatesteur

cependant, la classe interne permet au compilateur de contrôler la cohérence de type chose impossible avec un pointeur de méthode.:)

---

Quelqu'un peut m'explique ce que cela veut dire?
en claire il est donc interressant d'utiliser des classes internes et anonymes (que je comprend pas trop n'en plus) que d'avoir plusieurs classes???

Merci de votre aide:?

Citation:

---

Betatesteur a écrit:
les modificateurs de visibilité de classes internes connaissent qques pb parce qu'à ma connaissance (je peux me tromper) les installations actuelles de la machine virtuelle n'implémente pas la notion de la classe private ou protected à l'intérieur d'un paquetage, donc le fait d'attribuer à une classe interne autre chose qu'une visibilité public n'est qu'une garantie de la compilation comme je l'ai dit plus haut.

---

En fait, pas tout à fait. Une classe interne (Titi) est un membre comme un autre de la classe englobante (Toto) et de ce point de vue, elle peut avoir n'importe quel modificateur de visibilité (public, protected, private, ou "package") et cela s'interprète de la même manière que pour une variable membre ou une méthode de la classe englobante. Par contre, pour une classe "top level" (c'est-à-dire une classe non interne, donc Toto dans notre cas) on ne peut pas utiliser un modificateur private ou protected, seuls public ou "package" sont acceptés.

Citation:

---

Envoyé par adiGuba

Une classe interne static conserve bien les mêmes droits d'accès aux membres d'instances de la classe parente... mais comme elle n'est plus fortement lié à une instance spécifique, ce n'est possible qu'avec une instance reçu en paramètre, par exemple :

---

C'est bien ce que je voulais dire mais ce n'etait probablement pas assez bien explique.

Citation:

---

Envoyé par adiGuba

Comme n'importe quel classe avec extends :mouarf:
Plus sérieusement la seule contrainte étant de la définir dans la classe parente ou une de ses classes filles (pour avoir un référence sur la classe parente) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class Toto { class Titi {   }   class Titof extends Titi {   } }   class Tata extends Toto { class Toutou extends Toto.Titof {   } }

---

---

Oui, je ne voyais pas dans quel contexte on pouvait etendre ce genre de classes (donc par la redefinition via une classe fille de la classse conteneur). Mail il faut dire que je n'ai jamais pousse vers ce genre de constructions.

Dans ce cas pour eviter un "trou" il suffit de :
- ou declarer la classe interne final (on empeche directement toute redefinition)
- ou declarer la classe interne private (la classe fille de la classe conteneur ne la voit pas)
- ou de declarer la classe conteneur final puisqu'alors on ne peut pas avoir un acces a une instance permettant la redefinition :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

final public class Test { public class Titi { } }   public class Test2 { public class Titi2 extends Test.Titi { } }   => "Test2.java": an enclosing instance that contains Test.Titi is required at line 2, column 3   public class Test3 { public Test3() { Test t = new Test(); Test.Titi titi2 = new Test.Titi(); Test.Titi titi3 = new t.Titi(); } }   =>"Test3.java": an enclosing instance that contains Test.Titi is required at line 4, column 23 =>"Test3.java": package t does not exist at line 5, column 30

---

La redefinition est impossible.

je n'avais pas vu les choses sous cet angle:)