Garder des api mouvantes et ne pas se cantonner a une structure bien déterminées a ses avantages. Il peut y avoir comme dans tout programme des problemes de conception. Garder une structure figée empeche de corriger ce genre de choses.
C'est vrai, mais il y a des limites.
Une API c'est l'equivalent d'un contrat, tu dis aux gens qui vont utiliser ton API :
"Voila les gars, les choses vont marcher comme cela, promis, vous pouvez les utiliser maintenant"
Quand tu t'amuses a casser ton API a chaque version, les gars n'ont plus du tout confiance en toi, ils en ont marre de devoir retoucher leur code et sortir une nouvelle version a chaque fois, se taper le support des gens qui leur demandent pourquoi ca marche plus,...
Bref, tu perds tes clients quand tu les mene en bateau trop souvent, meme chose avec les API.
La bonne facon de faire c'est soit :
1) Reflechir profondemment aux changements a faire, et changer l'architecture rarement, histoire de faire comprendre aux gens "on sait c'est chiant, mais fallait vraiment le faire"
2) Garder l'ancien API et introduire un nouveau en parrallele tout en marquant l'ancien obsolete avec indication claire que l'ancien disparaitra d'ici x periode.
On aboutirais alors a quelque chose comme windows XP qui peut encore faire tourner des applis DOS au détriment de la qualité du support des applis 32 bits
Tu m'expliqueras ou est le probleme...
Les applis DOS tournent grace a une machine virtuelle, l'OS en lui-meme ne fait rien pour garder la compatibilite DOS.
[^] # Re: Question ?
Posté par pasBill pasGates . En réponse à la dépêche Nouveau modèle de développement pour Linux. Évalué à 7.
C'est vrai, mais il y a des limites.
Une API c'est l'equivalent d'un contrat, tu dis aux gens qui vont utiliser ton API :
"Voila les gars, les choses vont marcher comme cela, promis, vous pouvez les utiliser maintenant"
Quand tu t'amuses a casser ton API a chaque version, les gars n'ont plus du tout confiance en toi, ils en ont marre de devoir retoucher leur code et sortir une nouvelle version a chaque fois, se taper le support des gens qui leur demandent pourquoi ca marche plus,...
Bref, tu perds tes clients quand tu les mene en bateau trop souvent, meme chose avec les API.
La bonne facon de faire c'est soit :
1) Reflechir profondemment aux changements a faire, et changer l'architecture rarement, histoire de faire comprendre aux gens "on sait c'est chiant, mais fallait vraiment le faire"
2) Garder l'ancien API et introduire un nouveau en parrallele tout en marquant l'ancien obsolete avec indication claire que l'ancien disparaitra d'ici x periode.
On aboutirais alors a quelque chose comme windows XP qui peut encore faire tourner des applis DOS au détriment de la qualité du support des applis 32 bits
Tu m'expliqueras ou est le probleme...
Les applis DOS tournent grace a une machine virtuelle, l'OS en lui-meme ne fait rien pour garder la compatibilite DOS.