[
https://issues.apache.org/jira/browse/NET-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rory Winston closed NET-166.
----------------------------
Resolution: Later
> [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.
