Discussion :

[firgon]

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 !

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
String getString()
{
return variableString;
}

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[verbose]

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[EIN-LESER]

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

[firgon]

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 ?

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.

[Invité]

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

[EIN-LESER]

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

[Max]

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

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
public void toto() {
}

sera interdit au bénéfice de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public void toto()
{
}

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

[billynirvana]

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Pill_S]

Je peux très bien faire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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"

[firgon]

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

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

[darkxan]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

return Collections.unmodifiableList(this.zeList);

[Pill_S]

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