Version imprimable
<HS>
@Rod: Dans l'exemple que tu cites, on pourrait pas passer par friend (entre le moteur et widget) ou "inverser" le mécanisme, on ne passe pas le widget au moteur, mais le moteur au widget qui pourra donc passer les info qu'il veut ensuite ? (idée comme ca, pas réfléchie plus en profondeur)
</HS>
<HS>friend c'est ok si effectivement il n'y a que quelques classes qui auront besoin de cette donnée. Mais un moteur de rendu graphique ne peut malheureusement pas contenir dans une seule classe, et dans cet exemple particulier, il est difficile de faire en sorte que seules 2 ou 3 classes aient besoin de connaitre ce rectangle englobant.Citation:
Envoyé par Flob90
Bien sûr, certains me dirons que si j'en arrive là c'est parce que j'ai fait des erreurs de conception, que je ne sais pas refactoriser mon code ou que je suis fainéant. Effectivement, dans la théorie on devrait pouvoir parvenir à une parfaite encapsulation et une sémantique 100% utile. Dans la pratique c'est pas toujours facile...
Cette solution ne fonctionne pas car elle ne fait que déplacer le problème: celui qui calculer les collisions, qui que ce soit, aura besoin de connaitre les rectangles englobants de tous les objets qui doit gérer.Citation:
Envoyé par Flob90
</HS>
Oui les betes accesseurs sont des compromis parfois difficile a éviter.
Dans le pire des cas je fais des accesseurs sans verbes, genre machin.truc();
Dans l'idéal je transforme cela en verbe, mais plus on va vers des systèmes "basiques" plus c'est difficile de ne pas passer par des accesseurs betes. Typiquement les objets contenant uniquement des données (et peu de logique concernant ces données) sont candidates aux accesseurs.
Pour le reste il y a eurocardmaster... heu les fonctions de service plutot :D
Pour continuer sur le HS de r0d : V comme visiteur comme dirait l'autre camarade