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

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/

Salut
Merci pour cet article :ccool:

C'est moi qui te remercie pour tes encouragements

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

Merci.

Citation:

---

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.

Merci de la remarque

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

Citation:

---

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

Citation:

---

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

Citation:

---

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

Citation:

---

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

---

Citation:

---

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.

Citation:

---

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

---

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 :D

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

Citation:

---

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

---

par

Citation:

---

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

Citation:

---

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

---

par

Citation:

---

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

---

.

---

:ccool:

Citation:

---

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.

Citation:

---

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

Je dirais plutôt :

Citation:

---

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.

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à":aie:

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.

Citation:

---

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! :cry:

Bonsoir à tous,

Citation:

---

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.

Citation:

---

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" :roll: Comme quoi la compréhension de la logique n'est pas la même selon les cultures :lol: (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!)

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"... :calim2:

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

Citation:

---

Envoyé par nicroman

... d'autant que les fichiers .java sont considéré par défaut en CP1252 (ISO-8859-1), .

---

euh? par défaut par qui?
(par ailleurs je ne crois pas que CP1252 et ISO 8859 1 soient équivalents -contrairement à ce que Microsoft veut laisser croire- y 'a qu'à voir le nombre d'anomalies sur sites Web qui déclarent l'un (ISO) et en fait sont composés avec l'autre (Cp1252))
ceci dit c'est vrai que l'encodage des fichiers est un souci dans les grands projet internationaux car même si on se limite à l'anglais on a vite fait de déraper (exemple -qui m'est arrivé dans un javadoc-: "the façade pattern" :oops:)

Citation:

---

Envoyé par nicroman

d'autant que les fichiers .java sont considéré par défaut en CP1252 (ISO-8859-1),

---

Effectivement, ISO-8859-1 n'a rien à voir avec CP1252.

Le fichier java sont considéré par défaut comme "dans l'encodage par défaut de la plateforme". Sur un windows en europe de l'ouest, ce sera cp1252, en europe centrale du 1250, en Grèce du 1253. Ce truc est hérité des code page sous IBM/DOS. Sur un linux récent, ce sera utf-8, il y a fort à parier que sur un linux configuré au japon ce sera plutôt de l'UTF-16 voir une format japonais spécifique. Sur des linux plus anciens, c'est en général de l'ISO-8859-1.


Moralité, si tu veux une source portable, utilise une des variante UTF, l'utf-8 étant le plus répandu chez nous.

Citation:

---

Envoyé par professeur shadoko

ceci dit c'est vrai que l'encodage des fichiers est un souci dans les grands projet internationaux car même si on se limite à l'anglais on a vite fait de déraper (exemple -qui m'est arrivé dans un javadoc-: "the façade pattern" :oops:)

---

Plus simplement, imagine écrire dans une javadoc:

"@param currency Allowed values are € and ¥"
Le gars qui ouvre en iso-8859-1 va lire ça
"@param currency Allowed values are € and Y"
Le gars qui ouvre en utf-8 va lire ça
"@param currency Allowed values are and Y"
Et le grec, lui, il va lire ça
"@param currency Allowed values are € and Y"

C'est toujours important de standardiser le format. Des outils comme maven ou ant sont d'ailleurs bien pratiques à ce sujet :mouarf:

Rien à rajouter de plus :)

Citation:

---

Envoyé par Documentation javac

-encoding encoding
Set the source file encoding name, such as EUC-JP and UTF-8. If -encoding is not specified, the platform default converter is used.

---

Si la dessus on rajoute Eclipse qui va utiliser l'encoding par défaut du workspace.... Il y a vraiment moyen de s'arracher les cheveux

En bref... il vaut mieux utiliser que des trucs compatibles et utiliser \u quand on veut autre chose....

Bonjour à tous,
Une fois de plus merci pour les différentes critiques. Je profite pour vous annoncer la mise à disposition de la suite de cet article qui traite de la programmation orientée objet. Pour tous ceux qui souhaiteraient me donner un coup de main dans la relecture technique, bien vouloir cliquer sur ce lien : Programmation Orientée Objet

Il y a un souci dans cet article, les codes s'affiche dans un tableau : http://armel-ndjobo.developpez.com/t...le-acces/#LX-A