[
https://issues.apache.org/jira/browse/NET-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Tauner updated NET-166:
------------------------------
Description:
imho the FTPClient inheritance hierarchy should be changed as follows:
FTPClient should be renamed to something else (e.g. FTPClientImpl).
a new Interface named FTPClient should be introduced which should be
implemented by both, the old FTPClient and FTPSClient.
shared code should be extracted and inherited.
why?
because atm its not possible (pls correct me if im wrong!) to extend the ftp
classes in such a way, that the resulting classes could have a common
superclass other than FTPClient.
e.g. i want to implement caching of dirlistings
the easiest way would be to define an interface CachingClient which extends the
new FTPClient interface with a method like
public FTPFile[] list(String dir, long timeDeltaMS) throws IOException;
one could then create two new classes CachingFTPClient and CachingFTPSClient,
which would implement the CachingClient interface and extend either
FTPClientImpl or FTPSClient.
that way you could have two caching client classes with a common parent
class/interface other than the current FTPClient, which is highly restrictive
when extending the current FTPClient classes: i cant use any other method than
those specified in FTPClient, if i want to share the source from both client
implementations.
another option to implement a feature like caching would be a proxy, but one
would have to forward all current FTPClient methods inside the proxy object,
which isnt very neat.
third option would be to use FTP directly, but thats a lot of unnecessary work
too.
i hope someone can understand what i wrote :)
cons: this would break client code, that tries to instantiate FTPClient.
thats a reason to change it before the release of commons net 2.0. btw
id be glad to help with this, if you contact/instruct me :)
edit: what i havent thought about, is, that current FTPClient extends class
FTP, which extends abstract class SocketClient
crap. :(
ill leave this issue open, because id like to hear some comments anyway
was:
imho the FTPClient inheritance hierarchy should be changed as follows:
FTPClient should be renamed to something else (e.g. FTPClientImpl).
a new Interface named FTPClient should be introduced which should be
implemented by both, the old FTPClient and FTPSClient.
shared code should be extracted and inherited.
why?
because atm its not possible (pls correct me if im wrong!) to extend the ftp
classes in such a way, that the resulting classes could have a common
superclass other than FTPClient.
e.g. i want to implement caching of dirlistings
the easiest way would be to define an interface CachingClient which extends the
new FTPClient interface with a method like
public FTPFile[] list(String dir, long timeDeltaMS) throws IOException;
one could then create two new classes CachingFTPClient and CachingFTPSClient,
which would implement the CachingClient interface and extend either
FTPClientImpl or FTPSClient.
that way you could have two caching client classes with a common parent
class/interface other than the current FTPClient, which is highly restrictive
when extending the current FTPClient classes: i cant use any other method than
those specified in FTPClient, if i want to share the source from both client
implementations.
another option to implement a feature like caching would be a proxy, but one
would have to forward all current FTPClient methods inside the proxy object,
which isnt very neat.
third option would be to use FTP directly, but thats a lot of unnecessary work
too.
i hope someone can understand what i wrote :)
cons: this would break client code, that tries to instantiate FTPClient.
thats a reason to change it before the release of commons net 2.0. btw
id be glad to help with this, if you contact/instruct me :)
> [FTP] FTPClient should be an Interface
> --------------------------------------
>
> Key: NET-166
> URL: https://issues.apache.org/jira/browse/NET-166
> Project: Commons Net
> Issue Type: Improvement
> Affects Versions: 2.0
> Reporter: Stefan Tauner
>
> imho the FTPClient inheritance hierarchy should be changed as follows:
> FTPClient should be renamed to something else (e.g. FTPClientImpl).
> a new Interface named FTPClient should be introduced which should be
> implemented by both, the old FTPClient and FTPSClient.
> shared code should be extracted and inherited.
> why?
> because atm its not possible (pls correct me if im wrong!) to extend the ftp
> classes in such a way, that the resulting classes could have a common
> superclass other than FTPClient.
> e.g. i want to implement caching of dirlistings
> the easiest way would be to define an interface CachingClient which extends
> the new FTPClient interface with a method like
> public FTPFile[] list(String dir, long timeDeltaMS) throws IOException;
> one could then create two new classes CachingFTPClient and CachingFTPSClient,
> which would implement the CachingClient interface and extend either
> FTPClientImpl or FTPSClient.
> that way you could have two caching client classes with a common parent
> class/interface other than the current FTPClient, which is highly restrictive
> when extending the current FTPClient classes: i cant use any other method
> than those specified in FTPClient, if i want to share the source from both
> client implementations.
> another option to implement a feature like caching would be a proxy, but one
> would have to forward all current FTPClient methods inside the proxy object,
> which isnt very neat.
> third option would be to use FTP directly, but thats a lot of unnecessary
> work too.
> i hope someone can understand what i wrote :)
> cons: this would break client code, that tries to instantiate FTPClient.
> thats a reason to change it before the release of commons net 2.0. btw
> id be glad to help with this, if you contact/instruct me :)
> edit: what i havent thought about, is, that current FTPClient extends class
> FTP, which extends abstract class SocketClient
> crap. :(
> ill leave this issue open, because id like to hear some comments anyway
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
