Une petite relecture, en espérant ne pas radoter.
§ OO/ penser en termes de services
avec tel algorithme appliqué à tel structure ou tel type
"structure" est féminin -> telle
§ un chouilla plus loin: le pressing
Dans ce cas, toute la complexité de tri par couleur, de bonne quantité de lessive et autres est cachée
"cachée" a tendance à être un faux ami côté conception. Je préférerai presque "déléguée". Mais cela a aussi un sens fort :(. Quid "confiée à un spécialiste" ?
Autre reformulation qui me vient à la volée: "On n’a pas besoin de maîtriser les arcanes du nettoyage, des gens/spécialistes en qui on peut avoir confiance vont en assumer la responsabilité."
A ce propos, le terme a été employé mais pas posé: tout cela n’est jamais que de l’abstraction, et c’est une pierre fondamentale (je ne sais plus parler français) de la conception OO.
§ OO/exemple concret
j’ai fais remarquer
-> effe-a-i-té, pas esse
Mais… ce n’est pas une écriture à 4 mains?
§ OO/un peu de vocabulaire
Un objet n’est ni plus ni moins qu’une valeur qu’on manipule
une donnée, plutôt qu’une valeur, non?
§ OO/le type
Justement, comment sont définis les services qu’un objet peut rendre ?
Ne faudrait-il pas préciser que c’est le cas du C++ et d’autres langages à typage statique (?) ? Et que ce n’est pas vrai dans certains, plus proches de la définition OO originelle, où à la place on demande à un objet de répondre à un message, et que peut-être on ne sait pas s’il en est capable avant d’essayer.
on pourra créer autant d’objet
accorder au pluriel "objets"
§ OO/donc en C++
définir des fonctions à l’intérieure d’une structure
pas de "e" final à "intérieur"
§ OO/quelle méthode doit-on employer
Le prototype n’a rien d’extraordinaire, mais l’implémentation
Hum… j’aurai plutôt parlé de "déclaration", et de "définition". Je n’ai pas la norme sous les yeux pour voir quels sont les termes officiels.
la fonction à laquelle il a affaire
-> "à faire", IIRC
§ OO/séparons tout ça
séparer notre code entre définition et implémentation
Tu veux dire "définition de la classe" et "définition des fonctions"
vous-mêmes
Pas sûr qu’il faille un 's’ à "même" ici
découpez et vous gagnerez en lisibilité .
Avec le folding supporté par tous les outils modernes, est-ce que cela est toujours vrai? L’intérêt est lié à la chaine de compilation&link, et éventuellement à des considérations de distribution de code source.
§OO/invariant
Imaginez notre blanchisserie. Son invariant est que votre linge soit toujours en bon état
Je dirai plus qu’il s’agit d’une post-condition.
Pour info, mon exemple d’invariant est le suivant (en plus il se transpose bien à l’héritage et aux membres protégés: "peut-on avoir plus confiance aux enfants qu’aux voisins?"):
Mon chat est un drogué: il se fait des lignes de savon de Marseille. Je suis donc obligé de laisser la porte de la buanderie fermée en permanence.
Le voisin a un pb avec sa machine et vient toquer à la porte pour laver son linge. Pas de soucis, je lui file un double des clés et lui fais part de mon invariant/TOC: la porte de la buanderie doit toujours restée fermée.
Premier jour, il vient, et lave ses couleurs, il pense à bien refermer la porte à chaque fois. Nickel!
Deuxième jour, il revient pour son linge foncé. En court de route, appel de l’école: il y a une urgence et doit filer récupérer son gamin. Situation totalement exceptionnelle qui le fait partir précipitamment sans penser à refermer la porte de la buanderie.
Mauvaise surprise au retour, le chat est intoxiqué et je dois aller au véto.
-> discussions sur la confiance, les invariants, pourquoi on protège, etc.
même §
cours-jus
-> court-jus
§ privé VS public
inutile de le laisser masquer
-> laissé
Après: je dirai que par soucis d’homogénéité, c’est mieux d’éviter de trop mélanger les attributs publics et privés dans une même classe. -> principe de la moindre surprise.
§ Qui va construire
De même, l’initialisation ne se fait pas dans le corps du constructeur
Je rajouterai bien un "exclusivement". Car on peut le faire, mais ce n’est pas toujours le mieux, etc., etc.
même §
J’aurai bien appelé la fonction de réduction dans le constructeur. Ce n’est n’est alors qu’un renforcement technique de l’invariant.
§ 1 ctr, des ctrs
une seul ligne
-> seule*
std::string const d { iterateur, fin };
Je n’aime pas l’unicorn syntax pour les types conteneurs. Je préfère la réserver aux séquences de valeurs à stocker.
§ mutable
Une fonction membre constante, c’est une fonction qui ne modifie pas l’objet auquel elle appartient.
-> une fonction qui promet. Ce n’est pas parce que l’on ne modifie pas (chose que le compilateur sait observer), que nous (développeurs) le faisons promettre dans le code.
dans le cas de std::vector
, la fonction membre front
Je préférerai parler dans un premier temps de size
ou de empty
car il n’existe pas de surcharge non-const, et que quelqu’un de curieux pourrait voir qu’il y a plusieurs versions de front
.
Je relirai attentivement la page sur la sémantique de valeur plus tard