Kev Jackson wrote:
2) If the FileUtilsFactory is called from or implemented in
FileUtils.getFileUtils() / FileUtils.newFileUtils(), every task is
going to benefit.
I think the implementation I provided does precisely this, or rather
it calls from the interface (FileUtilsAdapter) instead of from the
implementation. If you mean that the current FileUtils should
delegate to another implementation using the factory that's different.
I think it would be cleaner to gradually transition all the tasks over
to an interface (while retaining the FileUtils semi-singleton). At
the point where all the tasks are using FileUtilsAdapter, we can
refactor and remove the parts of FileUtils that are exposed correctly
in the interface, maintaining bwc that way - the only thing left would
be a small stub which contains the static methods - that's my view of
how a transition would work anyway.
I think that using FileUtils to delegate/proxy to a real class would
be less 'elegant' than using an interface - although I can see the
immediate advantages of using the approach you mentioned (all tasks
benefit without actually having to change each class over to the
interface).
In that case I would like some time to think things over, as to provide
one face, and to have different implementations for currently different
parts.
Classes that support copying, things that support permissions, things
that support path manipulation, without getting a really big number of
classes.
FileUtils for Java 1.6 on Windows
FileUtils for Java 1.4 on VMS
etc.
I had an idea to turn FileUtils into a Facade that delegates different
actions to different back-ends.
Thanks for your elaborate reaction.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
