En gros, cela permet d'avoir une liaison moins forte entre la classe et son usage.
Mais c'est le principe de la POO d'avoir une liaison entre une classe et son usage. Rajouter un getter et un setter sur chacun de ses membres ce n'est pas de l'encapsulation, ça fait plaisir à ceux qui considèrent que tous les membres doivent être privés sans avoir trop à réfléchir. Je ne dit pas que la POO est la réponse à tous les problèmes, mais rajouter des get/set sans réflechir ce n'est pas de la POO.
En POO, on devrait réfléchir en terme de comportement et non de structure. Si je design une voiture en POO (l'exemple est un peu éculé, j'en suis désolé), ce qui m'intéresse c'est de la faire avancer, pas qu'elle ait 4 roues.
Par exemple, les getter et setter vont à l'encontre de la Loi_de_Déméter qui incite justement à programmer le comportement d'un objet et à moins s'attacher à sa composition (je cite l'article wikipédia : En particulier, un objet doit éviter d'invoquer des méthodes d'un membre objet retourné par une autre méthode).
Je ne parle bien sûr ici pas des objets "techniques" (un vecteur, un accès à une BDD, ...) mais de la partie fonctionnelle d'une application.
[^] # Re: Chacun son style
Posté par Étienne . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 3.
Mais c'est le principe de la POO d'avoir une liaison entre une classe et son usage. Rajouter un getter et un setter sur chacun de ses membres ce n'est pas de l'encapsulation, ça fait plaisir à ceux qui considèrent que tous les membres doivent être privés sans avoir trop à réfléchir. Je ne dit pas que la POO est la réponse à tous les problèmes, mais rajouter des get/set sans réflechir ce n'est pas de la POO.
En POO, on devrait réfléchir en terme de comportement et non de structure. Si je design une voiture en POO (l'exemple est un peu éculé, j'en suis désolé), ce qui m'intéresse c'est de la faire avancer, pas qu'elle ait 4 roues.
Par exemple, les getter et setter vont à l'encontre de la Loi_de_Déméter qui incite justement à programmer le comportement d'un objet et à moins s'attacher à sa composition (je cite l'article wikipédia : En particulier, un objet doit éviter d'invoquer des méthodes d'un membre objet retourné par une autre méthode).
Je ne parle bien sûr ici pas des objets "techniques" (un vecteur, un accès à une BDD, ...) mais de la partie fonctionnelle d'une application.
Étienne