Cet article concerne l'événement "Tech Connect! Autumn" hébergé par Link Information System. Ceci est un article de relais. "Tech Connect! Autumn" est relayé par un membre du groupe engineer.hanzomon. (Cliquez ici pour le lien système d'information Facebook](https://ja-jp.facebook.com/lis.co.jp/))
Le premier jour, Daisuke, qui est le leader de cet événement, vous enverra un poème.
C'est un poème qui gonfle l '** impression subjective ** de java.io.InputStream que j'utilise habituellement.
・ ・ ・ ・ ・ ・ ・ L'impression que j'ai de Stream est "flow". Insérez un flux d'entrée qui semble avoir une pointe nette lors de la lecture d'un fichier, etc. dans le canon. Lorsque vous le poignardez, les données sortiront comme de l'eau, vous devrez donc la boire tout en la stockant progressivement avec un lecteur tampon.
Lors de l'écriture d'un programme, c'est un problème même s'il coule, donc je le bois en le fermant avec mes mains en précisant le montant à lire. read () et close () ** ont une sensation de fluidité / blocage, et sont aqueux et agréables **. Mais la méthode skip () saute n octets de données, alors qu'en est-il de l'eau entre les deux? La question se pose et ce n'est pas liquide. En premier lieu, InputStream peut gérer des octets, il est donc préférable d'avoir une forme carrée qui représente un nombre. Disons que vous avez une ligne de cartes avec des chiffres dessus. Oublions le baril et l'eau.
Si vous lisez d'abord (), vous obtiendrez la première carte. Étant donné que les nombres de 0 à 255 y sont écrits, vous pouvez l'interpréter librement comme ASCII ou comme faisant partie des données d'image.
Si vous relisez (), vous obtiendrez la carte suivante. Ainsi InputStream se souviendra de la position de la carte que vous venez de passer.
Read () est défini pour lire un octet à la fois, et une méthode pour spécifier la taille et lire rapidement est définie, et la spécification de taille read () appelle en interne 1 octet read ().
Mark () se souviendra de la position de la carte et reset () la ramènera à cette position. Le véritable java.io.InputStream se met en colère lorsque vous appelez reset () et lancez une IOException, mais comme vous n'utilisez pas autant mark () et reset () en premier lieu, vous ne savez pas ou n'avez pas besoin de savoir qu'il est facile de se mettre en colère. La flottabilité d'InputStream a complètement disparu, et même les cartes ont un sens du casino en raison de l'agitation.
Il y a available (), qui promet de vous dire combien de cartes il reste, mais le véritable java.io.InputStream renvoie toujours zéro. Peut-être parce que vous ne voulez pas supposer que la cible de lecture est énorme ou que vous avez affaire à des données continues? , L'oncle prescripteur qui gère le casino peut avoir décidé de renvoyer zéro.
Si vous avez fini de lire la dernière carte et que vous appelez à nouveau read (), -1 sera renvoyé. -1 quand il n'y a plus de cartes.
Comme je l'ai écrit jusqu'à présent, java.io.InputStream est un résumé. Je pense que pas mal de gens obtiennent la ** sensation d'interface ** du texte, mais c'est abstrait. S'il s'agit d'une interface, elle va médiatiser divers échanges sans travailler, ce qui donne l'impression d'une personne côté compilateur, mais comme InputStream est abstrait, cela donne une légère sensation de muscle et une impression de travail. Le croupier est la seule personne à distribuer des cartes au casino.
J'ai écrit que c'était un croupier de casino, mais le sentiment réel est plus net et plus sérieux, donc java.io.InputStream est proche d'un croupier de casino de villégiature soigné (en charge des cartes) qui porte des vêtements blancs et fait du bon travail. C'est ça? Je porte des lunettes à monture noire.
Les enfants qui ont hérité d'InputStream travaillent encore aujourd'hui dans divers casinos de villégiature, incorporant leurs gènes et leurs responsabilités en eux-mêmes. Derrière les lunettes est plein de réalisations et de confiance de JDK 1.0. Demain, c'est @ taisuke3.