imaginez que pour dessiner un cube de côté l, une bonne API a une fonction cube(l) alors qu'une moins bonne aurait la fonction make_a_regular_hexahedron(d) où d est la diagonale et non le côté.
Plus tard, on se rend compte que notre fonction make_a_regular_hexahedron est vraiment chiante à utiliser. On aimerait bien changer le nom et le type de paramètre. Mais voilà, plein de logiciels l'utilisent et si on change cela, ça va "casser" la compatibilité ascendante => les développeurs devront revoir leur code et changer tous les endroits où ils créaient un cube avant s'ils veulent utiliser la nouvelle API.
Pourquoi ne pas tout simplement proposer, dans une nouvelle version de l'API, la fonction cube(l), qui se contenterait d'appeler la fonction make_a_regular_hexahedron(d), après avoir calculé la diagonale ? On a ainsi une compatibilité avec l'existant (qui continuera d'utiliser make_a_regular_hexahedron(d)) tout en proposant une meilleure API.
[^] # Re: Meilleure interface de développement, pas forcément meilleure 3D
Posté par windu.2b . En réponse au journal Direct3D vs OpenGL. Évalué à 10.
Pourquoi ne pas tout simplement proposer, dans une nouvelle version de l'API, la fonction
cube(l), qui se contenterait d'appeler la fonctionmake_a_regular_hexahedron(d), après avoir calculé la diagonale ? On a ainsi une compatibilité avec l'existant (qui continuera d'utilisermake_a_regular_hexahedron(d)) tout en proposant une meilleure API.