有什么从具体类继承的好例子吗？

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

想要改进这个问题吗？通过编辑这篇文章来更新问题，使其仅关注一个问题。

6 年前已关闭。

Answer 1

您通常有一个接口I的骨架实现。如果您可以在没有抽象方法的情况下提供可扩展性（例如通过钩子），那么最好有一个非抽象骨架类，因为您可以实例化它。

一个例子是转发包装类，能够转发到实现I的具体类C的另一个对象，例如启用装饰或C的简单代码重用，而无需从继承C。您可以在 Effective Java 第 16 项中找到这样的示例，优先选择组合而不是继承。 （由于版权原因，我不想将其发布在这里，但它实际上只是将 I 的所有方法调用转发到包装的实现）。

Answer 2

我认为以下是一个合适的例子：

public class LinkedHashMap<K,V>
    extends HashMap<K,V>

另一个很好的例子是异常的继承：

public class IllegalFormatPrecisionException extends IllegalFormatException
public class IllegalFormatException extends IllegalArgumentException
public class IllegalArgumentException extends RuntimeException
public class RuntimeException extends Exception
public class Exception extends Throwable

Answer 3

我能想到的一种非常常见的情况是从基本的 UI 控件派生，例如表单、文本框、组合框等。它们是完整的、具体的，并且能够独立存在；然而，它们中的大多数也非常基本，有时它们的默认行为并不是您想要的。例如，几乎没有人会使用纯粹的 Form 实例，除非他们可能正在创建一个完全动态的 UI 层。

例如，在我编写的一个最近达到相对成熟的软件中（这意味着我没有时间主要专注于开发它:)），我发现我需要向 ComboBox 添加“延迟加载”功能，因此它不会第一个窗口加载需要 50 年（以计算机年为单位）。我还需要能够根据另一个组合框中显示的内容自动筛选一个组合框中的可用选项，最后，我需要一种方法将一个组合框的值“镜像”到另一个可编辑控件中，并使一个控件中的更改发生在另一个可编辑控件中。其他也一样。因此，我扩展了基本的 ComboBox 以赋予它这些额外的功能，并创建了两种新类型：LazyComboBox，然后是 MirroringComboBox。两者都基于完全可用的具体 ComboBox 控件，只是覆盖一些行为并添加其他一些行为。它们不是非常松散耦合，因此不太坚固，但添加的功能足够通用，如果必须的话，我可以从头开始重写这些类中的任何一个来完成相同的工作，甚至可能更好。

Answer 4

一般来说，我唯一一次从具体类派生是当它们位于框架中时。派生自 Applet 或 JApplet 是一个简单的例子。

Answer 5

这是我当前正在实施的一个示例。

在 OAuth 2 环境中，由于文档仍处于草案阶段，因此规范不断变化（截至撰写本文时，我们处于版本 21）。

因此，我必须扩展具体的 AccessToken 类以适应不同的访问令牌。

在早期的草案中，没有设置 token_type 字段，因此实际的访问令牌如下：

public class AccessToken extends OAuthToken {

    /**
     * 
     */
    private static final long serialVersionUID = -4419729971477912556L;
    private String accessToken;
    private String refreshToken;
    private Map<String, String> additionalParameters;

    //Getters and setters are here
}

现在，有了返回 token_type 的访问令牌，

public class TokenTypedAccessToken extends AccessToken {

    private String tokenType;
    //Getter and setter are here...
}

我就可以返回两者和最终用户都一无所知。 :-)

总结： 如果您想要一个与具体类具有相同功能的自定义类，而不更改具体类的结构，我建议扩展具体类。

Answer 6

我主要有 Java 背景，但我对任何语言的示例都感兴趣。

与许多框架一样，ASP.NET 大量使用继承来在类之间共享行为。例如， HtmlInputPassword 具有以下继承层次结构

System.Object
  System.Web.UI.Control
    System.Web.UI.HtmlControls.HtmlControl          // abstract
      System.Web.UI.HtmlControls.HtmlInputControl   // abstract
        System.Web.UI.HtmlControls.HtmlInputText
          System.Web.UI.HtmlControls.HtmlInputPassword

：可以看到具体类的派生示例。

如果您正在构建一个框架 - 并且您确定想要这样做 - 您可能会发现自己需要一个漂亮的大继承层次结构。

Answer 7

其他用例是覆盖默认行为：

假设有一个类使用标准 Jaxb 解析器进行解析

public class Util{

    public void mainOperaiton(){..}
    protected MyDataStructure parse(){
        //standard Jaxb code 
    }
} 

现在假设我想使用一些不同的绑定（比如 XMLBean）进行解析操作，

public class MyUtil extends Util{

    protected MyDataStructure parse(){
      //XmlBean code code 
    }
}

现在我可以使用新的绑定与超类的代码重用。

Answer 8

装饰器模式是一种向类添加额外行为而不使其过于通用的便捷方法，使得大量使用具体类的继承。这里已经提到过，但在某种程度上是“转发包装类”的科学名称。

Answer 9

有很多答案，但我想我自己加 0.02 美元。

我很少重写 concreate 类，但在某些特定情况下。当框架类被设计为可扩展时，至少已经提到了 1。我想到了另外两个例子：

1）如果我想调整具体类的行为。有时我想更改具体类的工作方式，或者我想知道何时调用某个方法，以便我可以触发某些内容。通常，具体类会定义一个钩子方法，其唯一用途是让子类重写该方法。

示例：我们重写了 MBeanExporter，因为我们需要能够取消注册 JMX bean：

public class MBeanRegistrationSupport {
    // the concrete class has a hook defined
    protected void onRegister(ObjectName objectName) {
    }

我们的类：

public class UnregisterableMBeanExporter extends MBeanExporter {
    @Override
    protected void onUnregister(ObjectName name) {
        // always a good idea
        super.onRegister(name);
        objectMap.remove(name);
    }

这是另一个很好的示例。 LinkedHashMap 被设计为具有其removeEldestEntry 方法已被重写。

private static class LimitedLinkedHashMap<K, V> extends LinkedHashMap<K, V> {
    @Override
    protected boolean removeEldestEntry(Entry<K, V> eldest) {
        return size() > 1000;
    }

2) 如果一个类与具体类有大量重叠，除了对功能进行一些调整之外。

示例：我的 ORMLite 项目处理持久的 Long 对象字段和 long原始领域。两者的定义几乎相同。 LongObjectType 提供了描述数据库如何处理的所有方法长字段。

public class LongObjectType {
    // a whole bunch of methods

而 LongObjectType 并且只调整一个方法来处理基元。

public class LongType extends LongObjectType {
    ...
    @Override
    public boolean isPrimitive() {
        return true;
    }
}

希望这有帮助。

Answer 10

1. 如果您想扩展辅助库功能，则只能选择继承具体类。

2. 对于现实生活中的使用示例，您可以查看 DataInputStream 的层次结构

Answer 11

我开始觉得几乎在任何情况下从具体类继承都是合适的。

这就是“几乎”了。尝试编写一个 applet 而不扩展 Applet< /code> 或 JApplet。

这是来自 小程序信息的示例。页面。

/* <!-- Defines the applet element used by the appletviewer. -->
<applet code='HelloWorld' width='200' height='100'></applet> */
import javax.swing.*;

/** An 'Hello World' Swing based applet.

To compile and launch:
prompt> javac HelloWorld.java
prompt> appletviewer HelloWorld.java  */
public class HelloWorld extends JApplet {

    public void init() {
        // Swing operations need to be performed on the EDT.
        // The Runnable/invokeLater() ensures that happens.
        Runnable r = new Runnable() {
            public void run() {
                // the crux of this simple applet
                getContentPane().add( new JLabel("Hello World!") );
            }
        };
        SwingUtilities.invokeLater(r);
    }
}

Answer 12

另一个很好的例子是数据存储类型。举一个精确的例子：红黑树是一种更具体的二叉树，但是检索数据和其他信息（例如大小）可以进行相同的处理。当然，一个好的库应该已经实现，但有时您必须为您的问题添加特定的数据类型。

我目前正在开发一个为用户计算矩阵的应用程序。用户可以提供影响计算的设置。可以计算的矩阵有多种类型，但有明显的相似性，特别是在可配置性方面：矩阵 A 可以使用矩阵 B 的所有设置，但具有可以使用的附加参数。在这种情况下，我从 ConfigObjectB 继承了 ConfigObjectA，并且效果非常好。

Answer 13

一般来说，从抽象类继承比从具体类继承更好。具体类必须为其数据表示提供定义，并且某些子类将需要不同的表示。由于抽象类不必提供数据表示形式，因此未来的子类可以使用任何表示形式，而不必担心与它们继承的表示形式发生冲突。
即使我也从未发现过需要具体继承的情况。但在某些情况下可能需要具体继承，特别是当您为软件提供向后兼容性时。在这种情况下，您可能已经专门化了一个 A 类，但您希望它是具体的，因为您的旧应用程序可能正在使用它。

Answer 14

由于您所说的原因，您的担忧也在经典原则“优先考虑组合而不是继承”中得到了回应。我不记得上次从具体类继承是什么时候了。任何需要被子类重用的公共代码几乎总是需要为这些类声明抽象接口。按照这个顺序，我尝试更喜欢以下策略：

1. 组合（无继承）
2. 接口
3. 抽象类

从具体类继承确实不是一个好主意。

[编辑] 我将通过说当您控制架构时我看不到它的良好用例来限定此声明。当然，当使用需要它的 API 时，该怎么办？但我不明白这些 API 所做的设计选择。调用类应该始终能够根据依赖倒置原则声明和使用抽象。如果子类有其他要使用的接口，您要么必须违反 DIP，要么进行一些丑陋的转换才能获取这些接口。

Answer 15

来自 gdata 项目：

com.google.gdata.client.Service 旨在充当基类，可以针对特定类型的 GData 服务进行定制。

Service javadoc：

Service 类表示与 GData 服务的客户端连接。它封装了与 GData 服务器的所有协议级交互，并充当更高级别实体（提要、条目等）的帮助程序类，这些实体调用服务器上的操作并处理其结果。

此类提供访问任何 GData 服务所需的基本级别通用功能。它还被设计为充当基类，可以针对特定类型的 GData 服务进行自定义。 支持的自定义示例包括：

身份验证 - 为需要身份验证并使用 HTTP 基本或摘要身份验证以外的内容的服务实现自定义身份验证机制。

扩展 - 定义与服务关联的提要、条目和其他类型的预期扩展。

格式 - 定义可能由服务和客户端解析器和生成器使用或生成的其他自定义资源表示形式来处理它们。

Answer 16

我发现 java 集合类是一个很好的例子。
所以你有一个 AbstractCollection 和像 AbstractList、AbstractSet、AbstractQueue 这样的子项...
我认为这个层次结构设计得很好……为了确保不会发生爆炸，有 Collections 类及其所有内部静态类。

Answer 17

例如，您可以在 GUI 库中执行此操作。从单纯的组件继承并委托给面板没有多大意义。直接从Panel 继承可能要容易得多。

Answer 18

只是一个一般的想法。抽象类缺少一些东西。如果每个派生类中缺少的内容都不同，那就有意义了。但您可能会遇到这样的情况：您不想修改类，而只想添加一些内容。为了避免重复代码，您将继承。如果您需要这两个类，那么它将是从具体类的继承。

所以我的答案是：在所有情况下，你真的只想添加一些东西。也许这种情况并不经常发生。