Tu devrais t'adresser plus particulièrement aux développeurs java qui ont juste inventé le concept. L'infection s'est propagée chez les autres, C# en tête.
Désolé les gars mais quand je vois une classe qui :
utilise des setter/getter à tire-larigot quand bien souvent un attribut suffit.
hérite de classes multiples
qui implémentent elles mêmes des interfaces
Je me dit que le mec n'est pas assez efficace ou vaut bien faire trop tôt, de la même manière qu'il ne faut pas optimiser son code trop tôt.
Je préfère le concept de l'implémentation naïve, cité dans le journal :
je crée ma classe jusqu'à temps qu'elle fasse le job de manière propre mais sans prise de tête.
je recode de manière plus chiadée (héritage, interface...) uniquement si : moi ou un de mes collègues risque de l'utiliser plus tard.
À celui qui :
crée une classe.
crée l'interface sans savoir si ça va servir.
crée une classe de base qui implémente son interface parce que c'est dans la logique.
modifie sa classe en (1) pour qu'elle hérite de (3).
Tout ça pour une fonctionnalité sur laquelle il est le seul à travailler et dont il n'a aucune visibilité (one-shoot ?). Si c'est pas de l'overengineering...
# java ?
Posté par stopspam . En réponse au journal Lutter contre l'overengineering. Évalué à 0. Dernière modification le 23 mai 2016 à 15:14.
Tu devrais t'adresser plus particulièrement aux développeurs java qui ont juste inventé le concept. L'infection s'est propagée chez les autres, C# en tête.
Désolé les gars mais quand je vois une classe qui :
Je me dit que le mec n'est pas assez efficace ou vaut bien faire trop tôt, de la même manière qu'il ne faut pas optimiser son code trop tôt.
Je préfère le concept de l'implémentation naïve, cité dans le journal :
À celui qui :
Tout ça pour une fonctionnalité sur laquelle il est le seul à travailler et dont il n'a aucune visibilité (one-shoot ?). Si c'est pas de l'overengineering...