33 votes

Différence entre une API obsolète et une API patrimoniale ?

J'étudiais les anciennes API dans les Java. Collection Framework et j'ai appris que des cours tels que Vector y HashTable ont été remplacés par ArrayList y HashMap .

Cependant, elles ne sont toujours pas dépréciées et sont considérées comme anciennes, alors que la dépréciation s'applique essentiellement aux fonctionnalités logicielles qui sont dépassées et doivent être évitées. Je ne sais donc pas exactement quand une API est considérée comme ancienne et quand elle est dépréciée.

29voto

polygenelubricants Points 136838

Extrait du glossaire officiel de Sun :

dépréciation : Fait référence à une classe, une interface, un constructeur, une méthode ou un champ qui n'est plus recommandé, et qui peut cesser d'exister dans une version future.

Du guide "Comment et quand déprécier" :

Vous avez peut-être déjà entendu l'expression "humour autodévalorisant", ou humour qui minimise l'importance de la personne qui parle. Une classe ou une méthode dépréciée est comme cela. Elle n'est plus importante. Elle est si peu importante, en fait, que vous ne devriez plus l'utiliser, car elle a été remplacée et pourrait cesser d'exister à l'avenir.

En @Deprecated L'annotation allait un peu plus loin et avertissait du danger :

Un élément de programme annoté @Deprecated est l'un de ceux que les programmeurs sont découragés d'utiliser, généralement parce qu'il est dangereux ou parce qu'il existe une meilleure alternative.

Références


Notez que le glossaire officiel ne définit pas ce que signifie "héritage". Selon toute vraisemblance, il s'agit d'un terme utilisé par Josh Bloch sans définition exacte. L'implication, cependant, est toujours qu'une classe héritée ne devrait jamais être utilisée dans un nouveau code, et qu'une meilleure substitution existe.

Peut-être qu'un ancien code utilisant des classes héritées mais non dépréciées ne nécessite aucune action, puisque pour le moment du moins, elles ne risquent pas de cesser d'exister dans une future version.

En revanche, la dépréciation avertit explicitement qu'ils peuvent cesser d'exister, et qu'il faut donc prendre des mesures pour migrer vers leur remplacement.


Citations de Effective Java 2e édition

Pour comparer la façon dont ces termes sont utilisés dans le contexte, voici des citations du livre où le mot "déprécié" apparaît :

Point 7 : Évitez les finalistes : Les seules méthodes qui prétendent garantir la finalisation sont System.runFinalizersOnExit et son jumeau diabolique Runtime.runFinalizersOnExit . Ces méthodes sont fatalement défectueuses et ont été dépréciées.

Item 66 : Synchroniser l'accès aux données mutables partagées : Les bibliothèques fournissent les Thread.stop mais cette méthode a été dépréciée il y a longtemps car elle est intrinsèquement non sécurisé -- son utilisation peut entraîner une corruption des données.

Point 70 : Sécurité du filetage des documents : Le site System.runFinalizersOnExit est hostile aux threads et a été dépréciée.

Point 73 : éviter les groupes de fils : Ils vous permettent d'appliquer certaines Thread à un grand nombre de threads en même temps. Plusieurs de ces primitives ont été dépréciées, et les autres sont peu utilisées. [...] les groupes de threads sont obsolètes.

En revanche, ce sont les citations où le mot "héritage" apparaît :

Point 23 : ne pas utiliser de types bruts dans le nouveau code : Ils sont fournis pour la compatibilité et l'interopérabilité avec le code hérité qui précède l'introduction des génériques.

Point 25 : Préférer les listes aux tableaux : L'effacement est ce qui permet aux types génériques d'interopérer librement avec le code hérité qui n'utilise pas les génériques.

Point 29 : envisager des conteneurs hétérogènes sûrs sur le plan du type : Ces wrappers sont utiles pour retrouver qui ajoute un élément mal typé à une collection dans une application qui mélange du code générique et du code hérité.

Point 54 : utiliser judicieusement les méthodes indigènes : Ils donnent accès à des bibliothèques de code patrimonial, qui pourraient à leur tour donner accès à des données patrimoniales. [...] Il est également légitime d'utiliser des méthodes natives pour accéder au code hérité. [...] Si vous devez utiliser des méthodes natives pour accéder à des ressources de bas niveau ou à des bibliothèques héritées, utilisez le moins de code natif possible et testez-le de manière approfondie.

Point 69 : préférer que les services publics de concurrence attendent et notifient. : Bien qu'il faille toujours utiliser les utilitaires de concurrence de préférence au wait y notify vous pourriez avoir à maintenir un code hérité qui utilise wait y notify .

Ces citations n'ont pas été soigneusement sélectionnées : ce sont TOUS des cas où le mot "déprécié" y "héritage" apparaissent dans le livre. Le message de Bloch est clair ici :

  • Les méthodes obsolètes, par exemple Thread.stop sont dangereux, et devraient jamais être utilisé.
  • D'autre part, par exemple wait/notify peuvent rester dans l'ancien code, mais ne doivent pas être utilisés dans le nouveau code.

Mon opinion subjective

Selon moi, déprécier quelque chose, c'est admettre que c'est une erreur et que cela n'a jamais été bon. D'autre part, classer quelque chose comme un héritage, c'est admettre qu'il était assez bon dans le passé, mais qu'il a atteint son but et n'est plus assez bon pour le présent et le futur.

15voto

Timo Westkämper Points 7950

Une interprétation courante est que Déprécié signifie qu'il sera supprimé dans un avenir proche, et Héritage signifie qu'il sera conservé pour des raisons de rétrocompatibilité ou autres.

Les deux signifient qu'ils ne devraient pas être utilisés par un nouveau code.

Dans le cas du JDK, même le code déprécié sera conservé, car la rétrocompatibilité est très importante pour le JDK Java.

1voto

pdbartlett Points 1061

La dépréciation indique souvent qu'il y a une intention de supprimer la fonctionnalité à un moment donné dans le futur, tandis que l'héritage implique simplement qu'elle ne devrait pas être utilisée dans un nouveau code si possible (bien qu'elle puisse être nécessaire pour des raisons d'interopérabilité).

0voto

kgiannakakis Points 62727

En Déprécié donne une définition formelle d'une API dépréciée. Je ne pense pas qu'une définition formelle pour les classes héritées existe. Les deux signifient en fait que la classe ne doit pas être utilisée dans le nouveau code.

0voto

foret Points 639

J'ai une suggestion - legacy se réfère au code qui a été écrit dans le passé, deprecated se réfère à la recommandation de ne plus l'utiliser. Vous pouvez toujours utiliser l'api dépréciée, mais vous ne pouvez pas écrire le code hérité, parce que vous l'écrivez maintenant. Juste IMHO

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X