[jira] Closed: (NET-166) [FTP] FTPClient should be an Interface

["Rory Winston (JIRA)" <ji...@apache.org>]

     [ 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.