Pattern to initialize base class in derived class constructor (or factory)

Question

Imagine you have a derived class, where the base class is something you cannot modify. The base class has a lot of state (many non-constant private members) and many constructors, with varying numbers of arguments to initialize some subset of the state (the size of the subset varies by constructor, of course).

Now my derived class is a very lightweight wrapper over the base class. Let's assume it adds no state of its own, and only slightly modifies the behavior of a couple methods (perhaps doing some additional logging around a super.originalMethod() call).

The issue I have is that I want to take an object of the base class, and create a "copy" of it, with the same state, but as an instance of my derived class.

This is proving difficult. I can't call the "most complete" constructor of the base class, passing all the state from the source by calling getters, since depending on how the base class was constructed, some of the state values may be rejected by this constructor. For example, you can create a default object with a 0-arg ctor, any many values will be null. It is not, however, legal to pass null values in the ctor that allows you to specify these values.

Furthermore, the method above is fragile because if a modification to the base class occurs which adds more state, and "even more complete" constructor (or state which can't be set in a constructor, but only through accessor methods) is added, the copy won't be complete any more.

What I want is like `clone(), but rather initializing a new object of the same type, initialize the base class members of the derived class. I guess such a thing doesn't exist. Any suggestions on a pattern that might offer something equivalent?

Keep in mind I cannot modify the base class. If I could, this would be much easier.

Answer 1

If you can override all public methods, you can save the source object as the delegate

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

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

Answer 2

Favour composition over inheritance, perhaps by creating a wrapper class (as below). If your base class utilizes interfaces, your wrapper class can implement the same interfaces and delegate calls to the base class (decorator).

However, there is no robust strategy to do as you describe with inheritance. Even if you used reflection to perform a deep copy, as you pointed out, the implementation may change. You have broken encapsulation and your code would be intimately coupled with the base class.

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

As others have noted, it's natural to think of solving this by using delegation and implementing it as a proxy or decorator. The standard ways of dealing with these patterns require that you have an interface rather than a concrete class at the base, as does Java's dynamic proxy.

However, you can accomplish similar things with concrete classes using cglib or javassist.

With sufficient runtime JVM tinkering, perhaps through one of the above, or with AspectJ, I think you can even make your existing class implement a newly defined interface.

Hibernate creates proxies for all persistent classes without requiring that they implement an interface, and I believe it uses cglib to do this.

Answer 4

I notice some people are recommending you use both composition and inheritance (see below for an example of this anti-pattern).

Please do this only as a last resort. In addition to introducing redundant state, your child object will expose state and behaviour that is completely ignored. This will lead to a very misleading 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);
    }
}

EDIT: Actually, just don't do this. Ever. It's a horrible, horrible strategy. If you fail to manage all interaction with base-class state (which again, makes it a very brittle solution) then very bad things will occur. For example, if I modify base class as follows:

private static class Base {

    ...

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

    ...
}

Oh dear...

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

This looks like a job for Proxy. (Probably if you google, you can find a better proxy implementation, but the standard one is in my opinion good enuf.)

Implemnet an InvocationHandler like this

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

If the base class doesn't provide built-in support for cloning, there isn't any really good way. IMHO, if the right pattern is to divide classes into three categories:

-1- Classes which fundamentally cannot be meaningfully be cloned, by any means, without breaking class invariants.

-2- Classes which can be cloned without breaking class invariants, but which may be used to derive other classes which cannot meaningfully be cloned.

-3- Classes which can be cloned, and which will only be used to derive classes which can likewise be cloned.

Classes of type -2- or -3- should provide a protected virtual cloning method which will call the parent's implementation (if their is one), or Object.Clone (if there isn't a parent implementation) and then do any class-specific cleanup. Classes of type -3- should provide a public cloning method which will call the virtual method and typecast the result to the proper type. Inheritable classes of type -1- which derive from those of type -2- should shadow the protected cloning method with something other than a function.

If there's no way to add a protected cloning method into the parent class, there's no way to construct a cloneable derived class which won't be brittle with regard to parent-class implementation details. If a parent class is constructed according to the above pattern, though, cloning will be implementable cleanly in derived classes.

Answer 7

I don't think you're going to be able to assign it that way at all, due to the way that inheritence works. Let's say that your base class is of type "A". You create your wrapper class of type "B". You can assign an instance of "B" to type "A", but you cannot assign an instance of "A" to type "B".