Getters/Setters. Mal. Et point final

Article d'Egor Bugaenko 19 septembre 2014 | Publié dans : Core Java Ce vieux débat a été lancé par Allen Holub dans son célèbre article, en 2003, Pourquoi les méthodes getter et setter sont mauvaises - les getters/setters sont-ils un anti-modèle et devrions-nous les éviter, ou est-ce quelque chose que nous ' sont forcément nécessaires dans la programmation orientée objet. J'ajouterai mes deux cents à cette discussion. L'essentiel du texte ci-dessous est le suivant : les getters et les setters sont de mauvaises pratiques ; ceux qui les utilisent n'ont aucune excuse. Mais encore une fois, pour éviter tout malentendu, je ne suggère pas du tout que l’utilisation de get/set soit évitée autant que possible. Non. Je dis que vous ne les avez même pas laissés s'approcher de votre code . Qu'est-ce que vous pensez de cette déclaration? Digne de votre attention ? Utilisez-vous le modèle get/set depuis 15 ans et êtes-vous un architecte Java respecté ? Et vous ne voulez même pas entendre ces bêtises d'un inconnu ? Eh bien... je comprends vos sentiments. J'ai ressenti la même chose jusqu'à ce que je tombe sur le livre "Object Thinking" de David West - c'est le meilleur livre sur la programmation orientée objet que j'ai jamais lu. Donc s'il vous plait. Calmez-vous et essayez de comprendre ce que j'essaie d'expliquer. Sujet de controverse Il existe plusieurs arguments contre les « accesseurs » (un autre nom pour les getters et les setters) dans le monde orienté objet. Et ce sont tous des arguments très corrects. Jetons-y un coup d'œil rapide. Demandez, ne dites pas : Allen Holub dit : « Ne demandez pas les informations dont vous avez besoin pour faire un travail ; « demandez » à l'entité qui dispose de ces informations de faire le travail à votre place. Principe d'encapsulation violé : un objet peut être démonté par d'autres objets car ils sont capables d'intégrer n'importe quelle donnée dans l'objet, via des setters. Un objet ne peut tout simplement pas encapsuler son propre état de manière suffisamment sécurisée, car n'importe qui peut modifier cet état. Détails d'implémentation révélés : si vous pouvez obtenir un objet à partir d'un autre objet, alors nous nous appuyons trop sur les détails d'implémentation du premier objet. Si demain cela change (par exemple, le type de résultat), alors nous devrons changer le code. Toutes les justifications ci-dessus sont certainement logiques, mais elles passent à côté du point le plus important. Idée fausse de base La plupart des programmeurs croient qu'un objet est une structure de données avec des méthodes. Je cite l'article de Bozhidar Bozhanov : Getters et Setters ne sont pas mauvais. Mais la plupart des objets pour lesquels des getters et des setters sont créés contiennent simplement des données. Cette idée fausse est le résultat d’un énorme malentendu ! Les objets ne « se contentent pas de stocker des données ». Les objets ne sont pas des structures de données auxquelles sont attachées des méthodes. Ce concept de « stockage de données » est issu de la programmation orientée objet et des langages procéduraux, notamment C et COBOL. Je le répète : un objet n'est pas seulement un ensemble d'éléments de données et de fonctions qui les manipulent. Un objet n'est pas un objet de données. Et alors ? Ball and Dog Dans une véritable programmation orientée objet, les objets sont des êtres vivants, tout comme vous et moi. Ce sont des organismes vivants, avec leur propre comportement, leurs propriétés et leur propre cycle de vie. Un organisme vivant peut-il avoir un setter ? Pouvez-vous attacher (« poser ») une balle à un chien ? Ne réfléchissez pas. Mais c’est exactement ce que fait le morceau de code ci-dessous :

Dog dog = new Dog();
dog.setBall(new Ball());

Alors, comment vous l'aimez? Pouvez-vous retirer (« récupérer ») la balle du chien ? Eh bien, supposons que vous le puissiez. Au cas où elle l'aurait mangé et que vous l'auriez opérée. Dans ce cas, oui, vous pourrez récupérer (« récupérer ») la balle du chien. C'est exactement de cela dont je parle :

Dog dog = new Dog();
Ball ball = dog.getBall();

Ou un exemple encore plus ridicule :

Dog dog = new Dog();
dog.setWeight("23kg");

Pouvez-vous imaginer cela dans la vraie vie ? Est-ce que vous avez l’impression d’écrire tous les jours ? Si oui, alors vous êtes un programmeur procédural. Admets-le. Voici ce que dit David West à la page 30 de son livre : La première étape pour transformer un développeur procédural réussi en un développeur objectif réussi est une lobotomie. Avez-vous besoin d'une lobotomie ? J'en avais absolument besoin, et je l'ai obtenu en lisant le livre de West "Object Thinking". Pensée objective Commencez à penser comme un objet et vous renommerez immédiatement ces méthodes. Voici ce que vous pourriez obtenir :

Dog dog = new Dog();
dog.take(new Ball());
Ball ball = dog.give();

Désormais, nous traitons le chien comme un véritable animal qui peut nous prendre le ballon et le rendre si nous le lui demandons. Juste au cas où, je note que le chien ne peut pas renvoyer NULL. Les chiens ne savent tout simplement pas ce qu'est NULL ! La pensée objective (pensée) supprime immédiatement les références NULL de votre code. Un poisson appelé Wanda (1988) de Charles Crichton De plus, la pensée objective conduira à l’immuabilité d’un objet, comme le « poids du chien » dans notre exemple. Vous réécririez le code quelque chose comme ceci :

Dog dog = new Dog("23kg");
int weight = dog.weight();

Un chien est un organisme vivant immuable qui ne permettra à personne extérieure de changer son poids, sa taille, son nom, etc. Elle peut « dire », sur demande, son poids ou son nom. Il n'y a rien de mal avec les méthodes publiques qui exposent des requêtes pour certaines propriétés « internes » d'un objet. Mais ces méthodes ne sont pas des « getters » et elles ne doivent jamais recevoir le préfixe « get ». On ne « sort » pas du chien. Nous ne connaissons pas son nom. Nous lui demandons de nous dire son nom. Voyez-vous la différence? Nous ne parlons même pas de sémantique ici. Nous différencions l’approche procédurale de la programmation de celle orientée objet. En programmation procédurale, nous travaillons avec des données, les manipulons, les récupérons, les définissons et les supprimons si nécessaire. Nous sommes aux commandes et les données ne sont qu’un composant passif. Un chien n’est rien pour nous – il « contient simplement des données ». Elle n'a pas sa propre vie. Nous pouvons librement obtenir (obtenir) tout ce dont nous avons besoin et y mettre (définir) toutes les données. C'est ainsi que fonctionnent (fonctionnaient) C, COBOL, Pascal et d'autres langages procéduraux. Et la situation est complètement opposée dans le monde orienté objet. Ici, nous traitons les objets comme des organismes vivants, avec leur propre date de naissance et moment de décès, avec leur propre personnalité et leurs propres habitudes, si vous préférez. Nous pouvons demander au chien de nous fournir une donnée (par exemple son poids) et il peut nous renvoyer l'information. Mais rappelez-vous toujours que le chien est le composant actif. Elle décide de ce qui se passe après la demande. Et c'est pourquoi il est absolument faux que les méthodes d'un objet commencent par set ou get. Et il ne s’agit même pas de violer l’encapsulation, comme beaucoup le pensent. Il s'agit du fait que soit vous pensez comme un objet, soit vous écrivez toujours en COBOL avec la syntaxe Java. PS . Et oui, vous vous demandez peut-être : « Qu'en est-il des JavaBeans, JPA, JAXB et de nombreuses autres API Java qui dépendent de get/set ? Qu’en est-il de la fonction intégrée à Ruby qui facilite la création d’accesseurs ? Eh bien, que puis-je vous dire... vous n'avez pas de chance. Il est beaucoup plus facile de rester dans le monde primitif du COBOL procédural que de comprendre et d'embrasser le monde merveilleux des objets réels. P.P.S. _ J'ai oublié de dire, oui, l'insertion de dépendances via un setter est aussi un terrible anti-modèle. Mais nous en reparlerons dans le prochain article ! Article original