Discussion :

[jdelges]

Petite question que je n'ai jamais vue abordée:

En java, les méthodes getXXX() et setXXX() sont vivement conseillées pour encapsuler les champs privés d'une classe et ainsi éviter que pour une modification de l'implémentation d'une classe résulte la modification des classes qui l'utilisent.

Ex: classe personne (Java)

V1:

Code :

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

1
2
3
4
5
6
7
8
9
 
class Personne
{
public String getNomPrénom()
{
return NomPrénom;
}
private String NomPrénom;
}

V2:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
class Personne
{
 
public String getNomPrénom()
{
return Nom + " " + Prénom;
}
 
private String Nom;
private String Prénom;
}

Dans le cas de .NET:

V1 :

Code :

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

1
2
3
4
5
 
class Personne
{
public String NomPrénom;
}

V2:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
class Personne
{
public String NomPrénom
{
get { return Nom + " " + Prénom; }
}
private String Nom;
private String Prénom;
}

Donc peut-on conclure qu'il n'est pas conseillé en .NET d'utiliser systématiquement des ascesseurs?

[neptune]

Si, c'est tout à fait conseillé, comme pour tous les languages orientés objets.

[jdelges]

Oui, ma question c'est pourquoi? (puisqu'un ascesseur peut remplacer un champ public de manière transparente pour l'utilisateur de la classe)

[neptune]

C'est le principe de l'encapsulation. Tu caches les données internes de ta classe à ses utilisateurs. Ainsi, tu peux modifier tout le fonctionement interne sans poser de problèmes à ceux qui utilise ta classe. En publiant des accesseurs, tu décides quelles sont les seules manipulations autorisées sur ta classe.

De plus, si aujourd'hui une classe Person expose Name et renvoie une simple variable m_name, demain, si les règles business l'exigent, tu peux renvoyer String.Format("{0} ({1})", m_name, m_age) via le meme accesseurs, sans casser les applications qui l'utilisent.

[jdelges]

Oui, je sais ce qu'est l'encapsulation...

Et justement... Je reprends ton exemple
(en faisant exprès de ne pas encapsuler les champs pour te montrer que ça ne pose pas de problème!):

classe Person V1:

Code :

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

1
2
3
4
5
 
class Person
{
    public String Nom; 
}

classe Person V2:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
class Person
{
    public String Nom
    {
       get{ return m_nom + m_age; }
       set{ m_nom = value;}
    }
 
    private String m_nom;
    private int m_age;
}

Donc, les utilisateurs de la classe V1, accédaient directement à la variable publique Nom. Lors du passage à la V2, on a un ascesseur à la place d'un champ public...

Tu n'es pas d'accord avec moi que le mec qui utilisait la V1 n'a rien à changer à son code et que c'est totalement transparent pour lui?

[Ditch]

Salut JF,

c'est tout à fait correct ce que tu dis dans l'exemple cité.

Les ascesseurs sont utilisés principalement pour encapsuler les règles business comme cela a été indiqué mais aussi gérer les droits sur les propriétés (en mettant en private le get ou le set par exemple).

Mais tu pourrais aussi avoir des utilisations en interne qui font que le fait de proposer cette solution directement peut être utile:

Si tu as

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public string Var
{
get
{
if (var == String.Empty)
throw new Exception("blabla");
 
// ou encore
// if (var == String.Empty)
// return "NOTHING";
}
set{}
}
private string var = String.Empty;

Ce que tu gères et ce que tu renvoies sont ainsi différents.