Version imprimable
Hello,
J'ai un petit souci avec lesprincipes suivants de SOLID :
- SRP (Single Responsability Principle)
- OCP (Open Closed Principle)
Si je prends une classe rectangle, et que je veux pouvoir dessiner le rectangle et calculer sa surface :
- SRP me dit que ces deux fonctionnalités doivent être sorties de la classe (car après tout, il y a 2 fonctionnalités)
- OCP me dit de les mettre dedans (voir par exemple ce lien)
Du coup, je ne sais plus où donner de la tête.
De la façon dont j'ai compris SRP, ce n'est pas parce que ton rectangle doit pouvoir faire deux choses différentes (s'afficher et calculer sa surface) qu'il doit être séparé en deux objets distincts. L'unicité de responsabilité s'applique aux atomes sémantiques, c'est à dire aux fonctions, pas aux objets. Il est normal qu'un objet fournisse plusieurs services, c'est même, à mon avis, le principe de la poo. Sinon on ferait du fonctionnel.
SRP pour Property.
Je ne comprends pas du tout ton raisonnement, OCP ne veut pas dire du tout qu'il faille mettre deux méthodes à responsabilité distincte dans le même sac :/
Et d'ailleurs SRP ne dis pas non plus que parce que ta classe doit fournir deux services il faut faire deux classes :/
Si nos experts reconnus fatiguent on est mal barrés les gars :mrgreen:
On pourrait dessiner avec 2 bibliothèques différentes.Citation:
Envoyé par r0d
On pourrait calculer la surface selon deux projections géodésiques différentes.
Il y a donc plus d'1 raison de changer la classe -> scission (d'après ce que j'ai compris du SRP).
Si tu veux dessiner une liste de formes géométriques, il semble opportun d'avoir disons un vecteur d'une classe parente, et d'appeler une méthode polymorphique de dessin sur chaque objet.Citation:
Envoyé par Kaamui
Si tu veux effectuer une transformation sur une liste de formes géométriques, il ne semble pas déraisonnable de suivre la même chose. Or, l'affichage et les transformations géométriques sont deux responsabilités différentes, non ?
Non, c'est bien principe.Citation:
Envoyé par Kaamui
@oodini
C'est une question de choix personnel et de limite où tu veux aller dans ton design.
Si tu considères que ton élément Rectangle n'évoluera pas, alors tu peux donner la responsabilité unique "représenter le concept rectangle" à ta classe Rectangle et les RU "calculer la surface" et "dessiner un rectangle" à tes fonctions surface() et draw().
Par contre, tu peux aussi considérer que Rectangle entre dans un ensemble plus large, par exemple des polygones. Alors, ta classes Rectangle aura déjà beaucoup à faire avec la gestion des points (qui peuvent être à N dimensions), vérifier que le polygone est bien un rectangle (largeur et hauteur identique, angle droit, dans un même plan, etc). Dans ce cas, tu peux décider que la responsabilité du rendu du rectangle doit être pris en charge par une classe dédiée, qui aura beaucoup à faire aussi (gérer la projection en 2D à partir de ND, vérifier que le contexte de rendu est valide, optimiser le rendu, etc)
Et tu pourrais ainsi augmenter le nombre de classes (et donc séparer les responsabilités) selon la "précision" que tu veux avoir. Voir par exemple Boost.Geometry qui défini des classes pour les systèmes de coordonnées, pour les polygones, pour les algos, etc
Bref, c'est qu'une question de choix "statégiques". Le principal est surtout de savoir pourquoi ces principes existent, savoir les problèmatiques qu'ils permettent à éviter et savoir quand on choisit un design les conséquences de son choix (bons ou mauvais : temps de dev, complexité de dev, évolutivité, maintenabilité, etc)
C'est un peu la réponse que je souhaitais avoir.
J'ai l'impression que les principes SOLID, comme les design patterns, sont des choses à toujours avoir à l'esprit, qui nous accompagnent dans nos choix architecturaux, mais à ne pas appliquer systématiquement.
Oui, c'est ce que j'ai ajouté dans mon EDIT (mais tu as répondu plus vite que moi)
Par contre, comme toute les règles, les principes de POO doivent être respecter scrupuleusement...Citation:
Bref, c'est qu'une question de choix "statégiques". Le principal est surtout de savoir pourquoi ces principes existent, savoir les problèmatiques qu'ils permettent à éviter et savoir quand on choisit un design les conséquences de son choix (bons ou mauvais : temps de dev, complexité de dev, évolutivité, maintenabilité, etc)
Et comme toutes les règles, elles peuvent être enfrein :)
(plus précisement, on voit souvent des débutants ne pas maîtriser une règle, mais ne pas l'appliquer suite à la lecture d'un article disant que l'on pouvait ne pas respecter cette règle. C'est une erreur : on peut se permettre de ne pas respecter une règle quand on maîtrise les conséquences du non-respect de cette règle. Valable aussi pour les design pattern)
Bonjour,
Pourquoi ces fonctions devraient être membre ? Il n'y a aucune raison pour ça.
Surtout pour ces fonctions là, elles doivent pouvoir être libre non amies sans vraiment de problème, ou alors c'est qu'il manque des services vraiment basiques à ta classe, AMA.
Salut,
Il faut déjà bien comprendre les principes, et se rappeler que SRP a un champs d'action finalement fort étendu:
- au niveau de la fonction tout d'abord: chaque fonction ne doit faire qu'une chose mais doit veiller à la faire correctement (la fonction permettant de calculer la surface d'un rectangle ne doit faire que ça, de même que celle permettant de tracer le rectangle).
- Au niveau de la classe ensuite, où chaque type concret (rectangle, par exemple) hérite de la responsabilité de l'abstraction dont il hérite (Forme, par exemple)
- Au niveau du module enfin, car le module qui s'occupe de l'affichage du rectangle n'a, a priori, aucune raison de se charger également de la transmission (ou de la récupération) des données sur le net (qu'il soit publique ou privé... Ce serait, typiquement, la responsabilité d'un module séparé.
Pour pouvoir appliquer correctement l'OCP, tu dois également appliquer correctement les autres principes de SOLID, dont, essentiellement, le I (Interface Segregation Principle) et le D (Dependancy Inversion Principle)
Je m'explique : A priori, la manière dont la surface d'un rectangle est calculée est ferme et définitive : quel que soit le contexte dans lequel tu travailles, le résultat sera toujours obtenu par la multiplication de la longueur par la largeur (ou de la largeur par la longueur, ne soyons pas sectaires :D)
Mais cette possibilité (je parle de celle qui consiste à calculer la superficie de "n'importe quoi") représente, quelque part, un concept que l'on pourrait appeler "Surfacable".
Ce concept pourrait parfaitement être utilisé lorsqu'il s'agit, par exemple, de calculer la superficie total d'un corps quelconque (de la jolie vasque romaine contournée au corps d'une pin-up) que l'on aurait subdivisé en différentes formes de base.
De même, la possibilité d'afficher une forme correspond à un concept beaucoup plus général que l'on pourrait appeler "Drawable" car on pourrait parfaitement considérer que "n'importe quel corps" subdivisé en différentes formes géométrique est, lui aussi, affichable si l'on décide d'afficher toutes les formes qui le composent.
Tu remarqueras tout de suite que ton abstraction Forme (car ce qui est vrai pour le rectangle l'est également pour le disque ou pour le triangle) exposent, en définitive, une interface qui correspond à ces deux concepts, parce qu'on peut effectivement vouloir afficher ou calculer la superficie de n'importe quelle forme.
Par contre, on pourrait parfaitement envisager d'avoir deux abstractions totalement distinctes pour les formes :
SurfacableForm lorsque tu as besoin d'être en mesure de calculer la surface (car tu auras alors rarement besoin d'afficher ta forme) et DrawableForm, lorsque tu as besoin de l'afficher et qui n'a rien à voir avec SurfacableForm (parce que tu n'as aucun besoin d'être en mesure de calculer la surface d'une forme pour pouvoir l'afficher).
Le fait de séparer les différents concepts sous la forme d'interfaces simples (quelques fonctions au maximum), dans le respect de l'ISP, te permet donc une flexibilité beaucoup plus grande ;)
Mais revenons à OCP...
Ce principe te dit, simplement, que tu ne devrais idéalement pas te retrouver dans une situation dans laquelle tu serait obligé de modifier le code existant (et validé !!!) afin d'être en mesure d'intégrer des évolutions.
Le meilleur moyen pour y parvenir est, très certainement, de travailler sur des abstractions.
Par exemple, si tu as une classe Render qui est correspond à l'abstraction dont le rôle est d'afficher tes données métiers (quelle que soit la manière dont les données métiers sont représentée), tu pourrais déjà prévoir une fonction propre destinée à afficher les différentes données métiers sous une forme proche de
et, pour chaque donnée métier que tu manipule, tu pourrait parfaitement envisager de dériver une classe du concept Drawable qui fonctionnerait sous une forme proche deCode:
2
3
4
5
6
7
8
9
Un tel code respectera l'OCP (enfin, jusqu'à un certain point) parce que, si tu décides d'utiliser une autre bibliothèque pour l'affichage, il te "suffira" de créer une classe dérivée de Render, adaptée à la bibliothèque que tu utilises, pour rajouter le support de la bibliothèque en question, sans avoir à t'inquiéter de modifier le code que tu as déjà écrit.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Il aura par contre un certain mal à le respecter si tu décide d'ajouter le support du dodécagone :aie: (même si le problème se présentera plutôt si tu as de nombreux type dérivés de Render à maintenir en état de fonctionnement).
Par contre, un code qui ne respecterait pas l'OCP serait sans doute proche de
car tu ne pourras pas rajouter un nouveau type dérivé de UnType sans passer par tous les endroits où une telle logique serait mise en place.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
J'avais, il y a quelques mois, commencé un article qui traitait, entre autres, de SOLID.
Cet article présente le problème d'un jeu d'échec complet comme étude de cas, et propose une solution élégante au problème car il faut aussi penser au fait que l'interface publique de l'abstraction Render doit rester la plus stable possible dans le temps.
Si le nombre de données métier est relativement stable pour un jeu d'échecs, il risque en revanche de l'être beaucoup moins dés qu'il s'agit de tracer des formes, étant donné que tu es toujours susceptible de vouloir rajouter la forme composées de N+1 cotés égaux.
Mais, chemin faisant, je me suis retrouvé avec un truc de près de 200 pages au format A4, ce qui est un peu gros pour un article, et j'ai trouvé un éditeur qui va en faire un livre... Et comme je ne voudrais pas éventer le sujet, je n'en parlerai pas trop ici :P
La sortie de ce bouquin est prévue pour la mi novembre, environ, je ne manquerai pas de la signaler ;)
Tu établis de manière plus formelle ce que je croyais comprendre, et je t'en remercie.
Pour ton bouquin, je serai intéressé.
J'espère que tu fondes toutes les principes sur un seul exemple d'application (jeu d'échec), ainsi que les mauvaises méthodes qui viennent initialement à l'esprit (le coup du switch, en revanche, me semble vraiment trop mauvais pour être crédible :)).
Détrompe-toi, c’est très utilisé le switch. Et quand tu sais que ton ensemble de type est fini et qu’il n’évoluera pas (typiquement, types primitifs d’un interpréteur), c’est une solution tout à fait acceptable.Citation:
Envoyé par oodini
Switcher sur les types, ça amène toujours à faire des choses peu élégantes (traits, etc.), et j'arrive toujours à trouver moyen de l'éviter (via le polymorphisme, par exemple).
C'était avec plaisir :DCitation:
Envoyé par oodini
Je verrai "avec la direction" (de dvp) si on peut faire une annonce ou pas ;)Citation:
Pour ton bouquin, je serai intéressé.
A vrai dire, il est divisé en deux grandes parties : ce que je pense ce certaines pratiques, pourquoi et comment les éviter, avec des exemples simples, et le cas d'étude complet, qui est un jeu d'échec, pour lequel j'essaye chacune des décision prise :DCitation:
J'espère que tu fondes toutes les principes sur un seul exemple d'application (jeu d'échec), ainsi que les mauvaises méthodes qui viennent initialement à l'esprit
Le tout, dans mon "style de plume" habituel ;)Je peux pourtant t'assurer avoir déjà croisé ce genre de code, dans un projet professionnel, en production, avec un nombre de types qui n'étaient ni des primitifs ni fini, mais bien toute une hiérarchie de classes ayant sémantique d'entité.Citation:
(le coup du switch, en revanche, me semble vraiment trop mauvais pour être crédible :)).
Le résultat des courses était que ce code fourmillait littéralement de switch dans tous les sens :P
Acceptable certes, mais très certainement évitable et à éviter autant que possible :DCitation:
Envoyé par white_tentacle
Mais c'est vrai que c'est une technique très (trop) utilisée ;) :D
Et encore, quand tu as la chance que ce soit fait avec des traits...Citation:
Envoyé par oodini
Mais je peux t'assurer que ce n'est pas parce que TU évites cette technique (et je te félicite de le faire :D) ou parce que TU ne as la chance de ne l'avoir encore jamais croisée que l'exemple devient peu crédible, je peux te l'assurer... malheureusement :P
Si si, je te rassure, je le croise... J'ai aussi 95 dynamic_cast (je viens de faire une recherche) sur le code que j'ai récupéré... Et certains sont conjugués avec un switch et un typeid. :cry:Citation:
Envoyé par koala01
Je me disais plutôt que le gars qui va acheter un bouquin sur SOLID a peu de chances de coder ce genre d'abominations.
Ca fait peur, hein :question: :DCitation:
Envoyé par oodini
Sur SOLID, entre autres :DCitation:
Je me disais plutôt que le gars qui va acheter un bouquin sur SOLID a peu de chances de coder ce genre d'abominations.
Ben, disons que j'espère convaincre ceux qui le liront qu'il y a moyen de faire autrement et surtout ... proprement :D
Non c'est que j'ai l'impression que tu veux faire de deux fonctions (polymorphiques ou non - ce que tu proposes das ton exemple est une bonne idée) à responsabilité distincte une seule et même fonction, pour respecter l'OCP, mais je ne vois pas pourquoi, au contraire, si tu fais ça tu ne respecte pas le SRP, et par conséquent l'OCP aura du mal à être respecté puisqu'à la seconde ou tu voudra respecter le SRP, tu devra modifier le code existant, en tout cas d'après ce que j'en avais compris.Citation:
Envoyé par oodini
Mais je penses que white_tentacle avait visé juste sur ce qui te chagrinait, et que ce principe du SRP s'appliquait à l'échelle des méthodes pas des classes (en tout cas pour les question de service à fournir (dessin et calcul), car on peut facilement avoir envie de considérer comme cela a été dit que ta classe à la responsabilité unique de représenter "un rectangle" par exemple, mais ce n'est pas une responsabilité atomique en terme de comportement logiciel, donc bon...).
Tu parles d'appliquer SOLID à une classe (de manière englobante, comme si c'était une boite noire) <= mon ressenti, d'où mon incompréhension sur ta conception de ces principes ;)
Je réfléchis à cette question depuis quelques jours. J'ai un problème un peut comparable sur un projet perso. Du coup j'ai repris la lecture de Modern C++ Design, en espérant trouver LA réponse.
En fait, ce que me gène dans la présente discussion, c'est que tu veux avoir un objet qui peut être manipulé (affiché) par plusieurs bibliothèques. Dit comme ça, la responsabilité de l'affichage ne doit pas incomber à l'objet, mais à la bibliothèque. Non?
En fait, je pense que le problème n'est pas là. Le problème c'est d'avoir une bibliothèque suffisamment générique pour permettre au même objet de s'afficher différemment. Si le problème est bien là, alors les templates et la notion de Policy doit répondre à cette question je pense.
Je ne développe pas plus car je ne suis pas certain d'avoir parfaitement cerné l'interrogation du PO.
Non. Je m'interrogeais sur le fait de les mettre dans la même classe.Citation:
Envoyé par Kaamui
Après tout, une des fonctions pourrait très bien modifier un membre privé utilisé par l'autre fonction.
Ce n'est pas ce que dit la littérature :Citation:
Envoyé par Kaamui
A class should have one, and only one, reason to change.
Exact. Mais je n'ai pas encore d'opinion. Je lis, et j'essaye de comprendre.Citation:
Envoyé par Kaamui
@rod : admettons que tu stockes toutes tes formes dans un vecteur, mais que tu ne sais pas encore à ce moment là quelle bibliothèque d'affichage tu vas utiliser (cf DP Stratégie). Cela appelle immédiatement au polymorphisme dynamique, avec inclusion de la fonction d 'affichage dans la classe.
Je n'ai pas le nom du DP en tête, mais en donnant comme membre à la classe un pointeur vers une interface abstraite, et en affectant ce pointeur à une instance concrète déduite via l'utilisation d'une Stratégie, on devrait satisfaire le SRP et lOCP.
D'accord. Mais qu'une des deux méthodes modifient un membre privé utilisé par l'autre n'est pas du tout en contradiction avec SRP et OCP. Par exemple :Citation:
Envoyé par oodini
Dans mon petit exemple, updatePosition à pour seule responsabilité la mise à jour de la position de mon Rectangle, et draw rend le service unique "dessine moi". SRP est respecté, OCP aussi si on imagine draw et updatePosition virtuelles pour permettre l'évolution potentielle de ces dernières.Code:
2
3
4
5
Je t'avoue que je ne comprends pas trop cette formulation :/Citation:
Moi aussi :)Citation:
Exact. Mais je n'ai pas encore d'opinion. Je lis, et j'essaye de comprendre.
Note l'utilisation de "should" (pas "must").Citation:
Envoyé par oodini
Je n'aime pas cette phrase. Elle ne veut rien dire selon moi. Imagine si tu créée une classe Rectangle dont la seule responsabilité est de s'afficher dans un contexte donné. Cet objet a besoin de données pour s'afficher (couleur et position disons). Si on applique cette phrase, alors il faudrait que couleur et position soient deux classes distinctes de Rectangle, et sans agrégation! ça n'a pas de sens.
Il faut choisir une granularité qui convient au contexte précis du programme. Personne ne va t'insulter si tu as une structure POD de base qui implémente une fonction to_string(). ça ne rentre pas dans les grands principes, mais ça ne change rien à ton programme et il serait ridicule de créer 3 classes supplémentaires bourrées de templates pour gérer la transformation de ton objet en string alors que c'est juste pour le mettre dans ton fichier de log.
Nan mais là il y a un truc qui ne colle pas. Ou alors je passe à côté.Citation:
Envoyé par oodini
Tout d'abord, un objet a besoin du contexte pour s'afficher (par exemple une RenderWindow dans la SFML, ou un Widget, pour prendre un exemple plus général). En gros, la fonction Draw ressemblera à ceci: Draw( Widget & context );
Donc cette fonction dépend totalement de la bibliothèque. Je ne vois donc pas comment un objet pourrait ignorer, à la compilation, dans quel contexte il va s'afficher.
Une abstract factory?Citation:
Envoyé par oodini
Attention, tu utilises le mot "interface" au sens java. En c++, l'interface d'une classe est l'ensemble de ses fonctions membres, des ses variables membres et de ses amis. La notion d'interface au sens java n'a pas vraiment de sens en c++. On peut parler de classe abstraite, mais ce n'est quand même pas la même chose.
Tu n'ignoreras sans doute pas dans quel contexte d'affichage tu vas te trouver au moment où tu vas compiler.Citation:
Envoyé par r0d
Par contre, la question qu'il est surement intéressant de te poser est sans doute "tiens que se passerait-il si ... je venais à vouloir passer de Qt à SFML ou à une autre bibliothèque :question:"
Les données métier que tu as à afficher sont strictement identiques, mais le moyen de les afficher dépend de la bibliothèque utilisée et même sans doute de la vue dans laquelle tu te trouves.
Si je prends l'exemple du jeu d'échecs que j'ai pris comme étude de cas dans le bouquin :
j'ai clairement indiqué dans mes spécifications que je voulais que l'étude de cas reste simple, et qu'il était hors de question de commencer à expliquer l'utilisation de l'une ou l'autre bibliothèque IHM.
Mais je sais que, sorti de cette étude de cas, la première chose que l'on fera sans doute, c'est d'adapter les spécifications et de permettre un affichage plus user friendly, en décidant d'utiliser l'une de ces bibliothèques.
Selon l'OCP, je ne devrais pas avoir à modifier le code existant de mon jeu d'échecs pour y arriver, et l'on peut même estimer comme probable qu'il soit intéressant de permettre au joueur de choisir entre l'affichage "console", l'affichage "2D" et pourquoi pas un affichage 3D.
Ce sont autant d'affichages qui peuvent utiliser différentes bibliothèques pour y arriver.
La solution nous est donnée par le D de solid : la gestion (au niveau du jeu d'échecs) de l'affichage ne doit pas dépendre de détails propres aux différentes bibliothèque, mais tout doit passer par... une abstraction supplémentaire (une façade :question:)
De cette manière, si je veux changer de bibliothèque d'affichage (et donc de système d'entrées, car les deux sont intimement liés), je n'ai "qu'à" ... fournir une implémentation spécifique de cette façade qui se base sur la bibliothèque utilisée pour ce dont j'ai besoin.
Cela peut sembler quelque peu "overkill", mais, si tu veux pouvoir faire facilement évoluer ton application dans "n'importe quelle direction" (y compris celles que tu pourrait considérer comme étant les plus improbables), il est préférable de prévoir le "point de variation" qui te permettra de le faire le plus tôt possible, afin d'éviter d'avoir à tout casser lorsque tu en viendras à envisager ce genre d'évolution ;)
J'entends bien (enfin je crois), mais ça ne fait que déplacer le problème.
Que le code spécifique à ta lib d'affichage soit dans un intermédiaire (façade), dans le moteur de rendu lui-même, ou dans l'objet affiché, ça revient au même (dans le cadre de SOLID). Ce qui change, c'est le contexte réel de l'implémentation: dans quel sens le programme est supposé évoluer, quelle est l'architecture globale (MVC, 3 tiers, client/serveur, ...), granularité des modules compilés (une lib pour chaque classe jusqu'à un seul gros exécutable), etc.
Cela ne fait peut etre que déplacer le problème, mais cela le déplace à un endroit du code où il ne risque plus d'interférer avec "autre chose", et donc, où il ne risque plus de "tout casser" en cas de changement.Citation:
Envoyé par r0d
Je m'explique :
1- Tu peux envisager énormément de responsabilités pour tes données métier (dans la mesure où chaque donnée métier n'a qu'une responsabilité bien déterminée du moins), sauf celle qui consiste à s'afficher.
La responsabilité de l'affichage des données métier doit échoir à "quelque chose d'autre" (une classe dérivée de DrawableItem :question:)
En agissant de la sorte, tu permets déjà à tes données métier d'évoluer indépendamment du contexte d'affichage, tout en permettant à ce dernier d'évoluer de manière relativement indépendante de tes données métier.
2- On l'oublie souvent, mais un contexte d'affichage va généralement de paire avec un contexte d'entrées de la part de l'utilisateur : Si tu utilises le mode console, les entrées utilisateurs se feront... via le clavier (ou via des fichiers), alors que si tu utilises Qt ou SFML, les entrées de l'utilisateur se feront en fonction des événement ou des signaux émis par les éléments visuels.
De là à estimer qu'il n'y aura de toutes manière que les entrées susceptibles d'être comprises par un contexte d'entrées spécifique qui devront être gérées par le système d'affichage, il n'y a qu'un pas, que l'on peut allègrement franchir ;)
En effet, si j'introduis une commande proche de "blancs" en mode console, et que le système d'entrées de l'utilisateur interprète cette ligne de caractères comme étant la commande qui demande l'affichage de l'ensemble des pièces de l'équipe des blancs qui se trouve sur l'échiquier, la réaction "visuelle" du système d'affichage sera... d'afficher la liste des pièces blanches se trouvant encore sur l'échiquier.
D'un autre coté, si le système d'entrées ne comprends pas cette chaine de caractères, il devrait sans doute passer par défaut dans une situation dans laquelle la réaction visuelle sera... de m'afficher un message d'erreur m'indiquant qu'il n'a pas compris ce que je lui voulais.
Sous Qt ou avec SFML, cette même commande prendra sans doute la forme d'un clique sur un bouton particulier, ou que sais-je :question:
Mais la réaction visuelle sera forcément de même nature : soit la commande est comprise et les pièces blanches sont mise en évidence sur l'échiquier, soit la commande n'est pas comprise et j'obtiens un message (quelle qu'en soit la forme !!) qui me l'indique.
De la même manière, si j'introduis un déplacement sous la forme de A1C1 pour déplacer une tour, soit le système d'entrées est capable de reconnaitre cette chaine de caractère, et le déplacement doit s'effectuer (avec l'affichage correspondant), s'il est légal, soit (si le déplacement est illégal) le système d'affichage doit me faire savoir que le déplacement est illégal, soit, enfin, la commande n'est pas reconnue et on "retombe" dans la situation précédente.
Ce qu'il importe de se rendre compte, c'est que ce n'est pas la donnée métier qui correspond à la pièce déplacée ou au déplacement qui dépend du contexte, mais bel et bien... la commande qui va manipuler les données métier pour s'exécuter correctement.
Or, la commande, elle va être émise ... par un système d'entrées spécifique au contexte d'entrées / sorties utilisé à un instant T.
Et qui mieux que le contexte d'entrées pourrait indiquer le contexte de l'affichage, sachant que, de toutes manières, il n'y aura que les commandes reconnues qui devront avoir un équivalent à l'affichage :question:
A partir de là, tu t'organises comme tu veux pour que le système d'entrées soit en mesure de fournir, à une commande qui lui est spécifique, le contexte d'affichage correspondant vers lequel elle devra se tourner pour provoquer son propre affichage, mais, ce qui importe, c'est que chaque commande se divise finalement en deux grandes responsabilités :
une fonction "execute()" qui fait les vérifications éventuelles et qui modifie les données métier en conséquence et une fonction "printeMe()" (par exemple, voir d'autres fonctions supplémentaires) dont le comportement est parfaitement susceptible de s'adapter à un contexte d'affichage spécifique.
On pourrait estimer que l'on ne fait que "déplacer le problème", mais ce qui importe surtout, c'est que, au final tu te retrouves avec différentes abstractions (pièces, couleur, coordonnée, case, échiquier, render, input, command, ...) pour lesquelles il est possible, en cas de besoin d'adapter certains comportements en fonction des situations spécifiques :
-les premières dans cette liste (de pièces à échiquier inclus) n'ayant strictement aucun besoin de connaitre le contexte d'entrées / sorties,
- les dernières (de render à command inclus) ayant toutes comme point de variation possible le contexte d'entrées / sorties utilisé et donc susceptibles d'adapter les comportements (qui nécessitent de l'être) en fonction de ce point de variation et qu'il t'appartient de spécialiser en fonction du contexte d'entrées / sortie que tu envisages d'utiliser.
A partir de là, les différentes options que tu pourras envisager en terme d'architecture ou de modularisation n'auront plus qu'un impact extrêmement limité sur tout le reste ;)
De toutes façons, faire de la conception ne revient finalement qu'à déplacer des problèmes. Le but étant de les mettre au bon endroit et dans le bon ordre.
Ton exemple de commande est intéressant, car en plus, on pourrait imaginer pouvoir contrôler le programme par deux systèmes de commandes différents (console+GUI) simultanément. Par exemple, deux joueurs joue une partie; un joueur joue via une interface graphique, et l'autre en ligne de commande.
Prenons le cas où on a un MVC. Les contrôleurs (ligne de commande/GUI) sont dans le contrôleur. Les données (l'état de l'échiquier: position des pièces etc.) sont dans le modèle, et la vue se contente d'afficher le modèle. On aurait alors un contrôleur qui aurait deux input (console et GUI), qui utiliserait le modèle pour vérifier la faisabilité des commandes, et qui enverrai des notifications au modèle et éventuellement à la vue. Les deux inputs, comment seraient-ils implémentés à ton avis?
Non je crois qu'il s'agit de Dependency Injection. C'est un design pattern qui se rapproche de ce qu'expliquait Koala01, à savoir qu'on devrait ne pas avoir à s'occuper de "qui" gère le contexte, si on veut respecter SOLID(Dependency inversion Principle). Et c'est vrai qu'en y réfléchissant c'est génial et j'ai un cas concret pour le démontrer :Citation:
Envoyé par r0d
je suis en train de développer un jeu de carte multijoueur avec SFML. J'ai choisi également une lib (SFGUI basée sur SFML) pour l'interface graphique. Et depuis quelques temps je regrette sincèrement de ne pas avoir choisi Qt pour l'interface graphique parce que l'autre est moins complète et plus amateur. Malheureusement je n'ai pas ajouter d'abstraction entre la logique métier de mon appli et les classes responsables de la gestion de mon contexte(affichage+events), du coup je devrai passer dans mon code au marteau-piqueur si je voulais effectivement passer à Qt, ou Qt+SFML-SFGUI, ou autre.
C'est là qu'on s'aperçoit que des gars sont passé par là avant nous des milliers de fois et que SOLID est composé de principes très solides (pour rester dans l'humour de l'OP :)), qui respirent le vécu.
Tout à fait :DCitation:
Envoyé par r0d
Je t'avouerai n'avoir pas vraiment réfléchi à la question, mais, si tu as correctement défini tes responsabilités, cela ne poserait finalement pas énormément de problème :DCitation:
Ton exemple de commande est intéressant, car en plus, on pourrait imaginer pouvoir contrôler le programme par deux systèmes de commandes différents (console+GUI) simultanément. Par exemple, deux joueurs joue une partie; un joueur joue via une interface graphique, et l'autre en ligne de commande.
Par "simple" agrégation des deux :DCitation:
Prenons le cas où on a un MVC. Les contrôleurs (ligne de commande/GUI) sont dans le contrôleur. Les données (l'état de l'échiquier: position des pièces etc.) sont dans le modèle, et la vue se contente d'afficher le modèle. On aurait alors un contrôleur qui aurait deux input (console et GUI), qui utiliserait le modèle pour vérifier la faisabilité des commandes, et qui enverrai des notifications au modèle et éventuellement à la vue. Les deux inputs, comment seraient-ils implémentés à ton avis?
De la manière dont j'ai implémenté les choses, il y a en réalité quatre abstraction de base:
J'ai basé un certain nombre de classes template sur ces abstraction de base :
- Input (le système d'entrée)
- Render (le système d'affichage)
- Command (la commande à effectuer)
- CommandSender (une abstraction qui permet au système d'entrées d'émettre la commande qu'il a reconnue).
que j'adapte au contexte pour les entréesCode:
2
que j'adapte au contexte pour l'affichageCode:
2
que j'adapte en fonction de la commande à exécuter (comprends : pour laquelle je prévois d'adapter le comportement de execute() )Code:
2
dont chaque spécialisation pour CommTag hérite de ExecutableCommand, et pour laquelle ITag correspond au contexte d'entrée / sortieCode:
2
et enfin
dont le but est de renvoyer la commande équivalent à CommandTag et spécifique au contexte d'entrées / sortie équivalent à Itag.Code:
2
Je peux donc avoir une spécialisation de la commande, par exemple pour la commande d'aide, avec un tag proche de
qui ressemble àCode:struct HelpTag{};
Pour ce qui est de la commande concrète, je peux fournir une spécialisation partielle, le tag pour la commande étant connu, celui pour le contexte d'affichage ne l'étant pas, sous une forme proche deCode:
2
3
4
5
6
7
8
9
10
11
et une spécialisation partielle pour la classe ConcreteCommandSender proche deCode:
2
3
4
5
6
7
8
9
10
(on considère que la fonction render() de Game renvoie un Render & ;))Code:
2
3
4
5
6
7
8
9
10
11
12
Tant que l'on travaille dans un contexte exclusivement console, on crée un tag spécifique pour ce contexte, mettons
et la seule chose que l'on ait à préciser (pour chacune des commandes reconnues par le système, s'entend) est le comportement équivalent à printMe() pour la spécialisation partielle de la commande.Code:struct ConsoleTag{};
Cela pourrait donc prendre la forme de
Le jour où je décide d'utiliser une bibliothèque IHM pour rendre les choses plus user friendly, je crées un tag de contexte spécifique, par exemple:Code:
2
3
4
et je fournis une implémentation spécifique pour le comportement printMe(), sous une forme proche deCode:struct SfmlTag{};
Et le jour où j'ai envie d'avoir les deux regroupés, qu'est ce qui m'empêche de fournir une spécialisation totale pour ConcreteCommand et pour ConcreteCommandSender :question:Code:
2
3
4
Qu'est ce qui m'empêcherait d'avoir un tag proche de
de spécialiser render en fonction de ce tag pour qu'il envoie les informations à afficher aussi bien vers la console que vers SFML, de spécialiser ConcreteInput pour qu'il reconnaisse les commandes aussi bien en mode console qu'avec SFML, et ainsi de suite :question:Code:struct ConsoleAndSfml{};
Je pourrait tout aussi bien spécialiser le comportement de printMe sous la forme de
et fournir une déclaration et une implémentation de ces fonctions en conséquence ;)Code:
2
3
4
5
Avec un peu de chance, la spécialisation de ConcreteCommand pourrait même plutôt ressembler à
(code non testé ;)) et le tour serait joué ;)Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
Je suis content d'avoir lancé ce fil de discussion, car SOLID revient régulièrement sur le tapis (notamment par notre marsupial préféré), sans qu'on ait vraiment eu un sujet qui y était dédié (du moins, dans mes souvenirs).
Le fait est que SOLID est un groupe de principes qu'il est bon d'envisager dans son ensemble (chacun d'eux étant très certainement plus facile à respecter si l'on est déjà dans une situation dans laquelle on respecte les autres :marteau:), mais que l'on peut souvent se limiter au rappel d'un ou deux des principes dans la plupart des discussions.Citation:
Envoyé par oodini
Dans bien des cas de discussions, le simple fait d'inciter l'OP à respecter le SRP et le LSP vont l'orienter vers une solution où le respect du ISP (et du DIP) sera renforcé, et où l'on fera un grand pas dans le respect de l'OCP.
Du coup, il devient assez difficile d'aborder SOLID dans son ensemble sans partir dans une discussion purement théorique dans laquelle chacun verra forcément midi à sa porte, et dans laquelle chaque exemple peut apporter un nombre incalculable de contre exemples :P
La meilleure preuve en est que tu es arrivé avec un exemple tout simple et que la première chose que j'ai faite est d'introduire deux concepts basés sur cet exemple, afin de te démontrer que c'étaient deux choses tout à fait orthogonales qui pouvaient parfaitement être prises en compte séparément ;)