How to extends a class at runtime?

[alex]

I don't know whether the subject is proper, sorry for any confusion.

Now, I have a class A, which is not controlled myself and I can only
get an instance of it at runtime. However, I want to do some adapter
work to it, such as altering its interface.
My solution is using the instance of A as a constructor parameter of a
new adapter class B, for example:

class B {
private A a;
public B(A aa) {
a = aa;
}
/* adapter stuff here ... */
}

Of course, it works. But I am now wondering whether there is a
solution using inheritance instead of composition? Is there any
pattern or trick?

Any answer or hint will be appreciated, thanks.

 

[Roedy Green]

I don't know whether the subject is proper, sorry for any confusion.

You can compose programs on the fly, compile, and load them.
see http://mindprod.com/jgloss/onthefly.html

 

[Lew]

I don't know whether the subject is proper, sorry for any confusion.

Now, I have a class A, which is not controlled myself and I can only
get an instance of it at runtime. However, I want to do some adapter
work to it, such as altering its interface.
My solution is using the instance of A as a constructor parameter of a
new adapter class B, for example:

class B {
private A a;
public B(A aa) {
a = aa;
}
/* adapter stuff here ... */
}

Of course, it works. But I am now wondering whether there is a
solution using inheritance instead of composition? Is there any
pattern or trick?

Most of the time you're going to be better off composing a wrapper class than
extending the target class. This is true even when you control the source.

As an example, consider Collections.unmodifiableCollection( Collection <?
extends T> c). It works by extending the Collection interface, but by
wrapping the target object rather than trying to dynamically extend the target
object's actual class. This has a host of advantages - the resulting
collection need not try to handle, say, List-specific methods even though
object c might be a List, and of course, it's a lot faster, shorter and safer
than trying to dynamically re-extend the class of 'c'.

So even if you are extending, you can also compose. You can extend, in your
example, class or interface A with B, but still compose around an instance of
A internally. That way you aren't dynamically creating classes but have one
created the usual way, with source code and all that.

 

[alex]

Most of the time you're going to be better off composing a wrapper class than
extending the target class. This is true even when you control the source.

As an example, consider Collections.unmodifiableCollection( Collection <?
extends T> c). It works by extending the Collection interface, but by
wrapping the target object rather than trying to dynamically extend the target
object's actual class. This has a host of advantages - the resulting
collection need not try to handle, say, List-specific methods even though
object c might be a List, and of course, it's a lot faster, shorter and safer
than trying to dynamically re-extend the class of 'c'.

So even if you are extending, you can also compose. You can extend, in your
example, class or interface A with B, but still compose around an instance of
A internally. That way you aren't dynamically creating classes but have one
created the usual way, with source code and all that.

Thanks, this is a valuable suggestion. I'll look into
unmodifiableCollection now.

 

[Ian Shef]

My apologies for replying over Lew's response, I missed the original post
which is now gone from my server.

As Lew pointed out, composition may be a better answer than inheritance.
However, if you want to try a form of runtime inheritance, you could try
using dynamic proxies. See the javadocs for java.lang.reflect.Proxy

If you need help with this, you can get explanations and examples in
"Java Reflection in Action" (In Action series) by Ira R. Forman and Nate
Forman.

java.lang.reflect.Proxy requires that your class A have a defined
Interface.
"Java Reflection in Action" hints at how to get around this limitation.
You may have to see the book's web site (I did) for a better hint at how to
get around this limitation.

Caveat 1: I have no connection to this book except as a purchaser/reader.
Caveat 2: After studying this book, you may see reflection as the answer
to all problems. It isn't. However, the book can be helpful for those
cases where reflection is needed.

 

[Mark Space]

My apologies for replying over Lew's response, I missed the original post
which is now gone from my server.

That's because the original, and Lew's response is almost two months old.

Thread says "braaaaaaaaaains....."