Question

我正与其他开发人员进行辩论，他不喜欢我为自定义需求进行子类化java.io.File的想法（例如，有AWSFile或GoogleCloudStorageFile，（为了论证），我们需要覆盖一些方法，如listFiles()，getAbsoluteFile等。子类java.io.File何时可以？

例如，为什么没有java.io.File可以实现的通用接口，以便它更通用？这是故意这样做的吗？

我想知道我的方法是否确实好或坏，正如我之前在其他API-s中看到过的那样（如果我没记错的话，我在{{1]中看到了相同的方法前一段时间）。

这个问题的目的不是为了开始一场火焰战或任何事情，而是为了得到一个如何实现不同类型的TrueZip实体（File，AWSFile的例子，等）并且可能获得有意义的利弊列表。

Answer 1

我个人的偏好是您创建一个界面RemoteFile，然后在那里实现远程文件所需的方法。

在其中我建议您放置远程获取和设置文件所需的所有方法类型。

public interface RemoteFile {
    public File getLocalFile();
    public String getRemotePath();
    public boolean isDirectory();
    public List<RemoteFile> listFiles();
    ... etc...
}

Answer 2

子类将与超类紧密耦合，您的代码将很弱。如果可能，您必须在继承之前尝试委托。

public class YourFileWrapper {

private File yourFile;


public File getYourFile() {
    return yourFile;
} 
//rest of your code

子类java.io.File是一个坏主意吗？

2 个答案: