Architecture logicielle 100% SOLID ?

a marqué ce sujet comme résolu.

Salut à tous,

En fait je me posais une petite question toute bête (quoique).

Est-il possible de respecter à 100% des grands principes tels que les principes SOLID au sein d’un logiciel (je pense surtout au SRP) ? En fait, j’ai l’impression qu’on arrive toujours à un point où l’on a besoin d'a minima un composant "central", qui endosse plusieurs responsabilités.

Si oui, est-ce "risqué" de déroger à l’un de ces principes d’un point de vue de la maintenabilité ? Y a-t-il des alternatives ?

+0 -0

En soi, ça dépend du langage et des règles de styles qui y sont devenus la norme. Par exemple, en java, il est devenu commun d’avoir en tête des classes qui font des choses intéressante un private static final Logger LOGGER = LogManager.getLogger(MaClass.class);. Cette simple ligne viole (d’une manière très légère) le SRP car du coup la classe devient l’instanciatrice (et du coup la décideuse de comment c’est fait) du logger alors que c’est pas son job logiquement.

En soi, tu peux tout à fait, dans la logique du langage respecter le SRP, mais rapidement tu vas t’autoriser des écarts qui sont légitimes. Notamment, le but est de ne pas suringénieurer ton code.

Après SRP ne signifie pas "il n’y a pas de composant central" (désolé pour la double négation). Si tu as un composant central qui se contente de d’ordonnancer le cycle de vie de l’application mais délègue les tâches logicielles à d’autres composant, il respecte le SRP.

+1 -0

Il faut probablement exclure les idioms et patterns, qui peuvent ne pas suivre a 100% les principes généraux. Parce qu’ils sont bien connus, donc ne posent pas les problèmes habituels qui se posent quand on ne respecte pas les principes.

Et comme l’a dit artagis, il faut éviter de "suringénieurer". On peut toujours regarder les détails d’une solution, trouver des points qu’on peut améliorer et complexifier ainsi la solution. Mais, au final, la solution est tellement trop complexe qu’elle pose plus de problème qu’elle en résout.

Il faut, a mon avis, surtout comprendre le pourquoi de ces principes, ce qu’ils permettent d’éviter comme problème, et comparer le coût (temps de dev, temps de maintenance, etc) entre les différentes solutions. Si on sait qu’on n’aura pas à faire évoluer un code, ou qu’on sait que l’évolution d’un code ne sera pas un problème, on peut accepter une solution qui ne respecte pas a 100% les principes. L’important est de maîtriser ces coûts.

+1 -0

Salut,

Merci de vos réponses.

Il me reste une question ; à force de regarder le code pondu au boulot ou par des amis pour le loisir, je vois TOUT LE TEMPS des classes (alors faut savoir que c’est principalement du C#) du genre NetworkManager, InputManager, bref plein de XXXManagers : est-ce sain sur le plan conceptuel (logique, maintenabilité, toussa toussa) ou c’est moi qui ai un problème ? x)

Y a-t-il des cas où il est recommandé de passer par ce genre d’entités ? D’après le code d'@artragis oui, mais est-ce courant ? (Après c’est peut-être différent dans des langages où l’usage de l’OO est imposé, comme C# ou Java)

+0 -0

La question est : est-ce un choix technique assumé ou juste la répétition d’habitudes ?

Le meilleur moyen de faire perdurer une mauvaise pratique, c’est de ne jamais la remettre en question.

Quand le problème devient critique, on arrive facilement a voir qu’il y a des changements à faire sur la conception. (Dans un ancien boulot, on mettait 1 ou 2 journées pour implémenter une fonctionnalité et 1 ou 2 semaines pour corriger les bugs qui se produisaient en cascade).

Mais les problèmes de conception peuvent moins visibles, produire des retards de livraison, des produits mal tests et buggés, ou incomplet (doc), etc.

+1 -0

La question est : est-ce un choix technique assumé ou juste la répétition d’habitudes ?

De manière quasi certaine, des habitudes simplement appliquées. "On a toujours fait comme ça, alors on continue", j’imagine.

(Dans un ancien boulot, on mettait 1 ou 2 journées pour implémenter une fonctionnalité et 1 ou 2 semaines pour corriger les bugs qui se produisaient en cascade

Produit legacy ? :D

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte