commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Tauner (JIRA)" <j...@apache.org>
Subject [jira] Updated: (NET-166) [FTP] FTPClient should be an Interface
Date Thu, 26 Jul 2007 19:01:09 GMT

     [ 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message