| Penser en Java 2nde édition | - | Sommaire | Préface | Avant-propos | Chapitre : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Annexe : A B C D | Tables des matières | - | Thinking in Java |
Il est possible de transformer un tableau en List grâce à la méthode Arrays.asList() :
En fait, seule une partie des interfaces Collection et List est implémentée. Le reste des méthodes provoque l'apparition déplaisante d'une chose appelée UnsupportedOperationException. Vous en apprendrez plus sur les exceptions dans le chapitre suivant, mais pour résumer l'interface Collection - de même que certaines autres interfaces de la bibliothèque de conteneurs Java - contient des méthodes « optionnelles », qui peuvent ou non être « supportées » dans la classe concrète qui implémente cette interface. Appeler une méthode non supportée provoque une UnsupportedOperationException pour indiquer une erreur de programmation.
« Comment ?!? » vous exclamez-vous, incrédule. « Tout l'intérêt des interfaces et des classes de base provient du fait qu'elles promettent que ces méthodes feront quelque chose d'utile ! Cette affirmation rompt cette promesse - non seulement ces méthodes ne réalisent pas d'opération intéressante, mais en plus elles arrêtent le programme ! Qu'en est-il du contrôle de type ? »
Ce n'est pas si grave que ça. Avec une Collection, une List, un Set ou une Map, le compilateur empêche toujours d'appeler des méthodes autres que celles présentes dans cette interface, ce n'est donc pas comme Smalltalk (qui permet d'appeler n'importe quelle méthode sur n'importe objet, appel dont on ne verra la pertinence que lors de l'exécution du programme). De plus, la plupart des méthodes acceptant une Collection comme argument ne font que lire cette Collection - et les méthodes de « lecture » de Collection ne sont pas optionnelles.
Cette approche empêche l'explosion du nombre d'interfaces dans la conception. Les autres conceptions de bibliothèques de conteneurs semblent toujours se terminer par une pléthore d'interfaces pour décrire chacune des variations sur le thème principal et sont donc difficiles à appréhender. Il n'est même pas possible de capturer tous les cas spéciaux dans les interfaces, car n'importe qui peut toujours créer une nouvelle interface. L'approche « opération non supportée » réalise l'un des buts fondamentaux de la bibliothèque de conteneurs Java : les conteneurs sont simples à apprendre et à utiliser ; les opérations non supportées sont des cas spéciaux qui peuvent être appris par la suite. Pour que cette approche fonctionne, toutefois :
Dans l'exemple précédent, Arrays.asList() produit une List supportée par un tableau de taille fixe. Il est donc sensé que les seules opérations supportées soient celles qui ne changent pas la taille du tableau. D'un autre côté, si une nouvelle interface était requise pour exprimer ce différent type de comportement (peut-être appelée « FixedSizeList »), cela laisserait la porte ouverte à la complexité et bientôt on ne saurait où donner de la tête lorsqu'on voudrait utiliser la bibliothèque.
La documentation d'une méthode qui accepte une Collection, une List, un Set ou une Map en argument doit spécifier quelles méthodes optionnelles doivent être implémentées. Par exemple, trier requiert les méthodes set() et Iterator.set(), mais pas add() ou remove().
Malheureusement, beaucoup de code a été écrit en utilisant les conteneurs Java 1.0 / 1.1, et ajourd'hui encore ces classes continuent d'être utilisées dans du nouveau code. Bien qu'il faille éviter d'utiliser les anciens conteneurs lorsqu'on produit du code nouveau, il faut toutefois être conscient qu'ils existent. Cependant, les anciens conteneurs étaient plutôt limités, il n'y a donc pas tellement à en dire sur eux (puisqu'ils appartiennent au passé, j'éviterais de trop me pencher sur certaines horribles décisions de conception).
Le Vector était la seule séquence auto-redimensionnable dans Java 1.0 / 1.1, ce qui favorisa son utilisation. Ses défauts sont trop nombreux pour être décrits ici (se référer à la première version de ce livre, disponible sur le CD ROM de ce livre et téléchargeable sur www.BruceEckel.com). Fondamentalement, il s'agit d'une ArrayList avec des noms de méthodes longs et maladroits. Dans la bibliothèque de conteneurs Java 2, la classe Vector a été adaptée afin de pouvoir s'intégrer comme une Collection et une List, et donc dans l'exemple suivant la méthode Collections2.fill() est utilisée avec succès. Ceci peut mener à des effets pervers, car on pourrait croire que la classe Vector a été améliorée alors qu'elle n'a été incluse que pour supporter du code pré-Java2.
La version Java 1.0 / 1.1 de l'itérateur a choisi d'inventer un nouveau nom, « énumération », au lieu d'utiliser un terme déjà familier pour tout le monde. L'interface Enumeration est plus petite qu'Iterator, ne possédant que deux méthodes, et utilise des noms de méthodes plus longs : boolean hasMoreElements() renvoie true si l'énumération contient encore des éléments, et Object nextElement() renvoie l'élément suivant de cette énumération si il y en a encore (autrement elle génére une exception).
Enumeration n'est qu'une interface, et non une implémentation, et même les nouvelles bibliothèques utilisent encore quelquefois l'ancienne Enumeration - ce qui est malheureux mais généralement sans conséquence. Bien qu'il faille utiliser un Iterator quand on le peut, on peut encore rencontrer des bibliothèques qui renvoient des Enumerations.
Toute Collection peut produire une Enumeration via la méthode Collections.enumerations(), comme le montre cet exemple :
La classe Vector de Java 1.0 / 1.1 ne dispose que d'une méthode addElement(), mais fill() utilise la méthode add() qui a été copiée quand Vector a été transformé en List. Pour produire une Enumeration, il faut appeler elements(), on peut alors l'utiliser pour réaliser une itération en avant.
La dernière ligne crée une ArrayList et utilise enumeration() pour adapter une Enumeration à partir de l'Iterator de l'ArrayList. Ainsi, si on a du vieux code qui requiert une Enumeration, on peut tout de même utiliser les nouveaux conteneurs.
Comme on a pu le voir dans les tests de performances de ce chapitre, la Hashtable de base est très similaire au HashMap, et ce même jusqu'aux noms des méthodes. Il n'y a aucune raison d'utiliser Hashtable au lieu de HashMap dans du nouveau code.
Le concept de la pile a déjà été introduit plus tôt avec les LinkedLists. Ce qui est relativement étrange à propos de la classe Stack Java 1.0 / 1.1 est qu'elle est dérivée de Vector au lieu d'utiliser un Vector comme composant de base. Elle possède donc toutes les caractéristiques et comportements d'un Vector en plus des comportements additionnels d'une Stack. Il est difficile de savoir si les concepteurs ont choisi délibérément cette approche en la jugeant particulièrement pratique ou si c'était juste une conception naïve.
Voici une simple illustration de Stack qui « pousse » chaque ligne d'un tableau String :
Chaque ligne du tableau months est insérée dans la Stack avec push(), et récupérée par la suite au sommet de la pile avec un pop(). On peut aussi réaliser des opérations de Vector sur l'objet Stack. Ceci est possible car, de par les propriétés de l'héritage, une Stack est un Vector. Donc toutes les opérations qui peuvent être effectuées sur un Vector peuvent aussi être réalisées sur une Stack, comme elementAt().
Ainsi que mentionné précédemment, il vaut mieux utiliser une LinkedList si on souhaite un comportement de pile.
Un BitSet est utile si on veut stocker efficacement un grand nombre d'informations on-off. Cette classe n'est efficace toutefois que sur le plan de la taille ; si le but recherché est un accès performant, mieux vaut se tourner vers un tableau de quelque type natif.
De plus, la taille minimum d'un BitSet est celle d'un long, soit 64 bits. Ce qui implique que si on stocke n'importe quelle quantité plus petite, telle que 8 bits, un BitSet introduira du gaspillage ; il vaudrait donc mieux créer sa propre classe, ou utiliser un tableau, pour stocker les flags si la taille est un problème.
Un conteneur normal se redimensionne si on ajoute de nouveaux éléments, et un BitSet n'échappe pas à la règle. L'exemple suivant montre comme le BitSet fonctionne :
Le générateur de nombres aléatoires est utilisé pour générer un byte, un short et un int au hasard, et chacun est transformé en motif de bits dans un BitSet. Ceci fonctionne bien puisque la taille d'un BitSet est de 64 bits, et donc aucune de ces opérations ne nécessite un changement de taille. Un BitSet de 512 bits est alors créé. Le constructeur alloue de la place pour deux fois ce nombre de bits. Cependant, on peut tout de même positionner le bit 1024 ou même au delà.
Pour résumer les conteneurs fournis dans la bibliothèque standard Java :
Les conteneurs sont des outils qu'on peut utiliser jour après jour pour rendre les programmes plus simples, plus puissants et plus efficaces.
