views:

537

answers:

3

I have a class hierarchy like so: (=> means "is a subclass of")

anonymous instance class => abstract class => generic abstract class

or more succinctly:

C => B => A

When executing, "C" calls one of "A"'s methods. Within that method in "A", I want to use reflection to find protected fields of the object that are defined in class "B". (So these are fields that "C" and "B" can see, but not "A".)

How would I do this with Java reflection? And how can I future-proof it in case I add something between A & B or B & C?

+1  A: 
Field[] fields = getClass().getSuperclass().getDeclaredFields();

And then iterate those fields and get the ones you want.

In case your hierarchy grows, you can transform the above to a recursive calls to getSuperclass() (while getSuperclass() != Object.class), thus collecting all fields of all superclasses.

Bozho
OK, just to make sure I am not crazy - did I completely misread his question? Or is he in fact asking how a parent class would find a method on a child class? Because your method would work if he was asking about methods on the parent class, but I am reading that he is asking the opposite.
aperkins
@aperkins,this should work with methods of the child class too, because the getClass() will return the actual class of the Object at runtime (A) the getSuperclass() will then return the class (B), but it is not future-proof.
josefx
Yeah, I realized that after I thought about it. It is too early in the morning, and the winter crud is killing my brain. At least, that is my excuse, and I am sticking to it. :) I updated my answer appropriately. Thanks for the response.
aperkins
+5  A: 

You have to use getDeclaredFields() repeatedly on each class in the inheritance hierarchy of your object's class (via getSuperclass()).

However, what you are planning sounds like a nasty violation of the concept of inheritance. The best way of future-proofing would be to avoid this kind of thing entirely. What are you trying to do that you think requires such reflection shenanigans?

Michael Borgwardt
+1 because of your second paragraph - I agree completely.
aperkins
First I was pissed off. Then I tried to explain what my purpose was, but couldn't without discussing the whole problem. Then I got more pissed off. Then as I was laying my son to sleep, I saw that my problem could be solved much more cleanly without reflection by having the super class create the child objects and store them locally. Thanks for the kick in the pants.
roufamatic
A: 

As far as I know, there is no way to know about your "child classes" in Java reflectively. Wouldn't a better solution be to create an abstract method on A that B would have to implement, and call that instead?

public class A {
   //other stuff here
   protected void abstract mySubMethod();
   //other stuff here
}

Edit: If I have misunderstood your question, and you actually want to know about parent classes, then yes: getDeclaredFields() is the correct reflective method to use, as mentioned by other posters.

Additional Edit: I hate to keep modifying this answer, but... In general, if you are attempting to give access to a parent class, the "correct" and "future proof" way to do this is to create abstract methods that are getters or setters (or even more complex, if necessary) and then have the children honor those or not, and respond as appropriate.

That being said, you can do something like the others have said:

getClass().getParentClass().getDeclaredFields()

However, that would only work if C is always directly inherited from B. Reflections is, by it's very nature, tricky and specific. I have to do a LOT of it on a project I am on (don't ask, trust me, you DON'T want to know), and I avoid it whenever possible. Unless there is a good reason for A to need the protected fields and it is discovering information about them, then you would likely want to use an abstract method. I would also submit that it is likely that you can solve the other problem with an abstract method, however it might be a little bit harder.

aperkins