Junilu Lacar wrote:So, if you only care about certain fields that you want to explicitly list out, why use reflection? That's the smell. Using reflection to exclude specific fields makes sense because you won't have to change the code if that exclusion list doesn't change but the objects are modified to include more fields that should be checked. In your case, it doesn't make sense to use reflection because you want to list fields to include. If that list changes, you'll still have to change the code. You gain nothing by using reflection. Since reflection is costly, you're paying for a service that is of no practical use to you in the context of the problem you're trying to solve. That's like paying for premium cable channels that you don't ever watch. So what's the point?
Jesper de Jong wrote:What Tushar posted probably works, but it looks more complicated than necessary. The Spring ApplicationContext has a method to do exactly what you want: getBeansWithAnnotation.
It returns a Map in which the keys are bean names and the values are bean instances.
Stephan van Hulst wrote:If your external type follows the JavaBeans conventions, you can use an existing Hamcrest matcher. Sadly, the matcher is type-safe, so it's easiest to wrap it in a method call that takes all kinds of objects:
You then call it like this:
[To give a concrete example of that generation gap issue, let's say you call addRelationship(joe, grandson, peter). First of all, it's not very clear how to read this: is Joe the grandfather or grandson? Before you answer that, again that's the point. Somebody needs to tell you or you have to go look at the documentation and if there is none, you have to dig through the source code. This design makes the API ambiguous and unintuitive. This could be read as either "Joe is the grandson of Peter" or "Joe's grandson is Peter."
So, with just that one call you have created a generation gap because no intermediate relationship has been defined. Where is the grandparent's child who is the parent of the grandchild? That is, if Joe is the grandfather, then where is Joe's child who is Peter's parent?
Just posting this to try to articulate the picture I have in my head.
I'm looking at the Tree concept somewhat like an Iterator, as an abstraction and a "lens" to an underlying set of data. It's from the idea that Campbell gave about a Person having two trees, one for parents, another one for offspring. That's where the idea of using two different "lenses" came where I could go to a Person and ask him for a Tree view where that person has a child role or for others where they are have the parent role, or at least are part of a couple that makes up a Parent node. The Tree would then allow me to access the Parent and Child nodes directly and I can recurse from there. That's why the Role enum, if I found that it was really necessary, would have only Parent, Child, and possibly Sibling but probably not, as its values.
From a Parent or Child node, I can traverse the underlying collection by moving between Child and Parent nodes and invoking a relatively small API (getParentTree(), getChildTree(), getChildren(), getParent(), hasMother(), hasFather(), hasChild()) on the Tree/Node interface. Visitor pattern and the Strategy pattern are already vaguely creeping into the design picture at this point.
As I move from one person to another asking for one Tree view or another, I am able to move from person to person, child to parent and vice versa. This can all be done recursively or iteratively if you don't like recursion. The notion of the Akka-esque Root parent node comes in very handy in stopping the recursive or iterative traversal and of course when a Parent node (representing a couple) has no Child nodes, the recursion stops with the childless couple as well.
Now where Dave's Event idea comes in is that once the biological connections have been made, you can layer on the event-related connections. Say Bill and Sue adopted a child named Jim. Jim gets added to a Child of the "Bill & Sue" Parent node with an "adoption event" marker. Bill cheats on Sue and has a child with Mary so now Bill and Mary become a couple in Parent node with a Child node that represents their love child, Connie.
With the combination of Couple/Parent/Child connections and Event markers, I think I can come up with something that reflects what happens when the guy in the song becomes his own grandpa.