I have a behavior tree with different leaf nodes that execute tasks. When building out the tree relationship in the database I need an association between the leaf node entry and the Java class that will actually perform the task execution. I've seen some examples that store the canonical name of the Java task class with the leaf node data, and then instantiate the class at runtime using reflection. I'm not sure I like that approach, but I'm looking for all of the alternatives so I can make an informed decision.

1 Answer 1


You can use JPA with inheritance.

There are several variations ("patterns"):

  • all objects share the same table and there is a "discriminant" column/attribute (this is the closest to the one you explain). It is quick for queries, but you will have a column for each attribute of a subclass (if you have 20.000 instances, and only two instances of a subclass that defines attribute "x", you will have 20.000 rows where attribute 'x' is implemented as a null column. And it is more difficult to enforce that, when the instance is of the given subclass, the attribute may not be null (you would require a programmed constraint).

  • each subclass has a different subclass (good if subclasses have lots of different attributes, but implies joins when querying the DB).

  • one table is used for common attributes, there are tables for attributes specific to subclasses (this is a hybrid of the other two).

The advantage is that it is standard, and you forget about how to persist/retrieve the data, the JPA already does it for you.

The disavantage is that it is a full API and you should learn how it does manage relationships(including cascading and/or lazy loading), JPQL/Criteria, etc.

  • What would be stored in the discriminant column, or tables with specific attributes? I don't have additional state to load. It really is just a different implementation. I guess I'm asking what that "identity" would be, and how I might initialize and cache the instance (in a theoretical sense).
    – user9483
    Jan 25, 2015 at 20:18
  • 1
    In the discriminant column there is a value that allows JPA identify the specific subclass. For MyClass, you may define it as "X1", for MySubclass, "X2"... The value in the database would tell JPA if, when retrieving the data, it needs to new MyClass or new MySubclass. In the more extreme situation, you could use the entire name of the class as discriminant and end with the same table you would get with your first proposal (but of course, shorter codes may be quicker/more readable).
    – SJuan76
    Jan 25, 2015 at 20:23
  • 1
    If you do not have state, it seems an example of the strategy pattern. You could still use JPA for that, but using enum. That enum would be a property of the actual "entity" (which would be the nodes or leafs of the tree).
    – SJuan76
    Jan 25, 2015 at 20:26
  • Very cool. In JPA I'm used to associating a single entity with a single table, but once I researched the JPA discriminant column like you described it makes perfect sense. I think an enum is the best way to identify the implementation. Basically a TaskType relationship table. Does that sound like what you were giving as an example?
    – user9483
    Jan 25, 2015 at 20:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.