Pourquoi la classe StringBuilder n'est-elle pas héritée de Stream?

Question

Je suis simplement curieux à ce sujet. Il me semble que le comportement d'un StringBuilder est fonctionnellement (sinon techniquement) identique à un flux - c'est un fichier contenant des données auxquelles d'autres données peuvent être ajoutées.

Encore une fois, juste curieux.

Answer 1

Le flux est une entrée et une sortie de données binaires .

StringBuilder est un moyen de créer des données texte .

Au-delà de cela, il y a le problème d'état - un StringBuilder a simplement la valeur actuelle, sans aucune idée de & "; position &"; Il vous permet d'accéder aux données et de les muter n'importe où. En revanche, un flux est logiquement un flux de données potentiellement infini, avec un curseur quelque part au milieu pour indiquer où vous en êtes. En règle générale, il vous suffit de lire / écrire en avant, avec Recherche / Position pour passer à une partie spécifique du flux de données.

Essayez d'imaginer l'implémentation de l'API Stream avec StringBuilder ... ça ne rentre tout simplement pas. Vous pouvez trier pour le faire, mais vous vous retrouveriez avec StringReader et StringWriter, en gros.

Answer 2

StringBuilder a plus que des fonctions d’ajout. Il possède également des fonctions d'insertion, ce qui n'est pas naturel pour un flux. Utilisez la StringWriter classe si vous voulez un flux qui enveloppe un <=>.

Answer 3

Un flux fait normalement référence à une source d’entrée / sortie externe (fichier, réseau). StringBuilder n'a pas cette caractéristique.

Answer 4

Parce que ce n'est pas vraiment un flux. C'est plus un tampon qui grandit.

Answer 5

Bien que des données puissent être ajoutées aux deux, la fonctionnalité dans son ensemble est différente.

Un flux sert à entrer ou à sortir des données de / vers une source, pas à construire quelque chose. StringBuilder n'a pas besoin des fonctionnalités fournies par Stream, comme la mise en mémoire tampon, etc. pour construire une ressource.

Answer 6

D'autre part, vous trouverez les classes StringReader / Writer dans System.IO. StringWriter , par exemple. implémente TextWriter contre un StringBuilder sous-jacent.

Personnellement, je ne l'ai jamais utilisé, mais si vous avez une routine d'écriture de fichier texte, vous pouvez le faire fonctionner avec un TextWriter . Ensuite, dans votre test, au lieu d'instancier un StreamWriter , vous instanciez un StringWriter et vous pouvez ensuite vérifier ce qui a été écrit en consultant le StringBuilder sous-jacent.

Maintenant, j'ai le vertige ...