Un objet n'est pas ce que vous croyez

On définit habituellement un objet comme l'encapsulation de données et de comportement agissant sur ces données. C'est d'ailleurs un des 4 principes fondateurs de la Programmation Orientée Objet (OOP). C'est aussi une différence importante avec la Programmation Fonctionnelle, dans laquelle les fonctions agissent sur des structures de données dénuées de tout comportement et qui leur sont passées en paramètres.

Le but de l'encapsulation est de protéger l'état de l'objet, c'est-à-dire d'assurer sa cohérence à tout instant. Raison pour laquelle ces données ne sauraient être rendues publiques. L'état de l'objet ne doit pouvoir être modifié qu'au travers des méthodes qu'il expose, des méthodes qui sont le reflet d'interactions réelles que nous pouvons avoir avec cet objet.

Conséquence de ce postulat, les setters et getters, s'ils respectent l'encapsulation sur le papier, sont un dévoiement pur et simple du principe d'encapsulation : ensemble, ils exposent les entrailles de l'objet et permettent à un tiers de récupérer la donnée, la mettre à jour (ou procéder à quelque traitement basé sur cette dernière) et remettre le tout dans l'objet. Autrement dit, une belle fuite de responsabilité, connue sous le nom de feature envy. Autant faire simple, dans ce cas-là, et assumer que la donnée est publique — ce qui, encore une fois, serait une absurdité.

C'est bien le sens de la mise en garde d'Allen Holub, "tell, don't ask" : dites-moi quoi faire plutôt que de me demander les informations pour le faire, sachant que c'est ma responsabilité.

À se demander pourquoi tant d'IDE permettent encore de générer automatiquement ces méthodes (*). Bad habits die hard.

Au-delà, cela révèle une manière de penser contraire à ce qu'est l'OOP : nombreuses sont les personnes qui, lorsqu'elles créent une classe, déclarent avant toute chose les attributs de cette dernière. Comment cela serait-il possible ? Les données sont au service du comportement, donc sans comportement, pas de donnée. A faire de l'objet, raisonnons vraiment sur la base d'objets : des objets qui réflètent le monde réel, des objets avec lesquels on interagit, non de simples structures de données.

Un exemple concret vaudra mieux que de longs discours : cf. le code snippet.

Ainsi, pour être précis, il conviendrait de dire qu'un objet respecte le principe d'encapsulation. Mais un objet n'est pas l'encapsulation de données et de comportement agissant sur ces dernières. Car on veut interagir avec un objet comme avec une boîte noire, sans rien savoir des données qu'il utilise en interne pour représenter son état.