Oui, je fais du "ifVictory", mais plutôt au sens "object.doVictory", et dans le doVictory, on a le test de victoire (et donc le contenu de la méthode se déroule que si la condition de victoire définie dans cette même méthode est remplie).
Cela pousse l'OO jusqu'au bout: au lieu de faire une condition "ailleurs" et de faire exécuter le code correspondant là aussi "ailleurs", je fais les deux dans la classe concernée par la victoire (ou par le parcours des données). Cela respecte d'ailleurs bien plus les design patterns et l'encapsulation:
Le couplage est très fort entre la fonction où se trouvent ces lignes et la classe de "object".
Le couplage est bien plus faible (le code en "sait" moins sur la classe de "object" que le précédent code).
Cela pousse l'OO jusqu'au bout: au lieu de faire une condition "ailleurs" et de faire exécuter le code correspondant là aussi "ailleurs", je fais les deux dans la classe concernée par la victoire (ou par le parcours des données). Cela respecte d'ailleurs bien plus les design patterns et l'encapsulation:
Code :
if (object.isVictorious())
object.victory();
Le couplage est très fort entre la fonction où se trouvent ces lignes et la classe de "object".
Code :
object.doVictoryIfNeeded();
Le couplage est bien plus faible (le code en "sait" moins sur la classe de "object" que le précédent code).