Discussion :

[Eduardo Rocha]

La programmation en C++ est difficile, le g�nie logiciel en C++ est encore plus difficile

EDUARDO ROCHA 26-06-2023 G�nie logiciel
Mis � jour le 6 juillet 2023.

Il existe probablement une corr�lation entre les comp�tences en programmation C++ d�une personne donn�e et sa capacit� � d�velopper des logiciels dans ce langage. Cependant, ces deux aspects sont distincts et n'�voluent pas toujours ensemble. Il est naturel de supposer que la ma�trise de C​++ se traduit directement par la capacit� de d�velopper des logiciels en C​++, mais les deux ne sont pas toujours synonymes. Cet article explique comment la complexit� du C​++ cr�e des d�fis pour le g�nie logiciel. Il traite �galement de l'importance de la simplicit� pour la maintenabilit� et le succ�s � long terme.

Le g�nie logiciel et la programmation ne sont pas la m�me chose.
� Le g�nie logiciel peut �tre consid�r� comme une "programmation int�gr�e au fil du temps". �
_ G�nie logiciel chez Google

C++ est complexe, le g�nie logiciel n�aime pas �a

C++ est un cas particulier en raison de sa complexit�. Il offre de nombreuses fa�ons d'accomplir la m�me chose et il comporte �galement de nombreux pi�ges. C++ est un langage si puissant que les d�veloppeurs ont mis au point une infinit� de mod�les de programmation. Toutefois, le g�nie logiciel n'aime pas la complexit� et ne s'entend pas naturellement avec le C++. Peut-�tre que cela n'est pas visible dans les petits projets ou les �quipes, mais consid�rez les d�fis lorsque des dizaines, voire des centaines d'ing�nieurs travaillent sur la m�me base de code comprenant des centaines de milliers de lignes.

Tout comme C, C++ attend du d�veloppeur qu'il soit un expert et qu'il l'utilise avec soin. Se tirer une balle dans le pied est assez facile. Pour les projets � grande �chelle avec plusieurs d�veloppeurs, o� seulement quelques-uns seront des experts, le soin et l'attention de toutes les personnes impliqu�es sont indispensables.
Par exemple, consid�rez les principes de g�nie logiciel suivants :

1. �Vous n'en aurez pas besoin. � �You aren�t gonna need it� (YAGNI) stipule qu'un programmeur ne doit pas ajouter de fonctionnalit�s avant de les avoir jug�es n�cessaires. C++ propose de nombreuses mani�res diff�rentes d�aller � l�encontre de ce principe. Il est tentant de faire d'une fonction ou d'une classe un mod�le afin qu'il puisse �tre r�utilis� pour diff�rents types de donn�es, m�me s'il est actuellement utilis� pour un seul type. Cela rend le code plus difficile � lire, augmente le temps de compilation et d�grade l'utilisation d'outils tels que les analyseurs statiques et les compl�teurs de code. Par cons�quent, cela ne devrait pas �tre fait � moins qu'il n'y ait un besoin pour cela.
2. �vitez l'optimisation pr�matur�e. C'est un principe bien connu qui peut �tre ignor� dans n'importe quel langage de programmation. Toutefois, si vous utilisez C++ dans un projet, c�est probablement parce que vous avez besoin de bonnes performances. Donc, un certain niveau d'optimisation est n�cessaire ; parfois, il faudra m�me beaucoup d'optimisation. Le probl�me est qu'il est difficile de d�limiter, au sein d'un projet, le code qui doit �tre optimis� et le code qui n�en aura pas besoin. C++ nous donne les outils pour tout optimiser et nous optimisons souvent plus que n�cessaire.

J'adore C++ et c'est mon langage de pr�dilection par d�faut. S'il est utilis� correctement, il fera au moins aussi bien que la plupart des autres langages. Cependant, reconna�tre les dangers et les pi�ges potentiels du langage est la premi�re �tape vers un d�veloppement sain.

La simplicit� est la cl� d'une bonne ing�nierie logicielle et C++ par d�faut n'est pas simple.

Simplifiez lorsque cela est possible !

Le parcours d'apprentissage de C++ a souvent plusieurs pics de confiance. Plus vous apprenez, plus vous r�alisez � quel point vous ne savez pas. Et je crois que cela cr�e un mod�le int�ressant. Les d�veloppeurs exp�riment�s ont tendance � se limiter � des sous-ensembles du langage et � des sous-ensembles de mod�les de programmation suffisants et s�rs. Cette approche est efficace pour simplifier le langage pour un d�veloppement facile et maintenable.
Je ne fournirai pas de recette pour le faire. Je ne suis pas s�r d'�tre qualifi� pour le faire. Une chose que je peux dire, c'est qu'un code simple est g�n�ralement meilleur que le code optimal et le plus performant. En C++, le code optimal est souvent difficile � lire, difficile � comprendre et, surtout, difficile � maintenir. Je dirais qu'une grande partie de la programmation C++ peut �tre d�crite comme une optimisation pr�coce � petite �chelle.

Un autre probl�me est que l'�criture de code complexe peut �tre amusante et, parfois, belle. De nombreux d�veloppeurs tombent amoureux de C++ pour cela. Beaucoup d'entre nous trouveront de la joie en utilisant des motifs complexes pour le plaisir. N�anmoins, le probl�me est que le code devient souvent plus compliqu� qu'il ne devrait l'�tre. Moi-m�me, j'en suis coupable. Les d�veloppeurs qui entrent dans ce groupe devraient au moins �tre conscients de ce qu'ils font afin qu'ils puissent r�fl�chir � deux fois avant de trop compliquer les choses pour le plaisir. J'ai travaill� avec des gens qui s'int�grent tr�s bien dans ce groupe, mais qui ne le savent pas. Beaucoup per�oivent l'ajout d'une complexit� inutile comme une d�monstration de comp�tence et ne voient pas ses inconv�nients (ou ne s'en soucient tout simplement pas).


� Le d�bogage est deux fois plus difficile que l'�criture du code. Par cons�quent, si vous �crivez le code aussi intelligemment que possible, vous n'�tes, par d�finition, pas assez intelligent pour le d�boguer.
� Brian Kernighan

Si la simplification n'est pas possible, encapsulez les bits complexes

Si vous utilisez C++, c�est probablement parce votre projet n�cessite de bonnes performances. En outre, des mod�les de conception plus complexes peuvent �tre n�cessaires ou peuvent entra�ner un code plus simple. Dans ces cas, C++ fournira les bons outils pour le travail, mais le code r�sultant peut ne pas �tre facilement lisible ou facile � lire ou � comprendre.

Heureusement, C++ fournit �galement les outils pour encapsuler correctement et cacher cette complexit�. Ici, suivre les principes de l'ing�nierie logicielle comme SOLID avec une attention et un soin suppl�mentaires peut guider le d�veloppeur vers le succ�s.

Le temps suppl�mentaire n�cessaire pour le faire correctement pour les pans les plus complexes (par exemple, une conception plus approfondie et des r�visions de code) en vaut la peine � long terme.

Principaux points � retenir

1. C++ est connu pour sa grande complexit� et offre de nombreux mod�les de programmation. Cependant, le g�nie logiciel, qui met l'accent sur la simplicit� et la maintenabilit�, peut ne pas s'aligner facilement avec les subtilit�s du C++.
2. Simplifiez C++ pour un d�veloppement maintenable. L'�criture de code facile � comprendre et � maintenir est g�n�ralement plus pr�cieuse pour le succ�s � long terme que l'�criture de code optimal et all�g�.
3. Soyez conscient de la complication excessive et de l'optimisation pr�coce. Tenez-vous et vos coll�gues responsables.

La prochaine fois que vous interviewerez quelqu'un pour un poste senior en C++, ne demandez pas au candidat � quel point il est bon en C++, posez-lui des questions sur les pi�ges du C++ pour le g�nie logiciel. Il sera tr�s facile d'identifier des ing�nieurs ayant une exp�rience de d�veloppement pertinente.

Faire ce qui pr�c�de est plus facile � dire qu'� faire. Parfois, des mod�les de programmation complexes avec des fonctionnalit�s de langage complexes se traduiront par un code plus simple et meilleur. Apprendre � le faire n�cessite non seulement de l'exp�rience, mais aussi de la sensibilisation. J'esp�re que ce billet augmentera votre sensibilisation.

Je tiens � souligner que cet article a �t� �crit sur la base de mes propres fortes opinions. Donc, si vous �tes d'accord ou si vous avez un point de vue diff�rent, j'aimerais l'entendre ! N'h�sitez pas � laisser un commentaire ou � nous contacter.

La version originale de cet article

Et vous ?

Que pensez-vous de la programmation en C++ ?
Pensez-vous que la programmation en C++ est vraiment difficile ? Partagez vos avis.

[epsilon68]

J'ai vraiment aim� le c++, j'ai commenc� dans ce language. Je me suis m�me �clat�, j'avais tout fait enti�rement.

La conception logiciel est la clef de tout d�veloppement, et elle est plus dure en C++ car il faut d�finir qui est le propri�taire de chaque objet (Cependant, m�me si les gens ne le font pas en java ou c#, c'est un m�ga tort, et fait du code peu fiable.) et d�finir une bonne API est une chose complexe, mais dans tous les languages.

Apr�s je pense que la difficult� ultime est la reprise du code par quelqu'un d'autre. Ma derni�re exp�rience �tait en C# et �tait tout bonnement horrible, cependant il est assez ais� de faire du refactoring en C#.

J'avoue que je me suis dit, tellement j'ai souffert, qu'au vu de ce que des personnes peuvent faire en C#, je n'imagine pas ce qu'ils peuvent faire en C++. Aurais-je r�ussi � modifier et faire �voluer le programme ? je n'en suis pas s�r car le code est 10x plus difficile � lire, mais aussi 10x plus difficile � refactorer en C++.

Je ne sais pas si je reviendrais un jour � programmer en C++, je ferais surement un audit du code avant de me d�cider 🫣

ps: � tous les managers et DSI : vous �tes responsable de la situation dans laquelle vous avez mis vos �quipes, �tre dans le d�ni ne sert � rien, la r�alit� reviendra toujours au plus mauvais moment avec des cons�quences toujours plus grandes.

[Madmac]

Je ne sais pas si je reviendrais un jour � programmer en C++, je ferais surement un audit du code avant de me d�cider 🫣

[Madmac]

1. �Vous n'en aurez pas besoin. � �You aren�t gonna need it� (YAGNI) stipule qu'un programmeur ne doit pas ajouter de fonctionnalit�s avant de les avoir jug�es n�cessaires. C++ propose de nombreuses mani�res diff�rentes d�aller � l�encontre de ce principe. Il est tentant de faire d'une fonction ou d'une classe un mod�le afin qu'il puisse �tre r�utilis� pour diff�rents types de donn�es, m�me s'il est actuellement utilis� pour un seul type. Cela rend le code plus difficile � lire, augmente le temps de compilation et d�grade l'utilisation d'outils tels que les analyseurs statiques et les compl�teurs de code. Par cons�quent, cela ne devrait pas �tre fait � moins qu'il n'y ait un besoin pour cela.
2. �vitez l'optimisation pr�matur�e. C'est un principe bien connu qui peut �tre ignor� dans n'importe quel langage de programmation. Toutefois, si vous utilisez C++ dans un projet, c�est probablement parce que vous avez besoin de bonnes performances. Donc, un certain niveau d'optimisation est n�cessaire ; parfois, il faudra m�me beaucoup d'optimisation. Le probl�me est qu'il est difficile de d�limiter, au sein d'un projet, le code qui doit �tre optimis� et le code qui n�en aura pas besoin. C++ nous donne les outils pour tout optimiser et nous optimisons souvent plus que n�cessaire.

Le deuxi�me paragraphe est valable, mais pas le premier. La vitesse de compilations n'est pas un argument valable. La vitesse du code est la seule chose qui compte quand il est question de compilation. Un g�n�ral, les programmeurs d'exp�rience font ce genre de truc en sachant que cette classe aura des descendants. Ou pour �viter de fabriquer des constantes et variables globales Et parce que cela permet de d�finir les noms des m�thodes et de variables, � l'avance, afin encadrer les programmeurs qui travailleront avec ce code.

Si vous utilisez C++, c�est probablement parce votre projet n�cessite de bonnes performances. En outre, des mod�les de conception plus complexes peuvent �tre n�cessaires ou peuvent entra�ner un code plus simple. Dans ces cas, C++ fournira les bons outils pour le travail, mais le code r�sultant peut ne pas �tre facilement lisible ou facile � lire ou � comprendre.

Heureusement, C++ fournit �galement les outils pour encapsuler correctement et cacher cette complexit�. Ici, suivre les principes de l'ing�nierie logicielle comme SOLID avec une attention et un soin suppl�mentaires peut guider le d�veloppeur vers le succ�s.

La POO a �t� inventer avant tout pour produire du code avec des groupes de programmeurs. Si la vitesse est votre premier soucie, SOLID est � �viter comme la peste. Il est difficile � optimiser. Et DRY est encore pire. La POO a la r�putation de produire des programmes lents alors qu'en r�alit� la cause principale est l'adoption de SOLID. SOLID permet la PRODUCTION de code plus rapidement. POINT!.

Mark Zuckerberg a fait la premi�re version de Facebook en Ruby alors que le langage �tait trois fois plus lent. parce qu'il avait compris que la premi�re qualit� qu'un programme se doit d'avoir est de fonctionner.

�Done is better than perfect.�

-Mark Zuckerberg

[ternel]

L'objectif de SOLID est de produire du code solide: r�sistant au passage du temps, au changement de d�veloppeurs, etc. On dit aussi "maintenable".
Il permet de r�duire les bugs (disparition totale de classes enti�res de bugs comme l'oubli de fermeture d'une session, d'une connexion, etc)

Je n'ai jamais vu SOLID rendre un programme �crit en POO plus lent, moins optimis�. As-tu des t�moignages, des �tudes ou des exemples concrets la-dessus?

[jo_link_noir]

Les principes SOLID ont une approche tr�s OO dans leur description, mais en fait, ce n'est pas SOLID qui rend moins opti ou plus lent, mais la POO dans certains contextes.

Par exemple, si on poss�de un tableau d'un type quelconque qui contient 3 �tats qu'on veut manipuler, on va g�n�ralement faire une boucle sur chaque �l�ment qui manipule l'�tat 1, puis le 2, puis le 3. Si les calculs d�pendent du r�sultat de l'�tat pr�c�dent, on va faire une boucle qui manipule l'�tat 1, puis une boucle pour l'�tat 2 et pareil pour le 3�me.

Il s'av�re que cette approche est g�n�ralement moins optimale que 3 tableaux qui repr�sente chacun un �tat, car elle engendre plus de perte de cache. C'est la diff�rente entre SoA (Structure of Array) et AoS (Array of Structure).

� ce niveau, on s�int�resse plus aux valeurs que contiennent nos structures plut�t qu'� une abstraction qui permet de les manipuler de mani�re transparente. Dans ce contexte on se retrouve en opposition avec les principes SOLID. De toute mani�re, une approche OO ne fonctionne pas bien ici, on va plut�t faire de la programmation orient�e data.

Par contre, quand l'OO est adapt�, SOLID est utile et je suis du m�me avis que toi sur la maintenabilit�.

Par contre, je ne vois en quoi SOLID permet la disparition totale des fermetures d'une connexion ? Pour moi c'est le RAII qui fait permet cela ou autre selon le langage (le mot clef finally, les contextes manag�s, etc)

[koala01]

Salut,

Humm, je ne suis pas aussi cat�gorique que toi..

Il est vrai que le L de SOLID (LSP, mis pour Liskov Substitution Principle) est -- tr�s clairement orient� objet, vu qu'il parle du seule principe qui soit effectivement sp�cifique � l'OO : la substituabilit�.

Mais pour les autres...

Il n'y a -- par exemple -- absolument aucune difficult� � s'assurer qu'une fonction fasse une chose et une seule, m�me dans un contexte "non OO", que l'on adopte l'approche AOS ou SOA ne changera sans doute absolument rien : une fonction sera toujours plus facile � tester et � maintenir si elle ne s'occupe effectivement que d'une chose et d'une seule.

Il en va d'ailleurs de m�me avec l'OCP : Il est "relativement facile" de s'arranger pour "fermer son code" aux modifications (eg : pour faire en sorte qu'un comportement �crit, test� et valid� ne doive pas �tre modifi�) mais pour "l'ouvrir" aux �volutions. Et dans ce cas encore, AOS ou SOA n'y changera rien ... � moins bien sur que l'on d�cide de passer de l'un � l'autre.

Quant aux deux derniers -- ISP et DSP --j'ai d'avantage tendance � les consid�rer comme les pistes privil�gi�es � envisager pour am�liorer le respect des trois premiers ou, selon la situation, comme le "r�sultat naturel" d'une tentative (r�ussie) d'am�liorer le respect des trois premiers.

Apr�s, on peut bien sur discuter des heures sur "ce qui fait" r�elleement "l'approche OO". M'�tant d�j� exprim� sur le sujet, je ne le ferai ici que si on m'en fait la demande Mais comme vous le savez, j'ai un avis "plut�t tranch�" et sans doute tr�s diff�rents de la plupart des gens

Mais, quoi qu'il en soit, il faut se souvenir que SOLID sont -- d'abord et avant tout -- des principes de conception, ce qui implique que l'on doit (ou du moins, que l'on devrait) s'assurer :

1. que la mani�re dont on envisage de faire les choses les respecte les respecte avant d'�crire la moindre ligne de code et
2. que la mani�re dont on �crit effectivement le code continue � les respecter "tout au long du processus"

[jo_link_noir]

Il n'y a pas que L qui saute, il y a aussi le D et je ne vois pas vraiment comment appliquer l'ouverture du O sans point de variation disponible. �a va �tre compliqu� de faire des extensions sans faire de modification.

Pour moi il n'y a que le S (et le I qui va bien avec) qui est un principe plut�t logique, mais qui poss�de certaines limites: plus on poss�de de contexte plus il est "facile" de trouver des optimisations. Par cons�quent, 2 fonctions peuvent �tre fusionn�es pour faire la m�me chose de mani�re plus efficace. Je ne vais pas dire que cela arrive souvent, c'est m�me plut�t rare, mais c'est quelque chose qui arrive un peu plus souvent quand on se concentre sur nos donn�es.

[koala01]

Pour le D, on peut encore disucter, bien que, de mani�re g�n�rale, il s'appliquerait en SOA en transmettant de pr�f�rence la structure compl�te (ou, � d�faut, l'un des tableau qui la compose) plut�t que la donn�e sp�cifique que l'on trouve dans un tableau sp�cifique et qui nous int�resse "tout particuli�rement".

Car, quoi que l'on en dise, un tableau reste une abstraction, et une structure aussi

Quant au O, ben, en fait, il vient main dans la main avec le S en SOA, dans le sens o�, si chaque fonction ne fait qu'une et une seule chose, si tu veux faire �voluer une de tes structures de tableaux, tu vas sans doute rajouter un nouveau tableau � cette structure et ... les fonctions qui "vont bien" pour en g�rer les donn�es (dans le respect de SRP).

Et, pour profiter de cette �volution, tu peux "simplement" cr�er ... une nouvelle fonction qui fait appel aux fonctions "complexes" existantes et qui int�grent les fonctions de base que tu viens d'ajouter pour l'�volution. Ce qui se fait dans le respect de l'OCP.

Bien sur, nous sommes d'accord sur le fait qu'il puisse, peut-�tre (surement), parfois (souvent), sembler (�tre r�ellement) plus int�ressant d'aller modifier les fonctions complexes existantes que d'aller cr�er une fonction s�par�e qui prenne l'�volution en charge... Mais ca, c'est la grosse tentation que l'on a de mani�re syst�matique, et c'est justement la raison pour laquelle l'OCP existe

[jo_link_noir]

Mhouais, ce n'est pas vraiment ce que j�appelle de l'OCP. Ce que tu me d�cris me fait plus penser � l'�quivalent d'une nouvelle classe sans parent�. Pour moi, l'OCP est la capacit� � faire des points de variation -> du polymorphisme. La majorit� du temps, quand on fait des points de variation sur des donn�es, on se retrouve � modifier du code existant, ce qui ne respecte pas l'OCP. Exemple b�te, les visiteurs / std::variant.

[koala01]

Pour moi, l'OCP est la capacit� � faire des points de variation -> du polymorphisme

L'OCP est un principe (de conception), le polymorphisme est un concept (de programmation) ...

Tu fais simplement l'erreur de placer la relation entre le principe et le concept dans le mauvais sens : l'OCP c'est "l'objectif � atteindre", la r�gle qu'il faut s'arranger pour respecter, le polymorphisme c'est le moyen (en fait l'un des moyens) qui nous est donn� pour y arriver...

Cependant, le polymorphisme n'est pas -- loin s'en faut -- le seul moyen qui nous permettra de respecter l'O.

Car l'OCP nous dit simplement que

le code doit �tre ferm� aux modification, mais ouvert aux �volutions"

Autrement dit, tu ne dois pas (ou, du moins, tu ne devrais pas) avoir � modifier un code existant -- qui a �t� test� et valid� -- (c'est l'aspect "ferm� aux modifications") afin d'�tre en mesure d'int�grer une �volution (c'est l'aspect "ouvert aux �volutions")

Ou, si tu pr�f�res, tout ce que te demande en r�alit� l'OCP, c'est de faire en sorte (ou du moins d'essayer) que le code que tu as �crit avant-hier et valid� hier ne devra pas modifi� demain pour te permettre d'int�grer l'�volution suivante.

Peu importe comment tu y arrives !!!

Au mieux, il est possible de d�conseiller certaines pratiques, comme le RAII (if (dynamic_cast< ... *>(ptr)!= nullptr ) ou un �quivalent � peine cach� sous forme d'un switch ... case (ou n'importe quel switch case dont on aurait de bonnes raisons de croire que le nombre de valeurs envisag�es risque d'augmenter � chaque �volution)


Et, de ce point de vue l�, le SRP te donne "une autre cl�" nous permettant d'assurer le respect de l'OCP; m�me si c'est de mani�re un peu plus indirecte

Car, mieux le SRP sera respect�, plus tu pourras partir du principe que les fonctions qui le respectent le mieux seront celles qui... auront le moins besoin d�tre modifi�es pour permettre "l'�volution suivante".

Tu n'as m�me pas besoin d'�tre dans une approche orient�e objets ... Tu as juste besoin de te rendre compte que ta fonction "super complexe" (ou peut �tre pas tant que cela) prend en r�alit� en charge "un certain nombre" de responsabilit�s qui auraient parfaitement pu �tre "ventil�es" vers des fonctions "beaucoup plus simples"

D'ailleurs, je vais m�me aller (beaucoup) plus loin : � part LSP, qui est vraiment tr�s sp�cifique, et peut �tre l'ISP qui, � un certain niveau, ne pourra que t'inciter � ne pas *** forc�ment *** exposer toutes les fonctions que tu as cr��es, les trois autres principes (SRP, OCP et DIP) se tiennent pour ainsi dire par la main! Laisses moi m'expliquer avant de hurler, s'il te plait

Le SRP t'incite � cr�er des fonctions qui n'ont qu'une et une seule responsabilit�. Soit ...

On pourrait donc croire qu'une fonction de tri ne prend qu'une seule et unique responsabilit� : celle de ... trier les �l�ments qui lui sont donn�s. On est d'accord

Ben, en fait ... non, je ne suis pas "tout � fait d'accord" car -- je l'admets, je coupes les cheveux en quatre -- pour pouvoir d�cider de d�placer les �l�ments, il faut -- d'abord et avant tout -- qu'elle les compare deux � deux. Et cette comparaison est une responsabilit� qui m�riterait, selon les termes du SRP, d'�tre prise en charge par une fonciton sp�cifique.

Le mieux de l'histoire, c'est que si tu "extrait" effectivement cette fonction de comparaison de ton algorithme de tri, ta fonction de tri n'a ... plus aucune raison d'�tre modifi�e une fois qu'elle a �t� valid�e (� moins, bien sur, que tu d�cide de changer d'algorithme de tri ) Voil� donc l'OCP qui se pointe "tout naturellement" car, que tu veuilles un tri "croissant" ou "d�croissant", il n'y a finalement plus que ... la mani�re dont la comparaison sera effectu�e qui devra �tre modifi�e si tu veux passer de l'un � l'autre.

Au pire, tout ce qu'il te reste � faire, c'est de permettre � la personne qui veut utiliser la m�thode de tri que tu as d�velopp�e de choisir la fonction de comparaison qui lui convient (et, pourquoi pas, d'en s�lectionner une "par d�faut", pour la facilit�).

Et si, au lieu de parler de "fonction de comparaison", nous venions parler de "comparateur" Il s'agirait toujours de la m�me "fonction de comparaison", cependant, le simple fait de lui avoir choisi un autre terme qui "puisse sembler plus adapt�" pour la d�signer, et ... Bardaf : nous voil� avec un "zolie abstraction".

Et devine quoi Si je d�cide de faire d�pendre ma fonction de tri de l'abstraction (d�sormais) connue sous le nom de "comparateur", voil� le respect du DIP qui arrive en courant !

Car, � partir du moment o� tu est -- effectivement -- en mesure de fournir deux �l�ments � ton "comparateur" et qu'il te permet de d�terminer la relation A <comparaison> B est valide, il peut parfaitement te servir dans ta fonction de tri. Et ce, quelle que soit la forme effective de ton "comparateur", pour autant que nous nous soyons mis d'accord sur la mani�re de l'utiliser

Il est aussi vrai qu'il serait sans doute particuli�rement int�ressant d'aborder une approche g�n�rique dans le cadre de cet exemple. Et pourtant, la logique de SRP appelant OCP et DIP dans la foul�e est susceptible de s'appliquer ... quel que soit le paradigme envisag�

La majorit� du temps, quand on fait des points de variation sur des donn�es, on se retrouve � modifier du code existant, ce qui ne respecte pas l'OCP. Exemple b�te, les visiteurs / std::variant.

Peut-�tre est-ce l'occasion, ici, au calme du forum, d'essayer d'analyser les raison qui rendent cette situation possible, et, si possible, de dresser des pistes � envisager afin de l'�viter.

Bien sur, il sera surement beaucoup plus facile de suivre ces pistes sur un code de 100 fichiers que sur un code de 100 000 ... A moins que tu n'aies du temps � perdre dans une refactorisation compl�te

[jo_link_noir]

Tu t'es vachement centr�s sur la programmation g�n�rique. Dans ce que tu d�cris, le Comparator revient � une interface avec post et pr�-conditions, LSP a toute sa place. Ce dont je parle est un syst�me o� chaque type � son/ses propres algos (exit la g�n�ricit�), voir des interd�pendances. Du coup je reste sur ma position, l'OCP n'est pas le bienvenu.

[koala01]

Tu t'es vachement centr�s sur la programmation g�n�rique.

M�me pas...

Il faut juste garder en t�te qu'une fonction n'est ... que le moyen de faire comprendre � quelque chose d'aussi b�te qu'un oridanteur le comportement que l'on attend de lui � un moment pr�cis.

Et il faut donc garder en t�te le fait que ce comportement est destin� � nous fournir un r�sultat "clairement d�fini", "pr�dictible" et "reproductible":

• clairement d�fini : C'est ce que l'on a le plus facile � obtenir, pour autant que l'on choisisse correctement le nom de la fonction... Il vaut mieux choisir un nom qui �voque clairement ce que la fonction est sens�e faire
• pr�dictible : M�me si cela doit te demander "un certain temps" de le faire "� la main", tu es (ou devrais �tre) en mesure de d�terminer � l'avance le r�sultat que tu obtiendra en appelant ce comportement (cette fonction) avec un jeu de donn� sp�cifique (et dans une situation donn�e)
• reproductible : si tu appelles deux fois le m�me comportement avec les m�me donn�es (et dans les m�me circonstances) tu obtiendra deux fois le m�me r�sultat.

Et, � partir de l�, on peut partir sur le SRP: une fonction ne devrait faire qu'une et une seule chose pour s'assurer de la faire bien

C'est � dire que, si une fonction doit faire deux chose (comme "comparer" et "r�arranger" pour reprendre mon exemple pr�c�dent), c'est -- peut-�tre -- qu'elle en fait une de trop. Tu devrais (pourrais) donc envisager "d'extraire" le comportement qui consiste � comparer deux �l�ments de celui qui consiste � les r�arranger.

Alors, bien sur, ce qui nous int�ressant dans le comportement de comparaison, c'est le r�sultat que l'on obtient, et il faut donc ... un moyen de l'obtenir; mais c'est le propre de tout comportement, de toutes fonctions, non

Et il semble "logique" de se dire que, ayant extrait le comportement "plus simple" qui consite � effectuer la comparaison de la fonction de "r�arrangement", il faudra trouver un moyen -- n'importe lequel (fusse un pointeur de fonction) -- de faire en sorte que le comportement de r�arrangement "sache" quel comportement de comparaison appeler et, surtout, comment l'utiliser : quelles donn�es lui transmettre, dans quel ordre, et comment interpr�ter le r�sultat.

L'abstraction n'arrivant que ... parce que je d�cide d'appeler ce comportement de comparaison "compare", "comparator" ou encore "compareFunction" car je trouve cela plus clair que de l'appeler simplement "ptr" (ou "funcptr").

Dans ce que tu d�cris, le Comparator revient � une interface avec post et pr�-conditions,

Mais toute fonction testable a interface (comment l'utiliser) , pr�condition (sur les donn�es � transmettre) et postconditions (r�sultat escompt�) ... Ou � tout le moins l'un ou plusieurs de ces �l�ments

• Le simple fait de typer un param�tre va -- forc�ment -- imposer une pr�condtion car, si ce n'est pas le type ad�quat (ou, au pire, si on ne sait pas convertir la donn�e fournie dans le type ad�quat), tu es dans la merde...
• La moindre v�rification de validit� du r�sultat � l'int�rieur de la fonction n'est jamais qu'une mani�re de t'assurer du respect d'une post condition
• Et l'interface ne fait jamais qu'exposer la mani�re dont tu vas l'utiliser : cr�er un pointeur de fonction qui renvoie une donn�e d'un type donn� � partir de deux donn�es de type potentiellement identiques, c'est fournir une interface

LSP a toute sa place.

AAAhhh, non ... Du moins, pas dans le cadre de cette discussion ...

Le LSP ne s'int�resse qu'aux notions de "sous-typage" (faisons simple : d'h�ritage / impl�mentation des interface) et de substituabilit�. C'est d'ailleurs la raison de la pr�sence du S que l'on trouve entre principe et Liskov

La substituabilit� �tant la possibilit� de manipuler un objet de type B -- qui serait "sous-type de A" comme s'il s'agissait en r�alit� d'un objet du type A.

Pr� et post conditions (ainsi qu'invariant) �tant des notions intervenant dans la programmation par contrat. Si tu me donnes des donn�es valides et coh�rentes (pr�conditions), je dois pouvoir te fournir un r�sultat valide, coh�rent, pr�dictible et reproductible (post conditions) ...

Ce qui se passe, c'est que tu confonds encore une fois le "quoi" et le "comment" : le "quoi" �tant la substituabilit�, et le comment �tant -- entre autres -- compos� de la programmation par contrat, celle-ci ne faisant que te donner "des pistes � suivre" pour obtenir une substituabilit� coh�rente

Ce dont je parle est un syst�me o� chaque type � son/ses propres algos (exit la g�n�ricit�)

Je viens de t'expliquer que la g�n�ricit� n'est pas une fin en soi, mais, � partir du moment o� elle peut arriver "naturellement" ... simplement parce que tu as respect� le SRP, une fois qu'elle est possible (ou facilit�e), il serait peut-�tre dommage de ne pas en profit� en cas de besoins

voir des interd�pendances.

Ahh, les interd�pendances ...

Quelles qu'elles soient, c'est toujours un gros probl�me. Et le truc, c'est qu'il s'agit d'une boulle � facette, fa�on "soir�e disco"...

Car certaines viennent carr�ment d'une mauvaise conception au d�part. Et d'autres viennet aussi parfois de la mani�re dont le code est �crit. Le pire �tant qu'il y a tellement moyen d'en obtenir pour si peu de moyens de les �viter que cela peut devenir une gagure que d'essayer de les �viter

Ceci dit, je suis sur que tu penses sp�cifiquement � un cas bien particulier auquel tu auras �t� confront� "r�cemment".

Ceci dit, interd�pendances et OCP ne sont que les deux face d'une m�me pi�ce, dans le sens o�, plus tu as d'interd�pendances, moins il t'es ais� de respecter l'OCP et, � l'inverse, plus tu respecte l'OCP, moins tu as de risque de souffrir d'interd�pendance "fortes"

Du coup je reste sur ma position, l'OCP n'est pas le bienvenu.

C'est ton choix

Et je vais laisser les autres faire le leur ...

Pour ma part, j'aime simplement trop �crire sur un forum, et je me laisse beaucoup trop facilement emporter par ma plume

[jo_link_noir]

AAAhhh, non ... Du moins, pas dans le cadre de cette discussion ...

Le LSP ne s'int�resse qu'aux notions de "sous-typage" (faisons simple : d'h�ritage / impl�mentation des interfaces) et de substituabilit�. C'est d'ailleurs la raison de la pr�sence du S que l'on trouve entre principe et Liskov

La substituabilit� �tant la possibilit� de manipuler un objet de type B -- qui serait "sous-type de A" comme s'il s'agissait en r�alit� d'un objet du type A.

Pr� et post conditions (ainsi qu'invariant) �tant des notions intervenant dans la programmation par contrat. Si tu me donnes des donn�es valides et coh�rentes (pr�conditions), je dois pouvoir te fournir un r�sultat valide, coh�rent, pr�dictible et reproductible (post conditions) ...

Je vais la faire � l'envers. Comporator d�crit un type pouvant �tre d�crit par une interface ou un concept. Tout type correspondant au concept de Comparator �tant d'office un sous-type de Comparator. Sous-type ayant comme pr�-condition une fonction �quivalent � operator()(T const&, T const&) qui a comme post-condition un type convertible en bool. C'est de ce contrat que je parle. Tu remarqueras que je traite les types de la m�me mani�re que les valeurs, par cons�quent, contravariance et covariance ne sont que pr� et post-conditions. Mais comme de toute mani�re la notions de sous-typage peut �tre implicite quand bas� sur le comportement (comprendre truc et bidule sont d�finit, hop, �a en fait un sous type de X: duck-typing) et que la substituabilit� implique le respect d'un contrat, je ne me prive pas de r�duire le concept � des pr� et post-conditions.

[koala01]

Je vais la faire � l'envers. Comporator d�crit un type pouvant �tre d�crit par une interface ou un concept. Tout type correspondant au concept de Comparator �tant d'office un sous-type de Comparator. Sous-type ayant comme pr�-condition une fonction �quivalent � operator()(T const&, T const&) qui a comme post-condition un type convertible en bool. C'est de ce contrat que je parle.

Ca, c'est parce que tu as sp�cifiquement choisi une approche orient�e objet.

Mais la programmation par contrat peut s'appliquer d�s que tu te trouve face � un comportement dont tu veux garantir la "bonne ex�cution"

Si tu veux d�velopper une fonction "racineCaree", par exemple. Il faut que les entr�es respectent deux pr�-conditions:

1. elles doivent repr�senter une valeur num�rique
2. elles la valeur num�rique doit �tre strictement positive

Et le r�sultat obtenu doit respecter une post-condition : si tu multiplie le r�sultat par lui-m�me tu dois obtenir la valeur fournie en entr�e.

C'est aussi de la programmation par contrat... Il n'y a pourtant absolument rien qui pourrais te faire penser qu'elle ait �t� utilis�e dans une approche orient�e objet

Comparator n'est qu'une abstraction, qu'un terme que l'on va utiliser pour d�signer "aussi pr�cis�ment que possible" le genre de comportement que l'on est en droit d'attendre de sa part. Car on esp�re qu'il ne fera pas le caf�

Si tu bloques sur le terme "comparator", appelle le COMPARE_FUNCTION pour insister d'avantage sur le fait qu'il s'agit d'une fonction (ou plus vraisemblablement d'un pointeur de fonction), ca me va tr�s bien

Et si tu as une meilleure id�e de nom pour cette abstraction, vas-y, lache toi, fais toi plaisir

Le truc, c'est que l'on est "tellement habitu�" � utiliser la programmation par contrat dans le contexte d'une approche orient�e objets qu'on finit par ne m�me plus se rendre compte qu'elle peut tout aussi bien l'utiliser dans des contextes diff�rents.

Mais comme de toute mani�re la notions de sous-typage peut �tre implicite quand bas� sur le comportement (comprendre truc et bidule sont d�finit, hop, �a en fait un sous type de X: duck-typing) et que la substituabilit� implique le respect d'un contrat, je ne me prive pas de r�duire le concept � des pr� et post-conditions.

Tout � fait ...

Il me semble d'ailleurs que Liskov avait � l'origine �nonc� son principe dans une apporche fondamentalement fonctionnelle

Et, du coup, je me demande pourquoi tu voudrais absolument forcer Comparator -- bien que le terme ait sans doute �t� mal choisi et que tu aurais sans doute pr�fr� "COMPARE_FUNCTION" -- � rentrer dans le carcan Orient� Objets, alors qu'il s'agit simplement de ... la description intelligible d'un comportement prenant deux entr�es et te renvoyant une valeur bool�enne indiquant si la relation entre les entr�e correspond � celle que l'on recherche.

Car, ce que tu me dis, en substance, c'est:

Je file une valeur X et une valeur Y � un comportement, et, au sein de ce comportement, X et Y forment une coordonn�e

Si je donne deux valeur de X et deux valeurs de Y � un autre comportement, il manipule deux coordonn�es

(je simplifie, hein )

C'est cool ... Cette notion de "coordonn�e" n'est en fait qu'un abstraction "de type" (comprends : qui d�fini la repr�sentation des donn�es et la mani�re de les interpr�ter), qui m�riterait peut-�tre (ou pas du tout) d'apparaitre clairement dans ton code

Vas donc "un peu plus loin" dans le fait de cr�er tes abstractions en cr�ant ... des abstraction "comportementales". Comprends : si deux comportements prennent des entr�es �quivalentes et fournissent un r�sultat �quivalent; je peux les regrouper au sein d'une abstraction d�signant le "l'objectif g�n�ral" de ce comportement.

Peu importe la forme que cette abstraction "comportementale" prendra dans ton code.

Peu importe le nom que tu lui donneras, pour autant qu'il ne laisse aucun doute sur l'objectif de la fonction : si Comparator te fait trop penser � l'approche orient�e objets telle que vue par le C++, appelle cette abstraction COMPARE_FUNCTION si tu le souhaites

Peu importe la mani�re dont tu t'y prendra pour l'adapter aux diff�rents types de donn�es que tu manipule : Peut-�tre une approche bas�e sur les politiques et les traits serait-elle int�ressante � envisager ?

Tout cela rel�ve du domaine de l'impl�mentation. Et cela n'a rien � voir avec l'abstraction qui rel�ve du domaine conceptuel.

L'important �tant que, ayant respect� le SRP (� l'exces, vas tu peut-�tre penser), tu te donnes l'opportunit� en p�riode de conception de "voir �merger" de nouvelles abstractions qui seront en mesure de te faciliter la vie lorsqu'il sera question de respecter l'OCP.

[Madmac]

L'objectif de SOLID est de produire du code solide: r�sistant au passage du temps, au changement de d�veloppeurs, etc. On dit aussi "maintenable".
Il permet de r�duire les bugs (disparition totale de classes enti�res de bugs comme l'oubli de fermeture d'une session, d'une connexion, etc)

Ce que tu que tu d�cris sont les avantages d'un framework qui utilise l'h�ritage. Mais ce soucier de SOLID avant m�me d'avoir une id�e claire du r�sultat final am�ne les m�me risques que les microservices. SOLID devrait �tre consid�r� au m�me moment que le l'on passer � l'�tape de l'optimisation

Je n'ai jamais vu SOLID rendre un programme �crit en POO plus lent, moins optimis�. As-tu des t�moignages, des �tudes ou des exemples concrets la-dessus?

Le S de SOLID est le point le plus probl�matique. Si l'objet n'a qu'un type de responsabilit�, cela exclus les conversion. Donc tu dois fabriquer des classes (et des objets additionnelles)pour g�rer cette responsabilit�. Alors que plusieurs constructeurs pourraient faire l'affaire.

Et dans le cas des langages qui supportent les fonctions imbriqu�s, de grosses classes qui contiennent plusieurs objets sont parfaitement logique, car cela permet de remplacer des constantes globales en constante locale. Et de r�duire le nombre de param�tre des certaines fonctions.

Quelque fois utilis� une classe comme un domaine est la solution la plus performante. Plus on complexifie un programme, plus il devient difficile de l'optimiser. Donc avant de consid�rer SOLID, il est pr�f�rable de consid�rer Principe_KISS comme le crit�re le plus important.

[ternel]

KISS est tout autant l'essence du SRP.

J'applique SOID avec beaucoup d'int�r�t sans avoir � d�finir le moindre h�ritage. J'ai m�me tendance � consid�rer l'h�ritage comme un probl�me (en tout cas, la virtualit� et l'h�ritage publique)

RAII, dont les smart-pointers, sont un excellent moyen de supprimer les fuites de m�moire. D�montrable, robuste, OCP � fond, et sans h�ritage.
Une classe de connexion ssh aussi, toujours sans h�ritage.

SOLID est pour moi une pr�occupation pendant que je con�ois mon architecture.
C'est pour moi une application du principe d'encapsulation: si c'est fragile, je cloisonne et j'isole: SRP+OCP dans toutes les capsules. Pas d'h�ritage implique que L, I et D sont imm�diatement respect�s, puisque sans objet

[Madmac]

KISS est tout autant l'essence du SRP.

J'applique SOID avec beaucoup d'int�r�t sans avoir � d�finir le moindre h�ritage. J'ai m�me tendance � consid�rer l'h�ritage comme un probl�me (en tout cas, la virtualit� et l'h�ritage publique)

L'h�ritage n'est pas forc�ment un probl�me. Mais s'il est utilis� sur une portion de code tr�s utilis� (genre � l'int�rieur d'une �norme boucle). Ou que le programme doit chercher une m�thode sur plus d'une g�n�ration. Alors il est pr�f�rable de recopier les m�thodes communes � tous ces classes.Le truc est de savoir, o� l'h�ritage est susceptible de nos faire perdre de la vitesse.

Les "smart pointers" ont les m�me handicaps que l'h�ritage. L'approche SOLID cohabite tr�s avec les assemblages par composition (module en Ruby, Traits en Rust). En C++, c'est possible par l'inclusion d'une classe polymorphique avec id�alement un minimum de m�thode. En terme de performance c'est le meilleur des mondes. Polymorphisme de l'h�ritage. Et la performance d'une fonction. Pourquoi? Parce que l'h�ritage n'est utilis� qu'� un seul endroit: Pendant la cr�ation de l'objet. Ce qui fait que le compilateur compile les m�thodes de la m�me fa�on que des "fonctions amis".