Question

I have some Entities that look like this:

@Entity
public abstract class AbstractEntity{

    @Id
    private Long id;
    String name;
    User author;
    @Lob
    byte[] data;

}


public class EntityOne extends AbstractEntity{
    // nothing new
}


public class EntityTwo extends AbstractEntity{
    // nothing new
}


public class EntityThree extends AbstractEntity{
    // nothing new
}

The byte[] defined in the superclass is the interesting part of each subclass entity. The reason I want to subclass is to enforce typing rules, as some parts of the program require EntityThree, while some parts of the program require EntityTwo. the byte[] will have completely different meaning from subclass to subclass.

It feels a little strange, because I don’t expect that any of the subclasses will add any fields or methods… So i use inheritance only as a typing tool.

Is this a reasonable design? A better way to accomplish this? Does it break any best practices?

Answer 1

It is a good OO practice. For the database, use the SINGLE_TABLE Inheritance strategy (the default), and maybe use a custom @DiscriminatorValue per subclass, otherwise you’ll get classnames in your table.

From a DBA perspective, there is no difference between this and using a single class with a property TYPE.

For OO, the subclasses can be much more usefull, e.g. you can use it to implement certain methods differently or implement the visitor or strategy pattern instead of tedious if-then-else or instanceof structures.