> o) The usage of the "Archiver" is still awkward. You create an > Archiver, then set the filename of the archive. Why not have an > "Archive" interface representing the archive and a "ArchiveFactory" > > Archive arch = ArchiveFactory.getInstance(new File("my.tar");please take a look at the examples: Archiver archiver = ArchiverFactory.getInstance( new File("C:\\Temp\\ZIPTEST.zip")); You can allready do that. Further you can do this: If you don't have one, you are going thru ArchiverFactory.getInstance("zip"); And set the name with Archiver.save(File); Please verify if you have draft 7.
IMO you add a file to the individual "Archive" not to the "Archvier". That's why I would prefer to have a "TarArchive" that represents the original archive file. Its name would be immutable. So I suggest o Archiver -> Archive o make the Archive name immutable (no setName) But maybe I am off here ...any other opinions?
I think it's a good thing to move the Decompressor Interface methods to the Compressor interface too and to delete the Decompressor. This is similar to Archiver, which is a nice thing now.
Hm... I liked the separation ...but I fear you are right - will there at any stage be a compressor without the decompressor? That's the questions. Answer: it probably should not. So it might be ok... What do others think?
> o) If you want a certain compressor without going through the factory I > think > > Compressor compressor = Bzip2Compressor.getInstance(); > > would be the right way to go. Ok, that's easy. Why would someone like to do that?
Think you are right - direct instanciation is probably good enough. Compressor compressor = new Bzip2Compressor(); Question is whether compressor is threadsafe and one instance could be shared ...but fair enough. Probably better that way. Thanks! cheers -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
