在派生类构造函数（或工厂）中初始化基类的模式

Question

假设您有一个派生类，其中基类是您无法修改的。基类具有许多状态（许多非常量私有成员）和许多构造函数，具有不同数量的参数来初始化状态的某些子集（当然，子集的大小因构造函数而异）。

现在我的派生类是基类的一个非常轻量级的包装器。我们假设它没有添加自己的状态，并且仅稍微修改了几个方法的行为（可能围绕 super.originalMethod() 调用进行一些额外的日志记录）。

我遇到的问题是，我想获取基类的一个对象，并创建它的“副本”，具有相同的状态，但作为派生类的实例。

事实证明这很困难。我无法调用基类的“最完整”构造函数，通过调用 getter 从源传递所有状态，因为根据基类的构造方式，某些状态值可能会被此构造函数拒绝。例如，您可以创建一个带有 0-arg 构造函数的默认对象，任何多个值都将为 null。但是，在允许您指定这些值的构造函数中传递空值是不合法的。

此外，上面的方法很脆弱，因为如果对基类进行修改，会添加更多状态，并且添加“甚至更完整”的构造函数（或无法在构造函数中设置的状态，而只能通过访问器方法设置），副本将不再完整。

我想要的是像`clone()，而是初始化相同类型的新对象，初始化派生类的基类成员。我想这样的事情是不存在的。关于可能提供同等功能的模式有什么建议吗？

请记住，我无法修改基类。如果我可以的话，这会容易得多。

Answer 1

如果可以重写所有公共方法，则可以将源对象保存为委托

Class D extends B
    B src;
    D(B src){ super(whatever); this.src=src; }

    public method1(){ src.method1(); }

Answer 2

优先考虑组合而不是继承，也许可以通过创建包装类（如下所示）。如果您的基类使用接口，则您的包装类可以实现相同的接口并将调用委托给基类（装饰器）。

但是，没有像您所描述的继承那样的稳健策略。即使您使用反射来执行深层复制，正如您所指出的，实现也可能会发生变化。您已经破坏了封装，并且您的代码将与基类紧密耦合。

public static void main(final String[] args) {
    final Base base = new Base("Hello");
    base.printState(); // Prints "Hello"
    final Wrapper wrapper = new Wrapper(base);
    wrapper.printState(); // Prints "Wrapper says Hello"
    wrapper.clone().printState(); // Prints "Wrapper says Hello"
}

private static class Wrapper {

    private final Base base;

    public Wrapper(final Base base) {
        this.base = base;
    }

    public Wrapper clone() {
        return new Wrapper(base);
    }

    public void printState() {
        System.out.printf("Wrapper says ");
        base.printState();
    }
}

private static class Base {

    private Object state;

    public Base(final Object state) {
        if (state == null) {
            throw new IllegalArgumentException("State cannot be null");
        }
        this.state = state;
    }

    public void printState() {
        System.out.println(state);
    }
}

Answer 3

正如其他人所指出的，很自然地会想到通过使用委托并将其实现为代理或装饰器来解决这个问题。处理这些模式的标准方法要求您有一个接口，而不是像 Java 的动态代理那样在基础上有一个具体的类。

但是，您可以使用 cglib 或 cglib 来通过具体类完成类似的事情。 jboss.org/javassist" rel="nofollow">javassist。

通过足够的运行时 JVM 修补，也许通过上述之一，或者使用 AspectJ，我认为你甚至可以使您现有的类实现新定义的接口。

Hibernate 为所有持久类创建代理，而不要求它们实现接口，我相信它使用 cglib 来做到这一点。

Answer 4

我注意到有些人建议您同时使用组合和继承（请参阅下面的反模式示例）。

请将此作为最后的手段。除了引入冗余状态之外，您的子对象还将公开完全被忽略的状态和行为。这将导致 API 极具误导性。

public static void main(final String[] args) {
    final Base base = new Base("Hello");
    base.printState(); // Prints "Hello"
    final Wrapper wrapper = new Wrapper(base);

    wrapper.changeState("Goodbye");

    wrapper.printState(); // Prints "Wrapper says Hello"
    wrapper.clone().printState(); // Prints "Wrapper says Hello".

    // It seems my state change was completely ignored. What a confusing API...
}

private static class Wrapper extends Base {

    private final Base base;

    public Wrapper(final Base base) {
        super("Make something up; this state isn't used anyway");
        this.base = base;
    }

    public Wrapper clone() {
        return new Wrapper(base);
    }

    public void printState() {
        System.out.printf("Wrapper says ");
        base.printState();
    }
}

private static class Base {

    private Object state;

    public Base(final Object state) {
        if (state == null) {
            throw new IllegalArgumentException("State cannot be null");
        }
        this.state = state;
    }

    public void changeState(final Object state) {
        this.state = state;
    }

    public void printState() {
        System.out.println(state);
    }
}

编辑：实际上，不要这样做。曾经。这是一个非常非常可怕的策略。如果您无法管理与基类状态的所有交互（这又使其成为一个非常脆弱的解决方案），那么将会发生非常糟糕的事情。例如，如果我按如下方式修改基类：

private static class Base {

    ...

    // A new method
    public Object getState() {
        return state;
    }

    ...
}

哦天哪......

final Wrapper wrapper = new Wrapper(new Base("Foo"));
System.out.println(wrapper.getState()); // Prints "Make something up; this state isn't used anyway"

Answer 5

这看起来像是 Proxy 的工作。 （也许如果你用谷歌搜索，你可以找到更好的代理实现，但我认为标准的代理实现已经很不错了。）

Implemnet 和 InitationHandler 像这样

class Handler implements InvocationHandler
{
    private Thingie thingie ;

    public Handler ( Thingie thingie )
    {
        this . thingie = thingie ;
    }

    public Object invoke ( Object proxy , Method method , Object [ ] args ) thro
ws Throwable
    {
        if ( method . getName ( ) . equals ( "target" ) )
            {
                LOG . log ( this ) ;
            }
        return method . invoke ( this . thingie , args ) ;
    }
}

Answer 6

如果基类不提供对克隆的内置支持，则没有任何真正好的方法。恕我直言，如果正确的模式是将类分为三类：

-1-从根本上讲，在不破坏类不变量的情况下，无论如何都无法有意义地克隆的类。

-2- 可以在不破坏类不变量的情况下克隆的类，但可用于派生无法有意义地克隆的其他类。

-3- 可以克隆的类，并且仅用于派生同样可以克隆的类。

-2- 或 -3- 类型的类应提供受保护的虚拟克隆方法，该方法将调用父级的实现（如果它们是一个），或 Object.Clone （如果没有父级实现），然后执行任何类-具体清理。 -3- 类型的类应该提供一个公共克隆方法，该方法将调用虚拟方法并将结果类型转换为正确的类型。从类型 -2- 派生的类型 -1- 的可继承类应该使用函数以外的其他内容来隐藏受保护的克隆方法。

如果无法将受保护的克隆方法添加到父类中，则无法构造可克隆的派生类，该派生类在父类实现细节方面不会变得脆弱。但是，如果根据上述模式构造父类，则可以在派生类中干净地实现克隆。

Answer 7

由于继承的工作方式，我认为您根本无法以这种方式分配它。假设您的基类是“A”类型。您创建类型“B”的包装类。您可以将“B”的实例分配给类型“A”，但不能将“A”的实例分配给类型“B”。