Et si les « if » dans nos programmes informatiques étaient une mauvaise pratique ?
Je donne le lien sans trop de commentaires car je ne sais qu’en penser, mais ça m’interpelle quand même. Effectivement, les codes dont je suis le moins fier comportent beaucoup de conditions, et inversement. Je ne crois pas que le if soit mauvais en soi, mais ça vaut peut être le coup d’y regarder de plus près comme un indicateur de mauvaise architecture.
par
Étiquettes :
On voit qu’il est complètement à côté de la plaque ici :
« One of things which can suggest that things got to fishy in your implementation, is how hard is to test your objects. Classes with a lot of conditions require a lot of test cases and a lot of setup code. If your behaviour were properly isolated and subclassed, then your test would be very simple and with minimum setup code. »
Ce qui rend les tests difficiles, c’est le nombre de cas à tester, que le parcours de l’espace des cas soit implémenté avec des « switch », des « if », des classes ou de la méta-programmation. S’il trouve que son code sans « if » requiert moins de cas de tests, c’est soit que sa couverture de test a baissée, soit qu’il n’a pas implémenté la même chose.
Justement, ce qui rend les tests difficile, c’est le nombre de cas a tester. Pas le nombre de classes et de méthodes à tester.
Comme ce sont des tests unitaires, chaque test devient plus simple, parce que les méthodes elle-même sont plus simples : chacune représente moins de cas à tester.
Je pense même qu’au final, il augmente le nombre de tests effectués – et donc quelque part, c’est encore mieux.
@Sébastien
« Justement, ce qui rend les tests difficile, c’est le nombre de cas a tester. »
Oui c’est ce que j’écris explicitement.
« Comme ce sont des tests unitaires, chaque test devient plus simple, parce que les méthodes elle-même sont plus simples. »
Les méthodes ne sont pas plus simples : les corps des if et else sont extraits dans des méthodes, le contenu de la méthode reste grosso-modo le même, la seule chose qui change est la signature par l’introduction soit d’un contexte, soit d’une liste de paramètres fourre-tout.
@Damien c’est exactement ça, sa classe implémente moins de choses, par contre il aura plus de classes, chacune répondant à un des cas de figure que du switch ou des if. Au final il aura autant de tests et testera les même choses, sauf qu’au lieu de tester 50 cas pour une méthode ou une classe, il en testera 2-3 mais pour plus de méthodes/de classes. C’est ce qu’on appelle le Single Responsibility Principle.
Dans les langages orientés objets, on a souvent des mécanismes nous permettant justement d’éviter ces conditions, on pourrait par exemple citer le polymorphisme. On obtient ainsi du code plus court, plus simple.
Ce qu’il faut comprendre c’est qu’en OO on a des outils parfois plus adaptés que des conditions. Quand c’est le cas, utiliser un if plutôt que ces outils est mauvais.
« Au final il aura autant de tests et testera les même choses, sauf qu’au lieu de tester 50 cas pour une méthode ou une classe, il en testera 2-3 mais pour plus de méthodes/de classes. »
Le si/sinon n’implique pas d’avoir le traitement embarqué dans les blocs conditionnels, tu n’as pas d’augmentation du nombre de méthodes en « abandonnant » les si/sinon, mais du nombre de classes.
Je ne suis pas sûr que le nombre de tests soit le plus difficile, mais plutôt le type de tests.
Pour le if-less programming qui peut peut-être permettre à un programmeur experimenté de réfléchir deux fois à ce qu’il fait en parfois ajoutant une classe supplémentaire à la place d’un « if », cela ne semble pas être très utile à un programmeur débutant.
J’aimerais voir aussi le coût en performance d’éxécution et en impact sur la mémoire. Bien sûr cela doit dépendre des contextes.
Donc comme d’habitude à balancer entre pratique, théorie et contexte.
« Je ne suis pas sûr que le nombre de tests soit le plus difficile, mais plutôt le type de tests. »
Les types de tests ? Nânde ?
Laisser un commentaire