Déclaration et contrôle d'accès en Java

[naf87]

Bonjour à tous

Je viens par le présent message vous annoncer la publication de l'article
Déclaration et contrôle d'accès. Il a pour but de présenter de façon concise les notions fondamentales du langage Java (les énumérations, les classes et les interfaces) et s'inscrit dans la suite Le Mémo du certifié Java 6.

A terme, l'ensemble des articles de cette suite devra permettre à tout développeur Java d'avoir sensiblement le même niveau de connaissance qu'un titulaire d'une certification Java SE 6.

Je vous invite donc non seulement à prendre connaissance du contenu de cet article, mais aussi à laisser vos remarques sur la présente discussion afin de l'améliorer.

Je vous souhaite une bonne lecture.

Voici ma page personnelle developpez :
http://armel-ndjobo.developpez.com/

[Khaled.Noordin]

Salut
Merci pour cet article

[naf87]

C'est moi qui te remercie pour tes encouragements

[tralloc]

tu as oublié qu'on pouvait faire ça avec des enum, ça me semble important :

Code :

1
2
3
4
5
6
7
8
9
10
 
public enum Machin {
	Mars("planete",12),scrunch("asteroide",1.25f);
	private final float diametre;
	private final String type;
	private Machin(String type,float diametre){
		this.diametre=diametre;
		this.type=type;
	}
}

sinon c'est bien

[naf87]

Merci.

[Deadpool]

On crée les constantes en Java en faisant précéder les variables des mots clés final et static.

Moi perso j'aurais approfondi cette assertion car dit comme ça, ce n'est pas forcément vrai.

En effet, par un objet non immuable, les modificateurs static et final n'empêche pas de le modifier via ses méthodes d'altération.

De plus en Java une constante est quelque chose de bien particulier comme expliqué dans la FAQ.

[naf87]

Merci de la remarque

[tchize_]

On va encore dire que je suis pédant mais.... je ne suis pas d'accord:

Une classe de type enum est implicitement final, c'est pourquoi elle ne peut pas être définie comme abstract.

C'est faux. Une enum peux être abstract, mais c'est implicite, on ne peux pas l'expliciter. Une enum peut ne pas être final.
Les règles sont ici: http://docs.oracle.com/javase/specs/...8.html#jls-8.9

Les types Enum ne doivent pas êter déclarés abstrait, le faire entraient une erreur de compilation.
Une enum est implicitement final SAUF si au moins une des constantes contient un corps de classe

autrement dit, cette enum n'est pas final:

Code :

1
2
3
4
5
public enum SomeEnum {
 
    UN,
    DEUX{};
}

Du coup, ceci est faux aussi

D'après la première règle, on ne peut pas étendre les classes de type enum.

On peux créer un type anonyme qui étends l'enum, c'est exactement ce que j'ai fais dans le code précédent.


D'ailleurs, tout ça, tu le fais dans ce point-ci ou tu montre une enum non final et abstraite avec des sous classes anonymes

Il est possible de déclarer une méthode abstraite dans une classe de type enum, dans ce cas, chaque énumération devrait fournir une implémentation de la méthode sinon une erreur va se produire à la compilation.

Petit code de démo:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
public enum MyEnum {
 
    UN{public void test(){System.out.println("1");}},
    DEUX{public void test(){System.out.println("deux");}};
    public abstract void test();
}
 
public enum MyLastEnum {
 
    UN{public void test(){System.out.println("1");}},
    DEUX{public void test(){System.out.println("deux");}};
    public void test(){System.out.println("default");};
}
public enum MyOtherEnum {
 
    UN,
    DEUX;
}
 
public static void main(String[] args) {
        for (MyEnum e : MyEnum.values()){
            System.out.printf("Class is %s and parent is %s and super parent is %s\n",
                    e.getClass().getName(),
                    e.getClass().getSuperclass().getName(),
                    e.getClass().getSuperclass().getSuperclass().getName());
        }
        System.out.println("MyEnum modifiers: "+Modifier.toString(MyEnum.class.getModifiers()));
        for (MyOtherEnum e : MyOtherEnum.values()){
            System.out.printf("Class is %s and parent is %s and super parent is %s\n",
                    e.getClass().getName(),
                    e.getClass().getSuperclass().getName(),
                    e.getClass().getSuperclass().getSuperclass().getName());
        }
        System.out.println("MyOtherEnum modifiers:  "+Modifier.toString(MyOtherEnum.class.getModifiers()));
        for (MyLastEnum e : MyLastEnum.values()){
            System.out.printf("Class is %s and parent is %s and super parent is %s\n",
                    e.getClass().getName(),
                    e.getClass().getSuperclass().getName(),
                    e.getClass().getSuperclass().getSuperclass().getName());
        }
        System.out.println("MyLastEnum modifiers:  "+Modifier.toString(MyLastEnum.class.getModifiers()));
    }

Et sa sortie

Code :

1
2
3
4
5
6
7
8
9
Class is testenums.MyEnum$1 and parent is testenums.MyEnum and super parent is java.lang.Enum
Class is testenums.MyEnum$2 and parent is testenums.MyEnum and super parent is java.lang.Enum
MyEnum modifiers: public abstract
Class is testenums.MyOtherEnum and parent is java.lang.Enum and super parent is java.lang.Object
Class is testenums.MyOtherEnum and parent is java.lang.Enum and super parent is java.lang.Object
MyOtherEnum modifiers:  public final
Class is testenums.MyLastEnum$1 and parent is testenums.MyLastEnum and super parent is java.lang.Enum
Class is testenums.MyLastEnum$2 and parent is testenums.MyLastEnum and super parent is java.lang.Enum
MyLastEnum modifiers:  public

[naf87]

C'est faux. Une enum peux être abstract, mais c'est implicite, on ne peux pas l'expliciter. Une enum peut ne pas être final.
Les règles sont ici: http://docs.oracle.com/javase/specs/...8.html#jls-8.9

Merci des remarques tchize_,
Je pense qu'il est préférable de donner des références qui portent sur Java SE 6.
Le site que tu communiques porte sur Java SE 7.

On peux créer un type anonyme qui étends l'enum, c'est exactement ce que j'ai fais dans le code précédent.

J'aurais dû dire qu'on ne peut pas étendre explicitement un énum à l'aide du mot clé

Code :

extends

[tchize_]

oui enfin c'est le même règles hein, les textes que je référence sont les mêmes J'ai l'habitude de toujours prendre la dernière version du spec quand il s'agit d'enseigner quelque chose à un ou plusieurs utilisateur, si c'est possible. Sinon on va lui dire qu'un truc est interdit alors qu'il est devenu permis

[naf87]

Ok, je crois que tes remarques vont me permettre de parfaire l'article.
Si je dois resumer :
je dois remplacer cette affirmation

Une classe de type enum est implicitement final, c'est pourquoi elle ne peut pas être définie comme abstract.

par

Une classe de type enum est implicitement final à moins qu'une des constantes ne contienne un corps de classe, c'est pourquoi elle ne peut pas être explicitement définie comme abstract.

je dois remplacer

D'après la première règle, on ne peut pas étendre les classes de type enum.

par

D'après la première règle, on ne peut pas étendre explicitement les classes de type enum en faisant usage du mot clef

Code :

extends

.

[naf87]

On va encore dire que je suis pédant

. Tant que ton savoir est une lanterne, je crois qu'il n'y a que des sots pour la rejeter.

[tchize_]

Envoyé par naf87

Une classe de type enum est implicitement final à moins qu'une des constantes ne contienne un corps de classe, c'est pourquoi elle ne peut pas être explicitement définie comme abstract.

J'utiliserais les termes de la JLS moi


Une classe de type enum est implicitement final à moins qu'une des constantes ne contienne un corps de classe. C'est une erreur de compilation d'utiliser le modifier "abstract" ou "final" pour la déclaration d'un enum

[thelvin]

Je dirais plutôt :

Un enum ne peut pas être déclaré final ou abstract. De toute façon une classe ne peut pas déclarer qu'elle hérite d'un enum et la question ne se pose pas.
Au niveau du bytecode, les instances d'un type énuméré peuvent être de leur propre classe, qui hérite du type énuméré dont elles font partie. C'est le compilateur qui marque les classes finales ou non-finales de la façon la plus appropriée.

Mais bon, je n'ai jamais été très doué pour les tutoriels.

edit : ou sinon reprendre la JLS, oui.

[tchize_]

Et pour info, il y a 2 ans, à la devoxx anvers, un présentateur a montré comment rajouter des enums "à la volée"' pour pouvoir répondre à la question de son client "ha oui, faut tester le comportement de la librairie si un jour on ajoute un nouvel enum. Mais pas touche aux enums actuel, on veux se limiter à cette liste là"

[naf87]

Bonsoir à tous,
juste pour vous informer que je viens de mettre à jour l'article en ligne.
Merci et bonne continuation aux uns et aux autres.

[professeur shadoko]

Protected : il est presque identique au modificateur par défaut. Cependant, en plus des classes du même package, les classes dérivées peuvent accéder aux elements protected d'une classe.

j'ai plusieurs fois fait remarquer dans le forum que cette affirmation est inexacte.
par exemple pour une instance dérivée tu peux accéder aux membres protected de ta super-classe uniquement en ce qui concerne l'instance courante
(tu ne peux pas accéder aux éléments protected d'une autre instance)
Si p2.Y dérive de p1.X et si p1.X a un membre d'instance protected m.
alors tu peux accéder à this.m mais pas à autreInstanceDeTypeX.m.
En effet si p3.Z dérive de p1.X tu pourrais alors accéder à m dans une instance de p3.Z ce qui n'est pas souhaitable.
allez hop une aspirine!

[naf87]

Bonsoir à tous,

j'ai plusieurs fois fait remarquer dans le forum que cette affirmation est inexacte.

Je pense qu'il est préférable de dire que cette affirmation n'est pas complète.

[professeur shadoko]

Envoyé par naf87

Je pense qu'il est préférable de dire que cette affirmation n'est pas complète.

une histoire rigolote à ce sujet: étant intervenu à une époque sur la version française de la certification Java j'avais fait remarquer que l'assertion "accessible depuis les sous-classes" n'était pas vraie puisqu'on pouvait exhiber des cas où ce n'était pas vrai.... réponse des américains: "oui mais c'est vrai dans la majorité des cas" Comme quoi la compréhension de la logique n'est pas la même selon les cultures (et les questions à choix multiples ne sont pas aussi indiscutables qu'on le dit: j'avais plusieurs exemples de ce genre de questionnaires où le seul fait d'être Européen vous faisait donner une "mauvaise" réponse!)

[nicroman]

Au passage, sur le chapitre III, il serait peut-être bien de rajouter les règles de nommage en Java...

http://www.oracle.com/technetwork/ja...35099.html#367

on voit de plus en plus de gens utiliser "MaVariable" ou "MaFonction" dans une classe "classeDeTruc"...

Et d'exposer le fait qu'utiliser des caractères non-ascii, même si cela est permis, a un risque... d'autant que les fichiers .java sont considéré par défaut en CP1252 (ISO-8859-1), donc considérer que tous les caractères unicode sont autorisés.... cela dépend des options de compilations.

Dans notre boite la règle est de n'utiliser que les caractères ASCII, et, dans les ressources nécessitant des traductions, utiliser la notation \u00A9 pour les caractères unicode...