我正在寻找装饰器模式的替代方案,以使其更具活力。作为一个简单的示例,假设我们有以下代码:
interface Resource {
public String getName();
}
interface Wrapper extends Resource {
public Resource getSource();
}
interface Readable extends Resource {
public InputStream getInputStream();
}
interface Listable extends Resource {
public List<Resource> getChildren();
}
class File implements Readable {
...
}
class Zip implements Listable, Wrapper {
public Zip(Readable source) { ... }
}
如您所见,Zip 并没有直接实现 Readable,但是它正在读取的资源却可以。假设我们构建一个 zip:
Zip zip = new Zip(new File());
我不想(也不能)堆叠所有接口以相互扩展(例如 Listable 扩展 Readable),我也不能构造所有对象来实现所有功能,因为并非所有功能都相互关联,你想要能够通过包装它们来动态“装饰”对象。
我确定这是一个常见问题,但有解决它的模式吗?使用“包装器”界面,您当然可以根据需要探测资源链以检查功能,但我不确定这是否是一种理智的方法。
更新
问题如上所述,并非所有功能都相关,因此您无法构建良好的接口层次结构。例如,假设您有这个任意的新功能:
interface Rateable extends Resource {
public int getRating();
}
class DatabaseRateable implements Rateable, Wrapper {
public DatabaseRateable(Resource resource) { ... }
}
如果你运行:
Resource resource = new DatabaseRateable(new Zip(new File));
生成的资源已经“丢失”了所有添加的功能(可读、可列出......)。让 Rateable 扩展说 Listable 是荒谬的。
我可以再次递归检查 resource.getSource() 并找出所有功能。在立即答复中没有明确的解决方案,所以也许递归检查毕竟是一个不错的选择?