Chapitre 11 - Le système d’E/S de Java

Les types d'OutputStream

Cette catégorie contient les classes qui décident de l'endroit où iront vos données de sorties : un tableau de bytes (pas de String, cependant ; vraisemblablement vous pouvez en créer un en utilisant le tableau de bytes), un fichier, ou un « tuyau.»

En complément, le FilterOutputStream fournit une classe de base pour les classes de « décoration » qui attachent des attributs ou des interfaces utiles aux flux de sortie.

Tableau 11-2. Les types d'OutputStream

Ajouter des attributs et des interfaces utiles

L'emploi d'objets en couches pour ajouter dynamiquement et de manière claire des responsabilités aux objets individuels est mentionné comme un Pattern de Décoration. (Les Patterns[ 57 ] sont le sujet de Thinking in Patterns with Java, téléchargeable à <www.BruceEckel.com>.) Le Pattern de décoration précise que tous les objets qui entourent votre objet initial possèdent la même interface. Ceci rend l'usage basique des décorateurs claire — vous envoyez le même message à un objet qu'il soit décoré ou non. C'est la raison de l'existence des classes « filter » dans la bibliothèque E/S de Java : la classe abstraite « filter » est la classe de base pour tous les décorateurs. (Un décorateur doit avoir la même interface que l'objet qu'il décore, mais le décorateur peut aussi étendre l'interface, ce qui se produit dans un certain nombre de classes « filter »).

Les décorateurs sont souvent employés quand un simple sous-classement touche un grand nombre de sous-classes pour satisfaire toutes les combinaisons possibles nécessaires — avec tellement de sous-classes que cela devient peu pratique. La bibliothèque d'E/S Java demande différentes combinaisons de caractéristiques, c'est pourquoi le Pattern de décoration est employé. Il y a un désavantage au Pattern de décoration, néanmoins les décorateurs vous donnent une plus grande flexibilité pendant l'écriture d'un programme (puisque vous pouvez facilement mélanger et assembler des attributs [attributes]), mais ils ajoutent de la complexité à votre code. La raison pour laquelle la bibliothèque d'E/S de Java n'est pas pratique d'emploi est que vous devez créer beaucoup de classes — le type « noyau » d'E/S plus tous les décorateurs — afin d'obtenir le simple objet E/S désiré.

Les classes qui procurent l'interface de décoration pour contrôler un InputStream ou OutputStream particulier sont FilterInputStream et FilterOutputStream &mdash; lesquelles n'ont pas des noms très intuitifs. FilterInputStream et FilterOutputStream sont des classes abstraites qui sont dérivées depuis les classes de base de la bibliothèque d'E/S, InputStream et OutputStream, ceci étant l'exigence clef du décorateur (afin qu'il procure une interface commune à tous les objets qui seront décorés).

Lire depuis un InputStream avec FilterInputStream

La classe FilterInputStream accomplit deux choses significatives différentes. DataInputStream vous permet de lire différents types de données primitives tout aussi bien que des objets String. (Toutes les méthodes commencent avec « read, » comme readByte(), readFloat(), etc.) Ceci, accompagné par DataOutputStream, vous permet de déplacer des données primitives d'une place à une autre en passant par un flux. Ces « places » sont déterminées par les classes du Tableau 11-1.

Les classes restantes modifient le comportement interne d'un InputStream : s'il est mis en tampon ou pas, si il garde trace des lignes qu'il lit (vous permettant de demander des numéros de ligne ou de régler le numéro de ligne), et si vous pouvez pousser en arrière un caractère seul. Les deux dernières classes ressemblent beaucoup à une ressource pour construire un compilateur (c'est à dire, elles ont étés ajoutées en support pour la construction du compilateur Java), donc vous ne l'utiliserez probablement pas en programmation habituelle.

Vous devrez probablement presque tout le temps mettre en tampon votre entrée, sans prendre en compte l'élément d'E/S auquel vous vous connectez, ainsi il aurait été plus censé pour la bibliothèque d'E/S de faire un cas spécial (ou un simple appel de méthode)pour l'entrée non mise en tampon plutôt que pour l'entrée mise en tampon.

Tableau 11-3. Les types de FilterInputStream

Écrire vers un OutputStream avec FilterOutputStream

Le complément à DataInputStream est DataOutputStream, lequel formate chacun des types de primitive et objets String vers un flux de telle sorte que n'importe quel DataInputStream, sur n'importe quelle machine, puisse le lire. Toutes les méthodes commencent par « write », comme writeByte(), writeFloat(), etc.

À l'origine, l'objectif de PrintStream est d'imprimer tous les types de données primitive et objets String dans un format perceptible. Ce qui est différent de DataOutputStream, dont le but est de placer les éléments de données dans un flux de manière que DataInputStream puisse de façon portable les reconstruire.

Les deux méthodes importantes dans un PrintStream sont print() et println(), qui sont surchargées [overloaded] pour imprimer tous les types différents. La différence entre print() et println() est que le dernier ajoute une nouvelle ligne une fois exécuté.

PrintStream peut être problématique car il piège toutes les IOExceptions (vous devrez tester explicitement le statut de l'erreur avec checkError(), lequel retourne true si une erreur c'est produite. Aussi, PrintStream n'effectue pas l'internationalisation proprement et ne traite pas les sauts de ligne de manière indépendante de la plate-forme (ces problèmes sont résolus avec PrintWriter).

BufferedOutputStream est un modificateur, il dit au flux d'employer le tampon afin de ne pas avoir une écriture physique chaque fois que l'on écrit vers le flux. On employera probablement souvent ceci avec les fichiers, et peut être la console E/S.

Tableau 11-4. Les types de FilterOutputStream

Lecteurs & écrivains [ Loaders & Writers ]

Java 1.1 apporte quelques modifications significatives à la bibliothèque fondamentale de flux d'E/S (Java 2, cependant, n'apporte pas de modifications fondamentales). Quand vous voyez les classes Reader et Writer votre première pensée (comme la mienne) doit être que celles-ci ont pour intention de remplacer les classes InputStream et OutputStream. Mais ce n'est pas le cas. Quoique certains aspects de la bibliothèque originale de flux sont dépréciés (si vous les employez vous recevrez un avertissement de la part du compilateur), les classes InputStream et OutputStream fournissent pourtant de précieuses fonctions dans le sens d'un E/S orienté byte, tandis que les classes Reader et Writer fournissent une E/S à base de caractères se pliant à l'Unicode. En plus :

1. Java 1.1 a ajouté de nouvelles classes dans la hiérarchie d'InputStream et OutputStream, donc il est évident qu'elles ne sont pas remplacées.
2. Il y a des fois ou vous devrez employer les classes de la hiérarchie « byte » en combinaison avec les classes de la hiérarchie « caractère ». Pour cela il y à des classes « passerelles » : InputStreamReader convertit un InputStream en un Reader et OutputStreamWriter convertit un OutputStream en un Writer.

La raison la plus importante des hiérarchies de Reader et Writer est l'internationalisation. L'ancienne hiérarchie de flux d'E/S ne supporte que des flux de bytes de 8-bit et ne traite pas bien les caractères Unicode de 16-bit. Depuis qu'Unicode est employé pour l'internationalisation (et les char natifs de Java sont en Unicode 16-bit), les hiérarchies de Reader et Writer ont été ajoutées pour supporter l'Unicode dans toutes les opérations d'E/S. En plus, les nouvelles bibliothèques sont conçues pour des opérations plus rapides que l'ancienne.

Comme il est de coutume dans ce livre, j'aurais aimé fournir une synthèse des classes, mais j'ai supposé que vous utiliserez la documentation en ligne pour éclaircir les détails, comme pour la liste exhaustive des méthodes.

Les sources et les réceptacles de données

Presque toutes les classes originales de flux d'E/S Java possèdent des classes Reader et Writer correspondantes afin de fournir une manipulation native en Unicode. Cependant, il y a certains endroits où les InputStreams et les OutputStreams orientés-byte sont la solution adoptée ; en particulier, les bibliothèques java.util.zip sont orientées-byte plutôt qu'orientée-char. Donc l'approche la plus sage est d'essayer d'utiliser les classes Reader et Writer chaque fois que c'est possible, et vous découvrirez des situations où il vous faudra employer les bibliothèques orientées-byte parce que votre code ne se compilera pas.