从一个具体的类继承的好例子吗？[关闭]

Question 1

背景：

作为Java程序员，我广泛地从接口继承（而不是：实现），有时我设计抽象基类。但是，我从来没有真正感到有必要将具体的（非抽象的）类作为子类（在我这样做的情况下，后来证明了另一种解决方案，例如委托会更好）。

因此，现在我开始感到几乎没有任何情况可以从具体类进行继承。一方面，对于非平凡的类，李斯科夫替换原理（LSP）似乎几乎是无法满足的。还有许多其他问题，这里似乎呼应了类似的意见。

所以我的问题是：

在哪种情况下（如果有）从具体类继承实际上有意义吗？您能否举一个从另一个具体类继承来的类的实际实例，在这种情况下，您认为这是受限制的最佳设计？我对满足LSP的示例（或满足LSP似乎不重要的示例）特别感兴趣。

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

Question 2

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

一个示例是转发包装器类，以便能够转发到C实现的具体类的另一个对象I，例如，无需继承自即可进行修饰或简单的代码重用。您可以在“有效的Java”项目16中找到这样的示例，青睐于组合而不是继承。（由于版权原因，我不想将其发布在这里，但实际上只是将所有方法调用转发给包装的实现）。CCI

Question 3

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

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

Question 4

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

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

Question 5

一般而言，我从具体类派生的唯一时间是它们在框架中。源自Applet或JApplet成为琐碎的例子。

Question 6

这是我正在执行的当前实现的示例。

在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...
}

因此，我可以将两者都返回，而最终用户则是最明智的选择。:-)

简介：如果您希望自定义类具有与具体类相同的功能，而又不更改具体类的结构，则建议扩展具体类。

Question 7

我主要有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

在其中可以看到派生具体类的示例。

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

Question 8

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

可以说有一个使用标准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 
    }
}

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

Question 9

该装饰图案，添加额外的行为一类没有使它过于笼统的一个方便的方式，大量使用了具体类的继承。它已经在这里提到过，但是在某种科学上叫“转发包装类”。

Question 10

答案很多，但我虽然会加上自己的$ 0.02。

我不经常重写concreate类，但是在某些特定情况下。在设计框架类以进行扩展时，至少已经提到了1种。我想到了另外两个例子：

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

示例：我们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提供描述数据库如何处理long字段的所有方法。

public class LongObjectType {
    // a whole bunch of methods

whileLongType覆盖LongObjectType并且仅调整一个单一的方法来处理原语。

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

希望这可以帮助。

Question 11

如果您想扩展侧库功能，则继承混凝土类是唯一的选择。
例如，在现实生活中，您可以查看DataInputStream的层次结构，该层次结构为FilterInputStream实现了DataInput接口。

Question 12

我开始感到几乎没有任何情况可以从具体类进行继承。

这是一个“几乎”。尝试写一个小程序不扩展Applet或JApplet。

这是来自applet信息的例如。页面。

/* <!-- 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);
    }
}

Question 13

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

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

Question 14

通常，从抽象类继承比从具体类继承更好。具体的类必须为其数据表示提供定义，而某些子类将需要不同的表示。由于抽象类不必提供数据表示形式，因此将来的子类可以使用任何表示形式，而不必担心与它们继承的表示形式发生冲突。甚至我从来没有发现我觉得需要具体继承的情况。但是，在为软件提供向后兼容性时，尤其是在某些情况下可能会产生具体继承。在那种情况下class A，您可能有一个专门的a，但是您希望它是具体的，因为您的旧应用程序可能正在使用它。

Question 15

出于您所说的原因，经典原则“偏重于继承而不是继承”也表达了您的担忧。我不记得我上次从一个具体的类继承过来的事情。子类需要重用的任何通用代码几乎总是需要为这些类声明抽象接口。按照这种顺序，我尝试采用以下策略：

组成（无继承）
接口
抽象类

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

[编辑]我将通过声明这种陈述来限定您的发言权，即当您控制该体系结构时，我认为它没有很好的用例。当然，当使用期望的API时，whaddaya会做什么？但是我不理解这些API所做的设计选择。调用类应始终能够根据依赖关系反转原理声明和使用抽象。如果子类有其他接口要使用，则必须违反DIP或进行一些丑陋的转换才能获得这些接口。

Question 16

来自gdata项目：

com.google.gdata.client.Service设计为充当基类，可以针对特定类型的GData服务进行自定义。

服务javadoc：

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

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

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

扩展-为Feed，条目和与服务相关联的其他类型定义期望的扩展。

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

Question 17

我发现java集合类是一个很好的例子。因此，您有一个AbstractCollection，其子类如AbstractList，AbstractSet，AbstractQueue ...我认为此层次结构已经过精心设计..为了确保不爆炸，存在具有内部所有静态类的Collections类。

Question 18

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

Question 19

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

所以我的答案是：在所有情况下，您实际上只想添加一些内容。也许这种情况并不经常发生。