Les conventions "Accesseur/Mutateur"

images/whitebelt.png

Il y a une convention de nommage standard des méthodes pour représenter les accès à des attributs:

Convention Accesseur/Mutateur. 

public class CompteEnBanque { // pas un objet "valeur": état modifiable
   ....
   //autres champs et méthodes
   private double découvertAutorisé ;
   public double getDécouvertAutorisé() { return this.découvertAutorisé ;}
   public void setDécouvertAutorisé(double val)  { this.découvertAutorisé = val ; }

[Note]

Un premier intérêt du mutateur (setXXX) est qu’on pourra avoir un code qui fait des contrôles sur les valeurs passées en paramètre.

Ensuite, si, dans une version ultérieure, la réalisation du champ découvertAutorisé change (par exemple on décide d’utiliser un objet plus complexe comprenant le montant et l’heure de modification) la méthode publique reste la même. Les codes appelants ne sont pas modifiés et ont toujours une vision d’un attribut (même si le champ correspondant a disparu ou a été modifié!).

Il existe aussi des attributs qui sont calculés au moment de l’invocation par exemple getPrixTTC() d’un Produit: ce sera obtenu en multipliant la valeur du champ prixHT par le taux de taxe. Un autre exemple serait l'âge d’une personne: ce ne peut être qu’un attribut calculé à partir de sa date de naissance. Ces attributs relèvent donc d’un get mais pas d’un set !

Les standards de Bean définissent d’autres conventions qui sont utilisées pour "découvrir" des caractéristiques d’une classe au runtime (outils de développement, outils de déploiement, programmation dynamique,…).

Mais … il y a un mais … une utilisation à mauvais escient de ces conventions s’avérera catastrophique! (voir ci-après)

[Avertissement]

La terminologie accesseur/mutateur est une retranscription de la terminologie des spécifications de Java : accessor, mutator.

Pour simplifier bien des outils notent getter,setter … Mais la retranscription en français donne des franglismes à manier avec des pincettes.

Autre problème de terminologie: celui (en Anglais) de property pour désigner un attribut. On trouve ce terme dans de nombreux langages mais il y a une ambiguité historique car ça peut aussi désigner une Paire (Clef, Valeur) autonome qui n’est pas directement membre d’une classe (voir par ex. Properties en Java). Donc éviter ce terme si le contexte n’est pas explicitement précisé!