java - 像接口(interface)一样使用第三方抽象类？

Question

在我使用的第 3 方库中，有以下层次结构:

public abstract class Foo
{
    // Class is public in the Java sense and public in the library's API
}

public class FooImpl extends Foo
{
    // While this class is public in the Java sense, it is
    // NOT part of the public API and is not even documented
    // Library functions that hand back instances of this class
    // hand them back as type Foo
}

库中的各种方法对Foo 类型的事物进行操作。 Foo 文档说用户可以扩展 Foo 以进行具体实现，并且(显然)库提供了具体实现。

我对库提供的实现很满意，除了一种方法，我想稍微改变一下它的行为。但是我所提供的层次结构让我感到困惑。

如果 Foo 是一个接口(interface)(它不是!)，我会这样做:

public FooWrapper implements Foo
{
    private Foo wrappedImpl;

    public FooWrapper(Foo toBeWrapped) {
        wrappedImpl = toBeWrapped;
    }

    List<Whatever> methodIWantToTweak() {
        List<Whatever> list = wrappedImpl.methodIWantToTweak();
        do_something_to_list(list);
        return list;
    }

    Something methodThatsOk() {
        return wrappedImpl.methodThatsOk();
    }

    // similar delegations for remaining methods
}

但由于它不是一个界面，我不能这样做，或者至少不能干净利落地做到这一点。

我唯一能想到的是:

1) 扩展 API 非公共(public)类 FooImpl 并覆盖我想要调整的方法。

2) 做类似的事情:

public class FooWrapper extends Foo
{
    private Foo wrappedImpl;

    public FooWrapper(Foo toBeWrapped) {
        super();
        wrappedImpl = toBeWrapped;
    }

    List<Whatever> methodIWantToTweak() {
        List<Whatever> list = wrappedImpl.methodIWantToTweak();
        do_something_to_list(list);
        return list;
    }

    Something methodThatsOk() {
        return wrappedImpl.methodThatsOk();
    }

    // Override all non-final public, protected, and package-local
    // methods and delegate them to wrappedImpl
}

这两种方法对我来说都很糟糕。第一个问题是它依赖于一个它不应该知道的类，并且在库的 future 版本中可以更改/消失/重命名。第二个问题是 FooWrapper 的父类(super class)部分实际上没有被使用，并且不可能覆盖 Foo 的任何最终或私有(private)方法(这会导致问题在这些情况下，无法委托(delegate)给 wrappedImpl)。

我想我必须采用第一种方法，因为至少它会给出正确的行为，而第二种方法可能会以潜在的邪恶、微妙的方式被破坏，具体取决于 Foo< 的内部细节.

那我是不是运气不好？我还忽略了哪些其他方法/想法？

Answer 1

如果您不需要覆盖任何 Foo 的 final 或 protected(见下文)方法，我会采用第二种方法:对待 Foo作为一个界面，然后做你在那种情况下会做的事情。优点是您不依赖于可以更改的 FooImpl。

Foo 的

final 和 private 方法不是问题，因为您无法覆盖 FooImpl< 中的那些方法 或者如果 Foo 是一个接口(interface)，无论如何。另外，我认为你的意思是 protected 而不是 private。

如果您确实需要覆盖protected 方法，您将需要采用第一种方法。