Le modèle Decorator existe-t-il dans les classes Java IO?

14

Pour une mission, je dois savoir qui de la bande des modèle de conception Quatre classes java.io.Readeret ses sous - classes java.io.PushbackReader, java.io.BufferedReaderet java.io.FilterReaderont été construits avec.

Selon ce post, le motif de conception serait le motif décorateur. Cela n'a de sens pour moi que si PushbackReader, BufferedReaderet FilterReaderpeut être décoré pour être utilisé en même temps, créant efficacement un BufferedPushbackFilterReader. C'est ça l'idée?

java design-patterns

— Communauté
source

Regardez les constructeurs de ces classes. Vous permettent-ils de vous empiler, par exemple la Buffered nature au-dessus de la Filternature?

— Kilian Foth

@Kilian Foth: Ça y ressemble.

10

Oui, vous pouvez en effet les décorer comme ça. Considérez simplement ce qui suit

PushbackReader pushbackBufferedReader = new PushbackReader(
     new BufferedReader(original));

Cela décorerait un lecteur original pour

être d'abord tamponné
puis activer la fonctionnalité pushback / non lu (toujours le résultat est mis en mémoire tampon ..)

FilterReaderet Readersont des classes de base dans la hiérarchie ...

Et BufferedReader, FilterReaderet PushbackReadersont les décorateurs de Reader, non?

1

Oui c'est correct.

— duffymo

1

Oui - BufferedReader met le lecteur sous-jacent en mémoire tampon, PushbackReader vous permet de «non lire» les données du lecteur, etc.

11

Le motif décorateur s'applique ici parce qu'il BufferedReaderenveloppe un Reader- c'est toujours un Reader(il a toutes les méthodes de Reader), mais il a plus de "cloches et de sifflets" (plus de méthodes).

Voici un exemple montrant comment une classe "décore" les fonctionnalités de celle qu'elle encapsule, et vous pouvez les enchaîner pour continuer à décorer:

        new BufferedReader(new FileReader(new File("some.file")));

— bohémien
source