Je déteste avoir à programmer ou utiliser des accesseurs. Voilà, c’est dit.
Sérieusement, qui a eu l’idée de faire des méthodes getX() et setX() ? Dans le meilleur des cas c’est pénible a écrire et difficile à lire.
Qu’on ne me parle pas d’encapsulation, ces méthodes artificielles sont tout sauf un besoin d’encapsulation. C’est même exactement le contraire de l’encapsulation : C’est parce que je n’ai pas à savoir si un attribut est en accès direct ou non que je n’ai pas à utiliser d’accesseurs.
Il n’est pas besoin d’impacter la manière dont on appelle les attributs d’un objet pour différencier l’interface publique et les données internes. De nombreux langages on trouvé une manière élégante de gérer les accesseurs au niveau du langage au lieu de faire faire des pirouettes à l’utilisateur. Un des gros avantages c’est qu’on ne commence à définir des méthodes d’accesseur que quand on en a vraiment l’utilité, pas « partout, au cas où pour plus tard ».
Donc, quand il s’agit de migrer un attribut autrefois en accès direct, en Javascript :
A = { get b() { return this._b; }, set b(val) { return this._b = val;} }; // ou A.__defineGetter__("b", function() { return this._b; }; A.__defineSetter__("b", function(val) { return this._b = val; };
en Ruby :
class A def b @b end def b=(val) @b = val end end
en Python :
class X(object): def getb(self): return self._b def setb(self, val): self._b = val b = property(getb, setb) # ou mieux : class X(object): @property def b(self): return self._b @b.setter def b(self, val): self._b = val
Sérieusement, c’est moins de complexité pour démarrer du code (pas besoin de développer des accesseurs passe-plat au cas où on en aurait besoin plus tard, on peut s’en occuper uniquement quand le besoin arrive), et c’est plus de clarté pour tout ce qui utilise notre code (et là le gain est immense même si ça semble juste quelques caractères). Je n’imagine pas de m’en passer dans les langages où ça existe.
Si vous utilisez des getter et setter passes-plat, c’est soit votre code qui est mauvais, soit votre langage qui est bridé (soit que vous utilisez consciemment un langage bas niveau). Dans les deux premiers cas il y a quelque chose à repenser.
Bien entendu PHP reste à la traine, sous prétexte de simplicité (allez comprendre).
Laisser un commentaire