Je pense que cela pourrait être une méta-réponse controversée, et je suis un peu en retard à la fête, mais je pense qu'il est très important de le mentionner ici, car je pense que je sais d'où vous venez.
Le problème avec la façon dont les modèles de conception sont utilisés, c'est que lorsqu'ils sont enseignés, ils présentent un cas comme celui-ci:
Vous avez ce scénario spécifique. Organisez votre code de cette façon. Voici un exemple intelligent, mais quelque peu artificiel.
Le problème est que lorsque vous commencez à faire de la vraie ingénierie, les choses ne sont pas aussi simples. Le modèle de conception que vous lisez ne correspond pas tout à fait au problème que vous essayez de résoudre. Sans oublier que les bibliothèques que vous utilisez violent totalement tout ce qui est indiqué dans le texte expliquant ces modèles, chacun à sa manière. Et par conséquent, le code que vous écrivez "se sent mal" et vous posez des questions comme celle-ci.
En plus de cela, je voudrais citer Andrei Alexandrescu, en parlant de génie logiciel, qui déclare:
Le génie logiciel, peut-être plus que toute autre discipline du génie, présente une riche multiplicité: vous pouvez faire la même chose de tant de façons correctes, et il y a des nuances infinies entre le bien et le mal.
C'est peut-être un peu exagéré, mais je pense que cela explique parfaitement une raison supplémentaire pour laquelle vous pourriez vous sentir moins confiant dans votre code.
C'est dans des moments comme celui-ci que la voix prophétique de Mike Acton, responsable du moteur de jeu chez Insomniac, me crie dans la tête:
CONNAISSEZ VOS DONNÉES
Il parle des entrées de votre programme et des sorties souhaitées. Et puis il y a ce joyau de Fred Brooks du mois de l'homme mythique:
Montrez-moi vos organigrammes et cachez vos tables, et je continuerai à être mystifié. Montrez-moi vos tableaux et je n'aurai généralement pas besoin de vos organigrammes; ils seront évidents.
Donc, si j'étais vous, je raisonnerais sur mon problème en fonction de mon cas d'entrée typique, et s'il atteint la sortie correcte souhaitée. Et posez des questions comme celle-ci:
- Les données de sortie de mon programme sont-elles correctes?
- Est-il produit efficacement / rapidement pour mon cas d'entrée le plus courant?
- Mon code est-il assez facile à raisonner localement, pour moi et mes coéquipiers? Sinon, puis-je le simplifier?
Lorsque vous faites cela, la question de "combien de couches d'abstraction ou de motifs de conception sont nécessaires" devient beaucoup plus facile à répondre. De combien de couches d'abstraction avez-vous besoin? Autant que nécessaire pour atteindre ces objectifs, et pas plus. "Qu'en est-il des modèles de conception? Je n'en ai pas utilisé!" Eh bien, si les objectifs ci-dessus ont été atteints sans application directe d'un modèle, c'est bien. Faites-le fonctionner et passez au problème suivant. Commencez par vos données, pas par le code.