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.

That's true. The downside is that class D has useless (always null/default) members in that case. Pretty interesting though, and it gets around the doesn't implement interface problem of hoipolloi's answer.
–
BeeOnRopeJul 22 '11 at 2:32

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.

Yes, I would have definitely implemented this proxy pattern if I could. Unfortunately, the base class that I am deriving from is the public API, and doesn't implement any interesting interface that I can implement. That is, I need my object to be an instance of the base type, since I must use it as such in methods that I cannot change.
–
BeeOnRopeJul 22 '11 at 2:29

@BeeOnRope: If you are at the mercy of a poorly designed framework then I think you are out of luck. There are solutions, but they are brittle and will not sustain an API change in the superclass.
–
hoipolloiJul 22 '11 at 2:33

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.

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:

Agree, but sometimes your hands are tried to the structure of the existing code. In the end, I found that I could override the whole class in question by including my .class earlier in the classpath, so this lets me patch the behavior in a slightly less hacky way.
–
BeeOnRopeJul 29 '11 at 22:27

... but I'm still going to accept that answer since it's only one that I can see that works with the constraints given.
–
BeeOnRopeJul 29 '11 at 22:27

@BeeOnRope: It's a sorry state of affairs when classpath shenanigans are considered a 'less hacky way'! It sucks when our hands are tied though. Out of interest, what framework are you trying to work with? Good luck!
–
hoipolloiJul 29 '11 at 22:58

Well in this case it's less hacky in that it enables me to completely replace the class in question, rather than simply extend it. When I extend it, I need to search for every creation site of the base type (since no consistent factory pattern is used) and modify it to create my derived class. This is very fragile, obviously. With complete replacement, I don't need to worry about this at all, so I consider that less hacky and less prone to (silent) problems later. Library in question is Quartz.
–
BeeOnRopeAug 2 '11 at 7:59

Unfortunately this only works if I wanted to implement an interface in terms of the base class - here I need to implement the base class directly.
–
BeeOnRopeJul 22 '11 at 2:42

Then I think you want commons.apache.org/proxy. It is in my humble opinion better than the other options, because you can treat the original object and its base class like a black box. You don't need to know anything about its internal workings - (1) less implementation work for you; (2) if the base class changes, the proxy handles all of that.
–
emoryJul 22 '11 at 18:30

@emory: it introduces unnecessary complexity and dependencies if the OP can get away with using composition. Otherwise, I agree, it does seem to represent an elegant solution (far better than the composition AND inheritance work-around).
–
hoipolloiJul 24 '11 at 2:15

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.

There is an accessible clone() method in the base class, but I don't want to clone the base class, but rather I want to create a derived class with the same base class state as a given base class (not a given derived class).
–
BeeOnRopeJul 23 '11 at 20:11

If the base class's clone method uses Object.Clone to create the new object, then calling it upon a derived-class object will create a new derived class object. If the people who created the base class clone method used a copy constructor instead, the only way to create a clone the state of a derived-class object is to re-implement the guts of the copy constructor yourself.
–
supercatJul 24 '11 at 5:46

Sure, but I don't see how this is relevant to the problem at all. I have an object with type BaseClass, call it b, with an accessible clone() method. I want to create an object of type DerivedClass, whose BaseClass state is the same as the b object. How does clone() help? I can't call it on b since I will get an object of type BaseClass. I can't call it on any instance of the derived class, since non exists (with the state that I want).
–
BeeOnRopeJul 25 '11 at 22:23

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".