Flup se dirige dans la bonne direction. Le "principe de responsabilité unique" s'appliquait à l'origine aux procédures. Par exemple, Dennis Ritchie dirait qu'une fonction devrait faire une chose et bien le faire. Ensuite, en C ++, Bjarne Stroustrup dirait qu'une classe devrait faire une chose et bien le faire.
Notez que, sauf comme règles de base, ces deux-là n'ont formellement rien ou presque rien à voir l'un avec l'autre. Ils ne répondent qu'à ce qui est pratique à exprimer dans le langage de programmation. Eh bien, c'est quelque chose. Mais c'est une histoire très différente de celle vers laquelle se dirige le flup.
Les implémentations modernes (c'est-à-dire agiles et DDD) se concentrent davantage sur ce qui est important pour l'entreprise que sur ce que le langage de programmation peut exprimer. La partie surprenante est que les langages de programmation n'ont pas encore rattrapé leur retard. Les anciens langages de type FORTRAN capturent des responsabilités qui correspondent aux principaux modèles conceptuels de l'époque: les processus appliqués à chaque carte lors de son passage dans le lecteur de carte, ou (comme en C) le traitement qui accompagnait chaque interruption. Viennent ensuite les langages ADT, qui ont mûri au point de capturer ce que les DDD réinventeront plus tard comme étant important (bien que Jim Neighbours ait compris la majeure partie de cela, publié et utilisé en 1968): ce que nous appelons aujourd'hui des classes . (Ce ne sont PAS des modules.)
Cette étape était moins une évolution qu'une balançoire pendulaire. Alors que le pendule basculait vers les données, nous avons perdu la modélisation de cas d'utilisation inhérente à FORTRAN. C'est très bien lorsque votre objectif principal concerne les données ou les formes sur un écran. C'est un excellent modèle pour des programmes comme PowerPoint, ou du moins pour ses opérations simples.
Ce qui s'est perdu, ce sont les responsabilités du système . Nous ne vendons pas les éléments de DDD. Et nous ne comprenons pas bien les méthodes. Nous vendons des responsabilités système. À un certain niveau, vous devez concevoir votre système autour du principe de responsabilité unique.
Donc, si vous regardez des gens comme Rebecca Wirfs-Brock, ou moi, qui parlions des méthodes de classe, nous parlons maintenant en termes de cas d'utilisation. C'est ce que nous vendons. Ce sont les opérations du système. Un cas d'utilisation doit avoir une seule responsabilité. Un cas d'utilisation est rarement une unité architecturale. Mais tout le monde essayait de faire comme si. Témoin le peuple SOA, par exemple.
C'est pourquoi je suis enthousiasmé par l'architecture DCI de Trygve Reenskaug - qui est décrite dans le livre sur l'architecture Lean ci-dessus. Il donne enfin une certaine stature à ce qui était auparavant une obéissance arbitraire et mystique à la «responsabilité unique» - comme on le trouve dans la plupart des arguments ci-dessus. Cette stature est liée aux modèles mentaux humains: les utilisateurs finaux en premier ET les programmeurs en second. Cela concerne des préoccupations commerciales. Et, presque par hasard, il résume le changement alors que le flup nous interpelle.
Le principe de responsabilité unique tel que nous le connaissons est soit un dinosaure resté de ses jours d'origine, soit un cheval de bataille que nous utilisons comme substitut à la compréhension. Vous devez laisser quelques-uns de ces chevaux de passe-temps derrière pour faire un excellent logiciel. Et cela nécessite de sortir des sentiers battus. Garder les choses simples et faciles à comprendre ne fonctionne que lorsque le problème est simple et facile à comprendre. Je ne suis pas très intéressé par ces solutions: elles ne sont pas typiques et ce n'est pas là que réside le défi.
