Java继承：类的扩展是否应该继承该类？答案

【问题标题】：Java Inheritance: should an extension of a class inherit the class?Java继承：类的扩展是否应该继承该类？
【发布时间】：2013-09-26 10:26:20
【问题描述】：

对于我当前的项目，我正在为 java File 类制作一个包装器，以及一个路径 String 的包装器（即C:\Users\Public\）。让我们调用 File 类的包装器 FileWrapper 和路径的包装器 PathWrapper。

FileWrapper显然必须有一个路径：FileWrapper的File在磁盘上的位置。现在我的问题是... FileWrapper 应该包含 PathWrapper 类型的字段（以及 PathWrapper 的 PathWrapper.getPath() 的访问器方法），还是应该扩展 PathWrapper，从而继承 getPath() 方法？

我遇到的问题是FileWrapper，严格来说，不是Path。这只是一个文件。但在这种情况下，无论如何只使用继承似乎更简单。

我正在考虑的第二种解决方案还有另一个问题（在FileWrapper 中创建一个getPath() 方法）。我想创建一个FileWrapper 和PathWrapper 都将实现的Path 接口，以便允许FileWrappers 和PathWrappers 的通用列表。如果FileWrapper 是PathWrapper 的子类，则不需要此接口。

【问题讨论】：

java.io.File 没有获取路径和/或绝对路径的方法吗？如果您的 FileWrapper.class 是 File 的包装器，那么只需在本机调用该方法...不是吗？
FileWrapper.getPath() 将返回一个 PathWrapper 实例，其中包含一些花哨的方法，例如用于检查给定 PathWrapper 是否位于另一个 PathWrapper 定义的文件夹中的方法。
反过来也很方便PathWrapper.getFile()。
如果您想要的行为比您对该行为的实现更具体或更广为人知，或者如果您可以预期多种实现方式，那么基于接口的类型系统就是在您的数据中不存在紧密的、明确定义的“是”关系的情况下的方法。如果对期望的行为没有这样的关注，那么正确的方法是组合（这在任何情况下都是包装器所暗示的）。

标签： java design-patterns inheritance subclass extends

【解决方案1】：

我遇到的问题是FileWrapper，严格来说，不是Path。这只是一个文件。

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

这并不是说你不应该给 FileWrapper 一个 getPath 方法，但是：如果你发现在 FileWrapper 类上使用 getPath 更方便，那么它是非常有意义的添加方法。

我想创建一个FileWrapper 和PathWrapper 都将实现的“路径”接口，以便允许FileWrappers 和PathWrappers 的通用列表。

这听起来是个好主意。接口是子类化的一种不错的轻量级替代方案，在您的情况下更有意义。如果命名得当，这样的接口将为您的整个系统增加清晰度，而不会增加与可疑继承相关的混乱。

【讨论】：

我知道，传统上，我们会做出这样的区分。然而，在这种情况下，制作一个只有一行的 Path 接口似乎很麻烦。
@kryo 你可能想给Path 接口一个不同的名字——比如PathSource 或类似的名字，表明对象有一个路径（因此，让您调用getPath()) 而不是作为路径本身。
是的 Path 不是一个很好的名字，我只是暂时还没有想出一个描述性很强的名字。

【解决方案2】：

OO 设计规则：优先考虑组合而不是继承，因为组合（Has-a 关系）允许您的代码具有更大的灵活性

正如你所说，FileWrapper 不是PathWrapper，你回答了你的问题。

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

例如，如果您想在 Collection 中获取两者，则可以创建一个 Wrapper 接口，其中 FileWrapper 和 PathWrapper 是此层次结构中的兄弟姐妹，并共享可以由它们各自以不同方式实现的通用抽象方法。

许多设计模式都可以应用到这个例子中，你需要做的就是先决定你想要什么。

【讨论】：