Si je comprends bien, cela signifie de ne pas utiliser un modèle de conception jusqu'à ce qu'il soit logique de le faire, n'est-ce pas?
Oui.
Ne commencez pas par dire que vous allez utiliser le modèle de stratégie, attendez que vous écriviez du code, et si l'utilisation du modèle de stratégie est logique pour votre conception, utilisez-le.
Oui. Techniquement, vous pouvez vous rendre compte que le modèle de stratégie est approprié avant même d'écrire du code, mais cela devrait être parce que vous pensiez au problème réel et que vous conceviez une solution à ce problème, ce que je suppose être ce que vous vouliez dire.
Dois-je traiter le modèle MCV / MVP de la même manière lorsque je crée des applications GUI? D'après les liens respectifs, il indique que c'est un modèle architectural.
Oui, MVC / MVP / etc sont des modèles architecturaux. Dans un sens, cela ne fait aucune différence car vous ne devriez toujours utiliser MVC / MVP / etc que quand cela a du sens; lorsqu'il s'agit d'un ajustement raisonnable au problème réel que vous essayez de résoudre. Là où cela fait une différence, c'est que, parce qu'il s'applique à un niveau beaucoup plus élevé que, disons, le modèle de stratégie, vous comprendrez généralement si cela a du sens et déciderez si vous allez l'utiliser dans le cadre de votre travail de conception, avant d'écrire beaucoup de code.
Gardez également à l'esprit que "MVC / MVP" n'est pas un modèle unique, mais une très grande famille de modèles connexes, et il n'y a pas de consensus sur ce qui compte exactement comme "MVC" ou "MVP" ou "MVVM" ou le reste de la soupe alphabet associée.
Supposons que si je crée une application graphique et que je n'utilise pas le modèle MCV / MVP, mais mon code est propre, lisible et maintenable, est-ce toujours une odeur de code / mauvaise conception que je n'ai pas utilisé le modèle MCV / MVP ?
Pas du tout, car MVC / MVP / etc ne conviennent pas à toutes les applications GUI. Par exemple, certaines interfaces graphiques peuvent être si simples que ce serait une surpuissance totale, ou certaines interfaces graphiques peuvent ne pas avoir d'état permanent à mettre dans un "modèle", etc. Il y a de bonnes raisons pour lesquelles cette famille de modèles est si populaire, mais elles ne sont pas les seuls moyens d'écrire un bon logiciel GUI.
En outre, une "odeur de code" signifie généralement quelque chose à propos d'un extrait de code spécifique qui pourrait être le symptôme d'un problème plus important. Si tout votre code est "propre, lisible et maintenable", sans aucune exception, alors presque par définition, vous n'avez aucune odeur de code (sauf peut-être quelques odeurs de code "faux positif" qui n'indiquent aucun problème réel) ).
Donc, pour répondre au titre de votre question: "Comment traiter le modèle MVC / MVP?", Je dirais: allez lire pourquoi ces modèles sont si populaires, c'est-à-dire quels problèmes ils essaient de résoudre, de sorte qu'à l'avenir vous pouvez dire si votre dernier problème peut être résolu par l'un de ces modèles.