Lors de tutoriels ou sur les forums, nous pouvons lire la plupart du temps qu'il est conseillé de déclarer attributs en protected, et méthodes en public.
Pourtant récemment, je suis tombé sur un tuto où il était question de privilégier les méthodes en protected et attributs en private ! Ce pour avoir l'interface la plus simple et homogène possible (ce sont grosso modo les arguments de l'auteur).
J'ai trouvé qu'il était intéressant de procéder ainsi, j'aimerais connaître vos méthodes pour respecter l'encapsulation, et ce que vous en pensez (et ce que vous pensez de cette méthode-ci si ce n'est pas la vôtre) !
Fais-le ou ne le fais pas... Il n'y a pas d'essai.
Lors de tutoriels ou sur les forums, nous pouvons lire la plupart du temps qu'il est conseillé de déclarer attributs en protected, et méthodes en public.
Non. En particulier, déclarer des champs membres (non fonction) protected c'est très souvent une connerie et on déclare très souvent des fonctions membres (parce qu'en C++, on parle de fonction membre) privées ou protected.
JeromeBenedetti1988 a écrit:
J'ai trouvé qu'il était intéressant de procéder ainsi, j'aimerais connaître vos méthodes pour respecter l'encapsulation, et ce que vous en pensez (et ce que vous pensez de cette méthode-ci si ce n'est pas la vôtre) !
Note rapide : l'encapsulation est un moyen, pas un but.
Concernant le "comment est ce qu'il est mieux de faire ?", une classe est un fournisseur de service et pour mener à bien ce service, elle est associée à un état (si elle n'est pas vouée à avoir un état, il n'y a pas d'intérêt à en faire une classe). La validité de cet état, c'est elle qui en est la garante, et personne ne devrait pouvoir lui subsumer ce boulot, ou même risquer de lui ruiner. Un descendant quel qu'il soit ne devrait pas avoir à se préoccuper de l'état interne de sa base.
Donc même si cette classe est destinée à être héritée, les champs en question devrait être privés pour lui permettre d'être sure de ne pas avoir à surveiller ce que feront ses descendant. En revanche, comme les descendants sont susceptibles d'avoir besoin d'un accès privilégié à des fonctionnalités de la classe de base, on peut avoir des fonctions protected qui ne seront accessibles que par les descendant, de cette manière la classe de base peut imposer ses contrôles facilement.
Finalement, en ajoutant l'utilisation systématique du pattern NVI pour entre autre faire de la vérification de contrat, une manière de ne pas se casser les dents dans un début de conception c'est :
champs (non-fonction) systématiquement privés,
accès privilégiés pour les descendants en protected par l'intermédiaire de fonctions membres,
fonctions virtuelles systématiquement privées,
interface de la classe publique.
Et comme toujours, quand on considère que ces règles nous ruinent la vie et qu'on peut en énoncer les raisons, on s'autorise des entorses et on les justifie.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C