我正在尝试创建一个能够在我的程序中处理文件管理的对象。
Path 接口几乎有我需要的所有方法,但我想添加一些自定义的方法。如果我在我的对象中实现 Path,我将不得不覆盖所有路径的方法。
有没有办法创建一个具有 Path 接口的所有方法和一些附加方法的对象,而不实际覆盖接口的方法?
在某种程度上,我想扩展 Path 接口,但也可以定义任何其他方法体。
我正在尝试创建一个能够在我的程序中处理文件管理的对象。
Path 接口几乎有我需要的所有方法,但我想添加一些自定义的方法。如果我在我的对象中实现 Path,我将不得不覆盖所有路径的方法。
有没有办法创建一个具有 Path 接口的所有方法和一些附加方法的对象,而不实际覆盖接口的方法?
在某种程度上,我想扩展 Path 接口,但也可以定义任何其他方法体。
您可以使用装饰器模式。
还记得BufferedReader吗?这与您的情况非常相似-它是任何Reader周围的薄包装器(装饰器) ,使其缓冲并具有一些其他方法(可以读取行)。
public class DecoratedPath implements Path {
private final Path path;
public DecoratedPath(Path path) {
this.path = path;
}
public DecoratedPath(String stringPath) {
this(Paths.get(stringPath));
}
// add any additional constructors / factory methods you like
@Override
public int compareTo(Path other) {
return path.compareTo(other);
}
@Override
public int endsWith(Path other) {
return path.endsWith(other);
}
// Etc. for all the methods of the Path interface.
// They'll all delegate to the methods of the path field.
// You can also enhance some of them, if you want to,
// to return DecoratedPath instead of Path.
// your additional methods
}
用法:
DecoratedPath path = new DecoratedPath("/some/path");
我可能会警告您有关路径接口的一些小问题。另外,我对实现这个接口有两个建议。
据我所知,路径接口用于为文件操作符对象中的路径创建类型引用点。可以使用 Paths Helper Class 创建 Path(注意 -s)。但是,它从未被任何类实现。因此,它是一个用于在通用类型中传递数据的接口。这意味着,coder 应该使用 Path Interface 作为类型发送信息,然后在声明为接收 Path Type Object 的其他类操作上使用 Path Typed Object。因此,在我看来,实现路径类并不是必需的。
正如我所提到的,我可以建议你两件事:虽然,这些类型的实践不是好的设计决策。JavaSE7 Doc中也提到了这个问题:here
1) 首先,您不必为接口中的所有方法添加行为。您可以使用“未实现”的消息日志声明它们并返回空值。
2)但更好的方法是使用 Ali Alamiri 提到的抽象类。我个人不会大惊小怪地为抽象创建一个子类,而只是实现我想要的方法。如果我想为它制作更容错的应用程序,那么使用子类来携带所有未实现的方法并为所有这些方法使用警告消息日志。
您可以做的是创建一个abstract
实现Path
接口的类。在这个类中,您可以实现方法或不实现它们,以便另一个类可以处理它们。然后你可以扩展这个抽象类并覆盖你想要的任何方法,你不必覆盖每一个方法。
例如:
public abstract class AbstractPath implements Path
{
//All methods declarations from Path interface
}
public class Base extends AbstractPath
{
//Override any method declared in AbstractPath
}