Question sur l'encapsulation des attributs

Salut,

Je code avec un ami un jeu en C++, et nous ne sommes pas d'accord sur un point, du coup on fait appel à votre expertise pour trancher. Notre problème est un sujet récurrent sur les forum, mais à chaque fois la question déclenche souvent des émeutes, j'espère que ça ne sera pas le cas ici . Dans tous les cours de C++ que j'ai pu lire, il est conseillé de mettre tous les attributs en private et d'éventuellement mettre des getter et setter. Ayant appris la programmation avec Python, je n'ai pas beaucoup de notions en encapsulation. Voici notre classe:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

class Rect
{
    public:
        Rect(Position pos, int w, int h);
        Rect(int x, int y, int w, int h);
        ~Rect();

        Position pos;
        int w;
        int h;
};

Mais Qames (celui avec qui je code le projet) me dit de mettre les attributs en private et de faire des getter et setter, sous prétexte que c'est plus sécurisé. Mais si le code des accesseurs sont "classiques" c'est à dire T getAttr() { return attr; } pour le getter et void setAttr(T val) { this->attr = val; } pour le setter, alors à quoi bon ? Ca revient au même, non ?

Merci d'avance,

AZ et Qames.

PS: Pour une classe aussi simple c'est pas plus facile de faire une struct ?

En réalité, les getters et setters vont servir surtout dans ce type de classe: ils sont indépendants de l'implémentation.

Si pour accéder à la position x du rectangle je dois faire rect.pos.x, Demeter ne va pas être très content. Par contre avec rect.x(), je me fiche totalement des intermédiaires. En plus, manipuler x,y et w,h n'est pas symétrique. Autre exemple, si w et h sont regrouper dans une classe Bounds, il va falloir remplacer tous les rect.w en rect.bounds.w, pas s'il y a des getters/setters.

Ma solution préférée reste cependant l'usage de fonctions libres, Rect ne devient qu'un contexte de données qui n'est jamais directement manipulé. C'est aussi plus facile de faire de la programmation générique avec des fonctions libres (quand plusieurs classes Rectangle de différentes bibliothèques cohabitent dans l'application).

(Cela me fait vaguement penser à cette discussion.)

Ah ! À la lecture de la norme C++-11 tu sembles avoir raison. Il en va appremment de même pour les unions :

Merci pour cette précision.

Salut,

Merci à tous pour vos réponses, nous avons finalement opté pour une structure pour le point et pour le rectangle.

Je passe le sujet en résolu, merci encore.

Je sais aussi penser en termes de données. Et dans ce cas là, il ne s'agit que de données et pas de trucs bâtards de type données derrière une fonction qui rajoute un intermédiaire pour faire plaisir à ceux qui n'ont pas compris ce qu'est l'encapsulation.

rect.x() += 2 me parait être ce qu'il y a probablement de pire en terme de choix. À moins d'un encodage vraiment particulier de l'abscisse, cette surcouche n'apporte rien.

PS: je dois faire parti des rares personnes qui préfèrent voir un code planter si l'interface d'accès à une donnée change parce que la représentation de la donnée a changé. Cela me permet de juger s'il y a besoin de revoir les accès ou pas. Maintenant, c'est une situation que je n'ai pratiquement jamais rencontré. Je suis de fait prêt à payer le prix d'un changement d'interface de temps à autres : le prix est largement amorti depuis le temps. Mais bon, comme tu l'as dit, je suis principalement dans un paradigme de services -> d'où que mes interfaces ne dépendent pas de données, et que donc je n'ai pas le problème du changement de représentation qui influe l'interface.