Classe interne statique d'une classe interne

J'ai beau me creuser, je ne comprends pas la raison pour laquelle le code suivant ne compile pas :

Code:

---

1 2 3 4 5 6 7

class A { class B { static class C {   } } }

---

Je connais bien la règle qui dit qu'une classe statique ne peut être déclarée que dans une classe statique ou dans une top level classe. Mais c'est la raison d'être de cette règle qui m'échappe.

Quelqu'un a une explication ? Ou mieux, un exemple qui montre clairement pourquoi ce ne serait pas possible ?

Je ne comprends pas, à proprement parler, cette règle.
Mais on peut aussi se demander pourquoi tu veux en faire une classe interne de B alors que ça pourrait tout aussi bien être une classe interne de A.

Je suppose qu'on peut y voir une sorte de "propreté imposée", un peu comme l'obligation de déclarer certaines Exceptions, l'interdiction de déclarer une variable locale de même nom qu'une autre variable locale du scope au-dessus, la non-existence de goto ou l'interdiction du code mort.
Bon, c'est pas évident, certes.

Je ne vois pas de propreté là dedans, au contraire.
Si ma classe interne B est la seule à utiliser une classe "utilitaire" C, je ne vois pas ce que C irait faire dans A.

C pourrait être typiquement un Comparator par exemple.

Edit :

Quant aux raisons qui me poussent à faire cela, elles sont juste théoriques ;)

Oui enfin, imbriquer d'imbriquer d'imbriquer d'imbriquer, ça va 5 minutes. Je suppose que c'est la, la "propreté imposée."

Mais bon, des fois, les "propretés imposées" de Java échouent, c'est un fait. C'est rarement problématique.

Les autres "propretés imposées" ont une vraie raison d'être.

Pour celles que tu cites :
- obligation de déclarer certaines Exceptions : Fondement même de Java
- interdiction de déclarer une variable locale de même nom qu'une autre variable locale du scope au-dessus : Celle du dessus est masquée et donc inaccessible.
- non-existence de goto :aie:
- l'interdiction du code mort : raison évidente. Aucune raison de faire quelque chose après un return.

Un exemple un peu plus parlant, imaginé à l'arrache :
Ceci fonctionne (compile en tout cas, c'est pas le résultat mais l'idée qui compte) :
Une fenêtre qui a un listener qui souhaite conserver les clics qui se produisent trié par position horizontale du clic.
Le listener possède donc un comparator.

Code:

---

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

public class MaFenetre extends JFrame { public MaFenetre() { JPanel p = new JPanel(); p.addMouseListener(new MonListener());   }   private class MonListener extends MouseAdapter { SortedSet<MouseEvent> events = new TreeSet<MouseEvent>(new EventComparator()); @Override public void mouseClicked(MouseEvent e) { events.add(e); }   private class EventComparator implements Comparator<MouseEvent> { @Override public int compare(MouseEvent o1, MouseEvent o2) { return o1.getX()-o2.getX(); } } } }

---

Ce code me dérange.
Pour moi, la classe EventComparator devrait être statique puisqu'elle ne dépend pas de l'instance de MonListener. Et je ne l'imagine pas en dehors du listener puisque c'est un outil de celui-ci.

Ok, ce bout de code est pourri mais je ne trouve pas d'autre exemple.

Citation:

---

Envoyé par Satch

Les autres "propretés imposées" ont une vraie raison d'être.

---

Celles que je t'ai citées oui, parce que je voulais des exemples parlants et légitimes. Mais Java est plein de choses de ce genre, et certaines sont gênantes de-ci de-là, quand on tombe dessus. Ce n'est pas à chaque coin de rue, bien sûr.

Citation:

---

Ce code me dérange.
Pour moi, la classe EventComparator devrait être statique puisqu'elle ne dépend pas de l'instance de MonListener. Et je ne l'imagine pas en dehors du listener puisque c'est un outil de celui-ci.

---

Moi ce qui me dérange, c'est l'idée que dans le code d'une seule classe, il puisse possiblement y avoir des choses qui ne la regardent pas.

Pas que je serais outré si cette construction devenait possible, mais bon...

Salut,


J’ignore les raisons exact de tout cela, mais comme l'a indiqué thelvin l'objectif étant surement d'éviter de faire des truc pas très net :D

Au passage cela ne se limite pas aux classes statiques mais à tous les éléments static (explicitement ou implicitement) :

• Les méthodes static.
• Les attributs static (sauf cas particulier pour les constantes).
• Les interfaces/enums/annotations (qui sont implicitement static)

Au passage cela ne me choque pas d'interdire de définir des éléments static dans un contexte non-static... C'est même plutôt logique en fait !

Maintenant de mémoire j'ai rarement eu de problème avec cela... et ton exemple ne me convainc pas vraiment ;)

Citation:

---

Envoyé par Satch

- obligation de déclarer certaines Exceptions : Fondement même de Java

---

Pourtant les checked-exceptions sont très décriés...


a++