services publics d'une classe - références

Bonjour à toutes et à tous :)

Je viens du monde scientifique où je trouve assez difficile de communiquer sur les concepts de programmation C++.

J'ai débuté le C++ voilà à peine un an, mais je l'ai appris au biberon developpez.com, où des phrases comme "les services publics d'une classe", "les comportements que l'on est en droit d'attendre de la classe", "une classe fait une seule chose mais le fait bien" abondent. Du coup assez vite grâce à vous, mes programmes sont devenus (un peu) plus vivants/solides/extensibles.

Mais une telle vision n'est pas forcément partagée, et cela rend la communication difficile avec quiconque ne verrait les problèmes de prog que sous forme de structures de données et d'algorithmes.

Du coup je me suis rendu compte que j'avais du mal à identifier ce concept. On parle de quoi ? De programmation basée sur les services ? Sur les comportements ? Est-ce que c'est le paradigme générique qui encourage cette vision des choses ?
Et enfin, existent-ils des "références" (livres ou articles fondateurs...) qui appuient cette manière de voir les choses et dont je pourrais me servir pour rédiger/appuyer le chapitre "Prog" de mon manuscrit de thèse ? Quand les choses paraissent trop exotiques en science, on utilise des références pour rassurer et informer le lecteur ^^.

Cordialement,

Courage, nul n'est prophète en son pays.
Il s'agit de mise en application des principes SOLID de la programmation objet :
https://fr.wikipedia.org/wiki/SOLID_(informatique)

Attention, il s'agit de la conception des classes en règle générale.

En C++, on distingue un cas particulier d'utilisation des classes, la POO (Programmation Orientée Objet) qui repose sur les hiérarchies et le mot clé virtual.

Le C++ permet de construire des classes sans être dans ce cadre. Par exemple, la STL tout entière.
Les classes sont utiles à d'autres paradigmes, comme le "générique", basé sur les templates, et la "méta programmation", qui va encore plus loin.

Merci bacelar :)

Je connaissais un peu SOLID "en théorie" depuis le début (merci le livre de P. Dunski), mais je ne sais pas encore en appliquer les principes "directement", par contre je constate que ces principes émergent naturellement quand j'essaie d'écrire des bouts de code un peu extensible/fiable/robuste (à mon niveau... ;) ). Du coup je n'avais pas encore le recul pour faire le lien avec ce dont on parle ici, merci de l'avoir fait à ma place :)

Merci ternel pour tes précisions et ton recul toujours bienvenus !

Si je comprends bien ce que vous dites, ce n'est même pas un concept précis, ou une vision de la prog, mais bien les bases de la prog en général (je ne m'en étais même pas rendu compte :oops: ) ? Cette vision serait donc dans le milieu de la prog si peu exotique et si "bateau", que les références associées soient en fait... les livres de programmation pour débutants ? ^^

Ma question est sans nul doute extrêmement naïve mais au diable : reste-t-il des contextes d'application où penser "détails d'implémentations + algo = programme" se justifie ?

Citation:

---

Envoyé par Seabirds

reste-t-il des contextes d'application où penser "détails d'implémentations + algo = programme" se justifie ?

---

Peut-être cela ne répond pas à la question :whistle:

Actuellement je suis en train de réfléchir à un écran de recherche pour des utilisateurs.
Je serais parti pour faire un écran avec des cases à cocher (rechercher le nom, prénom, société), multi-colonnes pour le résultat (1 par critère) et on bloque pour attendre le résultat
Mais c'est trop compliqué parce que "il n'y pas qu'un seul bouton" ou "ce n'est pas moderne" :roll: :roll:

Donc, il faut faire la simple barre de recherche intelligente avec l'"instant search". Mais cela se code [au moins] avec un trie


Un autre exemple: une importation CSV d'utilisateurs (nom;prénom;société) avec gestion des doublons (en plus des erreurs de syntaxe - on oublie la ligne si mal formée ou critére utilisateur non respecté)
Pour 2000 utilisateurs si tu fais un bête tableau ordonné cela prend 5-6 secondes. Mais avec un arbre AVL tu arrives à 300-340 ms (*), et tu peux aussi gérer la recherche (mono critère) et la suppression très rapide.


* -> :mrgreen: avec un hash crc32 pour les chaînes de caractères et un "fixed size memory pool" pour les nœuds

SOLID, ce n'est pas tout à fait la base de la programmation.
C'est la base de la conception technique. Au moins à mes yeux.

Il s'agit de principes qui améliore la qualité d'un code.

• le SRP (Single Responsability Principle) améliore grandement la vérifiabilité.
• l'OCP (Opened Closed Principle) traite de la souplesse du code, donc de la facilité d'en écrire plus.
• le respect du LSP (Liskov Substitution Principle) apporte une meilleur utilisabilité dans l'OO (entre autre).
• l'ISP (Interface Segregation Principle) contribue à la séparation des taches.
• quant à la DI (Dependency Injection), la encore, c'est un moyen de découpler le code.

En conséquence, ces principes visent surtout à rendre le code modulaire, souple et maintenable. Les moyens de le faire passent généralement par fonctions et classes plus courtes, plus claires.
Les moyens techniques liés au C++ sont notamment le RAII, la const-correctness, les références, et bien souvent, des classes techniques sans héritages (comme dans la STL)

La programmation, c'est plus que simplement de la conception technique.
C'est aussi la conception fonctionnelle: la définition de la solution générale du problème, et le choix des algorithmes pour les différentes manipulations requises.
Pour cette autre partie, il n'y a pas beaucoup d'originalité. Il faut connaitre des algorithmes classiques, et savoir en construire.

Comme je te comprends :)

J'ai trouvé cet article Wiki intéressant : https://en.wikipedia.org/wiki/Compon...re_engineering

Les graphiques représentent bien l'idée d'API publique, avec un module fournissant des services. Tu ne raisonnes plus sur les structures et les algorithmes, mais sur les actions (réalisées avec.... des structures et des algo de toute façon ;))

Pour les objectifs dont parle Leternel, tu peux regarder https://en.wikipedia.org/wiki/Software_quality (reliability, efficiency, security, etc). Le but étant de faire un compromis entre ces objectifs (certains projets vont plus favoriser la sécurité, d'autres la maintenance, etc) et les moyens dispos (temps, compétences, etc).

Pour "détails d'implémentations + algo = programme", je pense que c'est lié de l'approche orientee donnees : https://en.wikipedia.org/wiki/Data-oriented_design, ou l'on pense en termes de flux de donnees. C'est ce type d'approche qui conduisent au pattern ECS pour les jeux vidéos.

Quelque soit l'approche, les objectifs sont les mêmes (la qualité logicielle). Les principes de POO continuent de s'appliquer avec l'approche orientée donnees, mais doivent être un peu adaptés.

Salut,

De manière générale, il y a toujours un moment où l'on finit par réfléchir aux "détails d'implémentation" et aux "algorithmes": après tout, le rôle de n'importe quelle application (ou bibliothèque) est... de manipuler des données (ces fameux "détails d'implémentation"), et notre rôle à nous est ... d'expliquer "à quelque chose d'aussi bête qu'un ordinateur" comment le faire (les algorithmes).

Mais ce qu'il faut comprendre, c'est qu'un algorithme ne vaut que par l'usage qui en est fait : une donnée inutilisée, un algorithme qui n'est jamais appelé, c'est du temps perdu (parce qu'il a bien fallu l'écrire et le vérifier).

Mais pire encore : un algorithme n'est valable que s'il apporte une certaine garantie de résultats fiables! Si un algorithme ne donne un résultat correct qu'une fois sur deux (ou même que 999 999 sur 1 000 000), l'utilisateur de l'algorithme (qui peut être ou non celui qui l'a créé) reste tout à fait en droit de se poser une question aussi gênante qu'un cailloux dans la chaussure : dans quelle mesure puis-je faire confiance au résultat :question:

Et, bien sur, si le résultat d'un algorithme dépend du résultat d'un autre algorithme qui dépend lui-même ... (je pourrais continuer longtemps comme cela ;) ), la question devient de plus en plus cruciale, parce que le résultat final est encore plus important, et qu'une erreur de résultat au niveau du tout premier algorithme qui aura été utilisé sera forcément... répercutée (et bien souvent amplifiée) par les algorithmes qui se basent (de manière directe ou indirecte) sur le résultat de ce premier algorithme.

Or, chaque détail d'implémentation que tu laisses accessible (en modification principalement) donne l'occasion à l'utilisateur d'aller ... le modifier d'une manière erronée. Et si tu as une donnée erronée ou corrompue, il ne faut pas t'étonner si... l'algorithme qui utilise cette donnée fournit... un résultat incorrect.

Et c'est, à mon sens, ce point particulier qu'il faut mettre en avant, car, à ce point, tu as la loi de Finagle qui pointe le bout de son nez, et qui pèse sur toi comme l'épée de Damoclès : si tu laisses à quelqu'un la possibilité de faire une connerie, il ne faut pas perdre ton temps à te demander SI il commettra cette erreur un jour ou non... Poses toi plutôt directement la question de savoir QUAND il la commettra ... Le truc, c'est que la réponse à cette question est toujours la même : au pire moment qui soit :P

Et, le pire de cette histoire, c'est que tu peux avoir le plus grand cerveau dans un domaine particulier en face de toi, ca ne changera rien : il fera peut-être moins d'erreurs, mais les conséquences de celles qu'il fera immanquablement seront souvent bien plus désastreuses.

L'approche orientée services permet de limiter au maximum les risques de "faire une connerie". Car, si tu ne sais rien d'une donnée à part la manière dont tu dois l'utiliser, tu ne peux pas faire énormément de mal, à part, bien sur, si tu ne l'utilises pas dans l'ordre dans lequel il aurait fallu le faire.

Mieux encore, si tu définis clairement comment tes données sont manipulées (et les algorithmes qui se rattachent à ces manipulations), tu peux aussi commencer à réfléchir en termes de pré conditons (conditions qui doivent être vérifiées avant le traitement) et de post conditions (conditions qui doivent être vérifiées après le traitement), et cela te permet de "passer un contrat" avec l'utilisateur : fournis moi des données cohérentes, tu auras le résultat correct".

Et ce contrat prendra -- au niveau de l'algorithme -- la forme d'assertion (vérification de la logique et des données entrantes) ou d'exception (les "cas particuliers" contre lesquels le développeur de la fonctionnalité ne peut rien, comme un serveur distant "down" ou un fichier inexistant lorsqu'on a voulu y accéder pour en récupérer certaines informations)

Tout ce que je viens de t'expliquer, ca porte un nom tout simple : encapsulation. Qui, contrairement à ce que croient encore certains, n'est absolument pas l'apanage des langages orientés objet, même si ces langages lui font généralement la part belle. Mais c'est un principe que l'on rencontre dans des langages exclusivement procéduraux! La meilleure preuve en est la structure FILE du C : très peu de gens savent de quoi elle est composées, mais tout le monde peut l'utiliser avec les fonction fopen, fread et fclose ;)

Enfin, la loi de Déméter et SOLID ne sont que des outils, des principes qui -- quand ils sont suivis -- tendent à favoriser (à part LSP, qui s'intéresse à un aspect tout à fait particulier) l'obtention d'une "encapsulation et une répartition du code optimales" : une encapsulation grâce à laquelle l'utilisateur d'une donnée ne pourra plus aller modifier la moindre donnée sans que la modification ne soit "validée" par le développeur de la fonctionnalité utilisée et une répartition du code grâce à laquelle la moindre erreur au niveau d'un algorithme pourra être rapidement circonscrite à ... une unique fonction d'une petite dizaine de lignes (voir moins).

Ce qu'il faut comprendre au final, c'est que, si on exclu LSP qui est essentiellement orienté OO, les quatre principes SO(L à exclure)ID et la loi de Déméter peuvent parfaitement être mis en oeuvre avec n'importe quel langage impératif, et plus encore avec les langages supportant le paradigme OO ou avec les langages supportant le paradigme générique ;)

Merci à tous pour vos réponses ! :D

Citation:

---

L'approche orientée services permet de limiter au maximum les risques de "faire une connerie". Car, si tu ne sais rien d'une donnée à part la manière dont tu dois l'utiliser, tu ne peux pas faire énormément de mal

---

C'est drôle mais bien que je connaisse (et utilise) cet argument, j'ai régulièrement du mal à y associer un exemple pratique concret (et pourtant j'imagine que si la STL ne cachait pas la misère derrière de beaux services so(l)ides, j'aurais déjà mis le feu à la maison depuis longtemps... ) :roll: Les pointeurs intelligents sont peut être un bon exemple : impossible de faire une bêtise en oubliant de libérer la mémoire, la STL se charge de ça. Mais d'aucuns diront que ça ne vaut pas la peine de les utiliser et que c'est quand même pas sorcier de mettre un delete, donc l'exemple n'est peut-être pas si bien choisi :?

Merci bktero, foetus et mintho carmo pour vos ressources, et ternel pour toujours plus de précisions :D
Merci koala01 pour l'argumentaire impeccablement déroulé ;)

Citation:

---

Envoyé par Seabirds

Citation:

---

Envoyé par koala01

L'approche orientée services permet de limiter au maximum les risques de "faire une connerie". Car, si tu ne sais rien d'une donnée à part la manière dont tu dois l'utiliser, tu ne peux pas faire énormément de mal, à part, bien sur, si tu ne l'utilises pas dans l'ordre dans lequel il aurait fallu le faire.

---

[...]Les pointeurs intelligents sont peut être un bon exemple : impossible de faire une bêtise en oubliant de libérer la mémoire, la STL se charge de ça. Mais d'aucuns diront que ça ne vaut pas la peine de les utiliser et que c'est quand même pas sorcier de mettre un delete, donc l'exemple n'est peut-être pas si bien choisi :?

---

Des arguments pour défendre std::unique_ptr :

• Quand on n'utilise pas de pointeurs intelligents et que des fonctions retournent des pointeurs nus, pour savoir sur lesquels faire delete, il faut perdre du temps à documenter les fonctions et à lire la documentation ou bien suivre des conventions de nommage contraignantes. Quand ce n'est pas fait et que le travail est fait dans l'urgence, certains delete sont oubliés ou écrits en trop.
• Quand les exceptions sont autorisées, sans pointeurs intelligents, écrire du code sans fuite mémoire est lourd. Exemple :
  
  Code:

  ---

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

  { Fruit* fruit1 = NULL; Fruit* fruit2 = NULL; try { fruit1 = FruitFactory::Instance().Construct(fruitName1); fruit2 = FruitFactory::Instance().Construct(fruitName2); foo(*fruit1, *fruit2); } catch(...) { delete fruit1; delete fruit2; throw; } delete fruit1; delete fruit2; }

  ---

  Le même code avec des std::unique_ptr :
  
  Code:

  ---

  1 2 3 4 5

  { std::unique_ptr<Fruit> fruit1 = FruitFactory::Instance().Construct(fruitName1); std::unique_ptr<Fruit> fruit2 = FruitFactory::Instance().Construct(fruitName2); foo(*fruit1, *fruit2); }

  ---

• Quand une classe a un membre pointeur et un destructeur qui appelle delete, il faut penser à désactiver explicitement (ou à redéfinir) le constructeur de recopie et l'affectation de copie. Sinon, si l'un d'eux est appelé, il y a aura un double delete.
  Avec un membre std::unique_ptr, le constructeur de copie par défaut et l'affectation de copie par défaut sont désactivés.

Cela dit, bien que std::unique_ptr est un bon moyen d'éviter des erreurs, c'est hors-sujet par rapport à la remarque de koala01.
std::unique_ptr ne cache pas vraiment son implémentation : on sait qu'il encapsule un pointeur et on peut facilement y accéder, entre autres avec les fonctions membres get() et release().

Si tu veux un exemple avec de l'encapsulation, il y a std::basic_string :
std::basic_string fournit des services, mais l'utilisateur ne sait pas forcément si, par exemple, l'implémentation utilise la SOO (Small String Optimization) qui consiste à stocker la chaîne sur place si elle est petite mais à la stocker ailleurs dans la mémoire dynamique si elle est grande.

En fait, AMHA, la structure FILE est vraiment l'exemple le plus accessible et le plus frappant d'une bonne encapsulation. Essentiellement du fait que ce n'est justement pas une notion issue du C++ mais bien une notion issue ... du C.

Ceci dit, un argument comme le DRY (Don't Repeat Yourself) sera peut être plus convaincant que le fait de parler d'encapsulation des données; alors que ce conseil (issu de l'Xtrem Programming) n'est jamais qu'un conseil visant à ... faire d'avantage encapsuler les données :P

Et sinon, il y a un exercice tout simple à proposer aux gens pour les convaincre de l'utilité de l'encapsulation :
Met les au défi de trouver le moyen d'obtenir un résultat incohérent pour une structure Date dont on ignore tout, si ce n'est qu'elle est associée à des fonctions comme

• bool isBissextilYear(Date const &)
• int numberOfDaysByMount(Date const &)
• int differenceByDays(Date const &, Date const &)
• using Duration = Date;Duration difference(Date const &, Date const &)
• Date computeDate(Date connst & origin, Duration d)
• Date computeDate(Date const & origin, int numberOfDays)

(en partant du principe que la logique appliquée pour chaque fonction est correcte à la base, cela va de soi)

Puis propose leur le défi inverse : écrire dix fois les algorithmes corrects permettant d'effectuer les calculs pour chacune de ces fonctions, en reprenant à chaque fois chaque algorithme depuis le début à partir d'une structure Date qui exposerait l'ensemble de son contenu.

Je peux te garantir que, si la logique est effectivement bonne pour les fonctions manipulant la structure opaque, personne n'arrivera jamais à obtenir un résultat erroné (comme le ... 30 février 1985), et que tout le monde a de très fortes chances de faire au moins une fois une erreur "idiote" dans la mise au point (à répétition) de ces algorithmes de base.

Et c'est d'autant plus embêtant que je vois, sans trop réfléchir, au moins trois à quatre possibilités différentes de représenter les détails constituant la notion de date, et que, si on venait à décider d'utiliser une représentation différente de cette notion, nous devrions systématiquement modifier l'ensemble des algorithmes dans lesquels la notion de date serait manipulée... Oh, tiens, on dirait que ca entre en conflit avec le O de SOLID, ca, non :question:

Ce que dit koala1 me fait penser à une phrase qui revient souvent dans le livre Effective C++ de Scott Meyers : "les interfaces doivent être faciles à utiliser correctement et difficiles à utiliser incorrectement".

C'est une façon de voir les choses qui pourrait intéresser tes collègues : ils écrivent sans doute de superbes et très pointus algorithmes mais il faut faire en sorte que les utilisateurs puissent les utiliser [remettre la devise ci-dessus entre ces crochets]. L'objectif étant finalement de mettre en valeur leur travail en fournissant des API qui permettront à tout le monde de tirer rapidement profit des algo sous-jacent.

Citation:

---

Quand les choses paraissent trop exotiques en science, on utilise des références pour rassurer et informer le lecteur ^^.

---

Il s'avère que Scott Meyers est une référence dans le monde C++ ;)

Et Seabirds plongea dans le livre de Scott Meyers... ;)
Merci à tous pour vos commentaires bien précieux ! :D

Citation:

---

Envoyé par Bktero

Ce que dit koala1 me fait penser à une phrase qui revient souvent dans le livre Effective C++ de Scott Meyers : "les interfaces doivent être faciles à utiliser correctement et difficiles à utiliser incorrectement".

---

C'est effectivement une phrase que je ressors très souvent dans mon contexte professionnel pour convaincre de la nécessité de retoucher du code.

Plus généralement, tout ce qui a été dit précédemment facilite également une autre partie du travail : les tests unitaires.
Si tu as une classe monstrueuse avec 15 membres (dont certains étant éventuellement des références), un constructeur avec 10 arguments, et une ribambelle de méthodes membres appelant les unes les autres, la réalisation de tes tests va être beaucoup plus pénible, et tu mettras du temps avant de pouvoir conclure que tu as une classe qui fonctionne.

Oui j'ai fini par saisir l'intérêt des tests unitaires. Je me souviens qu'au tout début je testais que 2*0 + 0 était bien égal à 0 :calim2:
Mais petit à petit j'ai fini par comprendre que c'était un outil très pratique pour formaliser, vérifier et simplifier les interfaces de classes/bibliothèques (même si ils sont pas parfaits/exhaustifs :? ).

Par exemple je me sentais obligé de vérifier dans le code client que chaque instance d'une classe A était dans un état cohérent après modification. Avec les tests unitaires j'ai compris qu'en fait ça voulait simplement dire que ne pouvais pas avoir confiance en ma classe A. Donc après m'être senti un peu stupide j'ai retroussé mes manches et j'ai appris un peu de technique (genre les unique_ptr et les parameter packs ^^) et j'ai fait en sorte que la classe soit incassable (jusqu'à maintenant et preuve du contraire :mouarf:). Du coup même si c'est pas parfait j'ai un peu plus confiance, ma bibliothèque est plus facile à utiliser correctement et plus difficile à maltraiter : merci les tests ;)

Tu iras loin petit :D

Aussi loin que mes frêles jambes de biologiste voudront me porter ;)