Java继承:一个类的扩展应该继承该类吗?

时间:2013-09-20 22:30:27

标签: java design-patterns inheritance subclass extends

对于我当前的项目,我正在为java File类创建一个包装器,以及路径String的包装器(即C:\Users\Public\)。 让我们调用FileFileWrapper的包装器和路径PathWrapper的包装器。

FileWrapper显然必须有一条路径:FileWrapper的{​​{1}}在磁盘上的位置。现在我的问题是...... File应该包含FileWrapper类型的字段(以及PathWrapper的{​​{1}}的访问方法),还是应该扩展PathWrapper,因此继承{ {1}}方法?

我遇到的问题是PathWrapper.getPath(),严格来说,不是PathWrapper。这只是一个档案。但在这种情况下,只使用继承似乎更简单。

我正在考虑的第二个解决方案还有另一个问题(在getPath()中创建FileWrapper方法)。我想创建一个Path接口,getPath()FileWrapper都会实现,以便允许PathFileWrapper的通用列表。 如果PathWrapperFileWrapper的子类,则不需要此接口。

2 个答案:

答案 0 :(得分:4)

OO设计规则:赞成合成而不是继承,因为合成(Has-a关系)可以让代码更灵活

正如您所说,FileWrapper不是PathWrapper,您已回答了您的问题。

您想将它们绑定在一起,您可以将PathWrapper传递给FileWrapper的构造函数。

例如,如果您希望同时在集合中获取这两者,则可以创建 Wrapper 界面,其中FileWrapperPathWrapper是这个层次结构中的兄弟姐妹,并分享可以由每个人以不同方式实现的常见抽象方法。

许多设计模式可以应用于此示例,您需要做的就是首先确定您想要的内容。

答案 1 :(得分:2)

  

我遇到的问题是FileWrapper,严格来说,不是Path。这只是一个档案。

这是您需要的唯一考虑因素:一旦您在逻辑上说FileWrapper 而不是Path,您应该从您的选择列表中排除继承。

这并不是说你不应该给FileWrapper getPath方法:如果你发现在getPathFileWrapper更方便类,然后添加方法是完全合理的。

  

我想创建FileWrapperPathWrapper都会实现的“路径”界面,以便允许FileWrappersPathWrappers的通用列表。< / p>

这听起来不错。接口是子类化的一种不错的轻量级替代方法,在您的情况下更有意义。恰当地命名,这样的界面将增加整个系统的清晰度,而不会增加与可疑继承相关的混淆。