Ah, enfin des parôles censés sur le sujet autres que "c'est un anti-pattern donc c'est mal".
Mes premières années de développements grossomodo ont été des applications de gestion de données pure et dure.
Et je me suis fait des noeuds au cerveau en essayant faire autre chose que du modèle anémique... sans succès, au sens ou ça donnait quelque chose de plus complexe, moins testable, et sans gain réel pour moi.
Ma petit conclusion personnelle est que cet anti-pattern est en fait parfaitement adapté à ce qui relève de la gestion de données pure et dure, en revanche dès qu'on sort de la gestion de données, c'est une autre histoire.
Je vais apporter mon grain de sel sur ton dernier point sur lequle je suis d'accord. Le problème c'est que quand je veux proposer des approches plus riches pour traiter des problèmes plus complexes et bien je rencontre une forte résistance en mode "les autres ils comprendront pas" Pour ceux qui imagine le niveau de complexité dont je parle et bien imaginer simplement que les commentaires ne suffisent pas pour comprendre l'image globale et qu'il faut quelque diagrammes UML et réunion pour parler de conception uniquement, ben c'est de trop. Et à cela, on préfère souvent niveler par le bas, ce qui est extrêmement frustrant.
Pour ceux qui imaginent que ce que je propose c'est de refaire un méga framework usine a gaz, c'est évidemment faux je fais au mieux pour proposer des abstractions nécessaires répondant à de besoins actuels voir à couvrir dans un futur proche (oui YAGNI mais je n'aime pas non plus l'idée d'avancer totalement à l'aveugle, pour moi il faut quand même un minimum d'anticipation quand tu sais ce qu'il va arriver). Mais c'est l'excuse qu'on me brandis dès que j'essaye de faire un peu trop réfléchir les gens.
Partager