discours sur la methode

Bonjour,

encore une question philosophique, mais j'aurai besoin d'une clarification :

Je débute et je suis en train de terminer mon premier projet, tout marche globalement bien, cool, merci au forum pour tous ces conseils ! :king:

Mais je viens d'echanger mon code avec un autre débutant qui avait un projet similaire et je me rends compte que j'ai sans doute pas fait les choses comme il faut.

Pour récupérer une variable, pendant que lui codait :

Code:

---

1 2 3 4 5

String getString() { return variableString; }

---

pour la même utilisation je code (et très souvent en plus) :

Code:

---

1 2	nomdelaclasse.variableString;

---

Je sais, c'est mal. Mais j'ai beau relire mes tutos préférés, je ne vois pas ce qui me l'interdit. Je pense bien que ça contredit l'esprit d'encapsulation des données de Java, mais quel est le risque? Pourquoi est-ce qu'il vaut mieux passé par une méthode GET que par l'appel direct à la variable recherchée?

D'avance merci de pas m'accabler d'insultes...

En effet, il s'agit d'une question de philosophie :mrgreen:

L'encapsulation est un des piliers de la programmation orientée objet. Elle consiste à réduire la visibilité des attributs afin d'empêcher que ceux-ci ne soient accessibles à tord et à travers.

Un exemple. Supposons une classe Calculatrice :

Code:

---

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

public class Calculatrice { private int resultat;   public int plus(int i) { return resultat += i; }   public int moins(int i) { return resultat -= i; }   public int getResultat() { return resultat; } }

---

Dans ce cas, l'attribut resultat est encapsulé car il n'est pas question d'autoriser quelqu'un à injecter le résultat qu'il veut, celui-ci doit être uniquement le produit des opérations que nous avons implémenté, à savoir la somme et la soustraction.

ton truc marche (bien que sa soit tres laid lol) tan que ta variable est public mais des que tu a une variable privée (et tu en auras souvent pour une question de securisation des données) tu sera obligé de passer par un get donc autemps prendre les bonnes habitudes dés le debut ^^
:pc:

Citation:

---

Envoyé par verbose

Elle consiste à réduire la visibilité des attributs afin d'empêcher que ceux-ci ne soient accessibles à tord et à travers.

---

C'est à dire qu'il peut y avoir des problèmes de piratages, ou il s'agit de s'empecher de faire soi-même des bétises plus tard ?

Citation:

---

Envoyé par €IN-LESER

ton truc marche (bien que sa soit tres laid lol) tan que ta variable est public

---

Donc c'est bien un problème d'organisation interne et personnelle au programmeur, y'a t'il des changements en terme de performances ou autre?

Qu'on se comprenne bien, mon but est pas de remettre en cause cette façon de fonctionner qui effectivement me parait plus propre, mais bien d'intégrer et de comprendre ce système et cette philosophie.

Citation:

---

Envoyé par firgon

C'est à dire qu'il peut y avoir des problèmes de piratages, ou il s'agit de s'empecher de faire soi-même des bétises plus tard ?

---

Salut

Je ne dirais pas un problème de piratage mais il faut comprendre : tu fournis des classes qui ont une certaine interface définissant les opérations que tu autorises. Si quelqu'un d'autre utilise ta classe pour autre chose, veux tu lui autoriser d'autres opérations ou non ? etc...
Ce n'est pas que personnel, si tu fais un projet libre les gens pourront réutiliser ton travail à d'autres fins, si c'est professionnel il vaut mieux respecter les ligne de développement pour éviter le bazard dans les sources. De plus ca te permet de faire des accesseurs qui peuvent aussi effectuer d'autres opérations et comme l#a montré verbose dans son exemple, tu reste maître en quelque sorte de ce que tu as voulu définir comme opérations possibles et autorisées

Tu reste maitre surtout sur tes propres betises futures (involontaires cela s'entend lol) et celles des autres succeptibles d'ultiliser ton code.

Il est vrai qu'il peut paraitre fastitieux d'appliquer cette methode sur les premiers projets en java etant données qu'ils ne sont (en general) pas bien gros mais si tu prends pas les bonnes habitudes dés le debut tu verras qu'il tarrivera des petites mesaventures quand tu arriveras ades projets de plusieurs milliers de lignes repartis sur un dixaine de classes voire plus :aie:

Puisque nous somme dans une discution philosophique je voudrais savoir un truc à propot de "static".

Voila par exemple j ai une classe qui va lire des donner dans un fichier et qui stoque le tout dans une Arraylist.

J ai fait une methode get et set pour pouvoir lire ou agir le cas échéant dessus .

Normalement (sans le static) j'aurais du déclarer une nouvelle instance de cette classe lectrice dans une autre classe qui par exemple fera le traitement pour avoir acces au méthose get et set.

Mais dans mon cas j ai utilisé le préfixe static pour m'affranchir de cela, quel est l impact d'une telle méthode?

Citation:

---

Mais dans mon cas j ai utilisé le préfixe static pour m'affranchir de cela, quel est l impact d'une telle méthode?

---

Lorsque tu crées un un objet d'une classe, il est chargé en mémoire avec ses attributs et méthodes. Par exemple, pour 10 nouveaux objets

Code:

---

1 2 3 4 5 6 7

class A { private int propriete; public int getPropriete() { return this.propriete; } }

---

tu auras 10x propriete et 10x getPropriete() chargés.

Si getPropriete() est static, alors tu n'auras qu'1x getPropriete(), car les attributs et méthodes static sont chargés une et une seule fois au chargement de la classe.
Seul problème:

Code:

---

return this.propriete;

---

dans getPropriete() ne marchera plus car tu ne peux pas référencer un attribut non static dans un contexte (ici dans la méthode) static.

Une méthode static, comme tu sembles l'avoir compris, est une méthode de classe. C-à-d que la méthode est partagée par tous les objets de la classe. Si ta méthode fait le même traitement sur les mêmes données, tu peux avoir un intérêt à ce qu'elle soit static. Parcontre, pour des cas comme celui pré-cité, c'est non static qu'il te faut.

En résumé, tout ce qui est propre au type (à la classe donc) devrait être static (tu économiserais de la mémoire entre autres) et tout ce qui est propre à l'instance (l'objet), doit être non static.

Citation:

---

Envoyé par verbose

En effet, il s'agit d'une question de philosophie :mrgreen:

L'encapsulation est un des piliers de la programmation orientée objet. Elle consiste à réduire la visibilité des attributs afin d'empêcher que ceux-ci ne soient accessibles à tord et à travers.

---

Ca marche bien avec les types primitifs (int, boolean...) et la classe String.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class A { private List zeList;   public A() { zeList = new ArrayList(); .... // là on insère des valeurs dans la liste... } public List getList() { return this.zeList; } }

---

Je peux très bien faire:

Code:

---

new A().getList().removeAll();

---

Et là, tous les objets de la liste sont supprimés alors que naïvement on pense que les données sont sécurisées.

A méditer.

Citation:

---

Envoyé par George7

...si c'est professionnel il vaut mieux respecter les ligne de développement pour éviter le bazard dans les sources...

---

Voilà une bonne raison de se mettre aux getters / setters. Si jamais tu veux faire du développement ton métier, ce n'est même pas la peine d'y réfléchir ! Sans même parler de bazard, chaque boîte a ses normes de développement, par ex dans certaines :

Code:

---

1 2	public void toto() { }

---

sera interdit au bénéfice de

Code:

---

1 2 3

public void toto() { }

---

La position du "{", c'est de l'enculage de mouches mais c'est comme ça :mouarf:
Et donc les get / set , une seule certitude, c'est chez tout le monde pareil : obligatoire ;)

Citation:

---

Envoyé par billynirvana

Je peux très bien faire:

Code:

---

new A().getList().removeAll();

---

Et là, tous les objets de la liste sont supprimés alors que naïvement on pense que les données sont sécurisées.

A méditer.

---

Oui. C'est un problème connu, qui bien souvent se résoud par l'utilisation de copies défensives

Code:

---

1 2 3 4 5 6 7 8 9

public List getList() { // return this.zeList; <-- WEAK!! // Copie défensive de this.zeList, afin de ne retourner qu'une "image" de la vraie liste. List clone = new ArrayList(); clone.addAll(this.zeList); return clone; }

---

Cf. "Java Efficace, Joshua Bloch"

;)

Bon, on a perdu pas mal de message à cause du bug, mais qu'il est intéressant ce post, on apprend plein de choses!!:king:

Bon pour les getters et setters, c'est intégré, les copies défensives ont l'air assez simples à gérer, aussi, merci à vous.

Citation:

---

new A().getList().removeAll();

---

Au lieu d'utiliser la copie, on peut aussi retourner une liste non modifiable. Cela n'a pas le même effet mais cela peut être intéressant :

Code:

---

return Collections.unmodifiableList(this.zeList);

---

Citation:

---

Envoyé par firgon

les copies défensives ont l'air assez simples à gérer, aussi, merci à vous.

---

Attention, ce n'est pas si simple que ça. A vrai dire, le code que j'ai proposé ci-dessus n'est pas 100% sûr. Il faudrait également cloner le contenu de la liste pour être vraiment stable.

Après, il faut choisir le degré d'isolation des éléments en fonction de l'utilisation de la classe. Ce genre de copies défensives ne devient vraiment utile que lorsque l'on travaille sur des api utilisées par beaucoup de programmeurs. A l'intérieur d'un projet dans une équipe de développeurs qui se connaissent, ce n'est vraiment pas nécessaire

;)

Dans la même série, du bon usage des droits d'accès et sujet dérivatoire.

Je viens d'utiliser mon premier singleton (oui, ben il faut bien commencer par le premier, hein...)

Je me rencontre qu'avec singleton.getinstance(), mon objet (et donc ses méthodes) devient disponible depuis partout dans le code.
Est-ce le but recherché, n'est-ce pas un problème compte tenu de ce qui a été dit auparavant (encapsulation, tout ça tout ça...)?
En fait, pour parler plus clair, ce n'est pas que ça me pose problème, mais je trouve ça contraire à ce qu'on a dit précédemment.

Un singleton n'a pas pour but de limitée l'accessibilité mais seulement de permettre la création d'une seule et unique instance de classe. En faisant un getInstance(), l'utilisateur a acces à l'interface de la classe comme avec n'importe quelle référence. Si l'utilisateur a trop d'acces, le singleton n'y est pour rien mais c'est ton interface qui est a revoir.

Autres questions philosophique que je me posait :
Ca concerne les constructeurs et les variables de classes:

Code:

---

1 2 3 4 5 6 7 8 9

public class Fenetre extends JFrame {   private static final long serialVersionUID = 1L; private droite PanneauDroit = new droite(this); private int cas,table;   public Fenetre () { cas = 0; ...

---

De 1 : je vois qu'on peut déclarer et même initialiser une variable aussi bien dans le constructeur que dans les déclaration avant le constructeur. Y'a t'il une différence fondamentale entre faire comme j'ai fait et faire un "int cas = 0" entièrement dans la zone des private (désolé j'ai pas le terme exact?)
Y'a t'il des préconisations en la matière ?

De 2:
Mon "private droite PanneauDroit = new droite(this);", ça j'ai remarqué qu'il fallait que je le mette avant le constructeur parce que pendant le constructeur "this" a pas encore d'existence (à ce que j'en ai compris) et ça pose des nullexception plus loin. Est-ce que je fais bien, ou est-ce qu'il y a plus propre pour contourner le problème ?

D'avance merci de vos réflexions.

Salut,

Citation:

---

Envoyé par firgon

De 1 : je vois qu'on peut déclarer et même initialiser une variable aussi bien dans le constructeur que dans les déclaration avant le constructeur. Y'a t'il une différence fondamentale entre faire comme j'ai fait et faire un "int cas = 0" entièrement dans la zone des private (désolé j'ai pas le terme exact?)
Y'a t'il des préconisations en la matière ?

---

On appelle cela une initialisation "en ligne"...

Cela permet d'éviter de surcharger le constructeur avec des initialisations lorsque la valeur ne dépend pas de paramètre du constructeur (c'est à dire lorsque la valeur sera toujours la même à chaque création d'instance).

Citation:

---

Envoyé par firgon

De 2:
Mon "private droite PanneauDroit = new droite(this);", ça j'ai remarqué qu'il fallait que je le mette avant le constructeur parce que pendant le constructeur "this" a pas encore d'existence (à ce que j'en ai compris) et ça pose des nullexception plus loin. Est-ce que je fais bien, ou est-ce qu'il y a plus propre pour contourner le problème ?

---

Tu peux tout à fait mettre cela dans le constructeur : this est parfaitement valable dans le constructeur !
De plus le code d'initialisation est exécuté avant le code du constructeur, donc je ne vois pas pourquoi cela ne marcherais pas dans le constructeur...

Ce qui me gène surtout dans ce code ce sont les règles de nommage qui ne sont pas respecté et même inversé (nom de classe qui commence par une minuscule / nom de variable qui commence par une majuscule). Il me semblais qu'il y avait une erreur quelque part mais je ne la trouvais pas :aie:

a++

Salut,

Citation:

---

Envoyé par firgon

...
Je me rencontre qu'avec singleton.getinstance(), mon objet (et donc ses méthodes) devient disponible depuis partout dans le code.
Est-ce le but recherché, n'est-ce pas un problème compte tenu de ce qui a été dit auparavant (encapsulation, tout ça tout ça...)?
...

---

+1
Ce n'est pas le but rechercher mais c'est une faiblesse du pattern et c'est documente en tant que tel.

Citation:

---

Envoyé par adiGuba

Salut,

Tu peux tout à fait mettre cela dans le constructeur : this est parfaitement valable dans le constructeur !
De plus le code d'initialisation est exécuté avant le code du constructeur, donc je ne vois pas pourquoi cela ne marcherais pas dans le constructeur...

---

Bon je vais tenter de cerner mieux mon problème, mais à chaque fois que je l'ai fait j'ai abouti à une exception nullpointer.

Citation:

---

Envoyé par adiGuba

Ce qui me gène surtout dans ce code ce sont les règles de nommage qui ne sont pas respecté et même inversé (nom de classe qui commence par une minuscule / nom de variable qui commence par une majuscule). Il me semblais qu'il y avait une erreur quelque part mais je ne la trouvais pas :aie:

a++

---

Oui, c'est vrai que je ne fais pas assez gaffe, à l'occasion je reprendrais tout ça... minuscule pour les variables, majuscule pour les classes, je le sais, mais je ne suis pas assez rigoureux. Merci !