Doesnt lead such a design to have tons of saveAnd.... methods. And the code within those objects is highly redundant, isnt it?void save(final OutputStream newContents, final FileObject dest) throws FileSystemException; void saveAndOverwrite(final OutputStream newContents, final FileObject dest) throws FileSystemException;
How strong is your preference?
However, I will let this decision on you. I never tried this style, maybe it become accepted.
;-) Wasnt it me? I wanted you to use a BackupPolicy. And yes - I think this is the cleanest solution. I just thought you didnt want to go this way now as I missed it in your latest proposal.If overwrite=false and the destination exists the methods should use "backup()" to create a backup of the destination fileAs an alternative, I took someone's suggestion of a policy object when I started coding a default implementation of the FileOperation interface, and let the policy object figure these things out.
If you already took this way it is even better.
I like save() because it describes the operation most closely from the point of view of the caller ("Hey, save this file with these new contents!"). The reason I used InputStream everywhere was for genericness (is that a word?). I pictured usage like this:You ask me? A non native speaker. However, it sounds cool ;-))
// copy(src, dst) in your snippet operations.save(src, otherFile.getInputStream()); operations.save(src, new ByteArrayInputStream(blobInMemory.toArray());
Didnt you mean? operations.save(otherFile.getInputStream(), dest); operations.save(new ByteArrayInputStream(blobInMemory.toArray()), dest);
But every Filesystem call it copy and even if you use a file-manager there is a menu-entry called "copy". "save" or "save As" only exists if you do have the content of the file open in an editor - and then, from the point of development - it is easier if the save method took an outputStream.
--- Mario
smime.p7s
Description: S/MIME Cryptographic Signature
