Question

So, I have been working on familiarizing myself with JPA’s inheritance features and have really liked them so far. One thing that occurred to me recently is that they could actually be used for something other than just retrieving data. Given that it can get subclasses based on a discriminator value, inheritance is actually a convenient way to transform configuration fields into implementations. Being in that stage where my knowledge-to-experience ratio is in the ‘just enough to be dangerous/not enough to always realize it zone’, I thought it might be best to ask if this was a good idea.

Take this example with a PRODUCT and BILLTYPE table.

Product:
int Id
int billtypeid

Billtype:
int id
varchar[15] description

Billtype is simply a billing strategy for the product (We’ll say some orders may be billed by weight, while others could just be billed by case). Each bill type will require the use of different methods during the invoicing process. The Billtype table will likely only have a handful of entries, and shouldn’t grow to be very large.

Would it make sense to use inheritance to subclass an abstract Billtype entity that also defines an interface for the different methods the invoice code will need? Something like this:

@Entity
@DiscriminatorColumn("description")
public abstract class BillType {
   // Getters, setters
   // Abstract methods that could be used elsewhere - ex:
   // BigDecimal calculateInvVal(...)
}


@Entity
@DiscriminatorValue("by case")
public class CaseBillType extends BillType {
   // Implementation of calculateInvVal - now when invoicing code needs this method, 
   // the right one is always associated with the current product!
}

This provides a convenient way to associate behaviors with fields in the database that represent configuration data, but mixes business code with entities (which, by most accounts, is very very naughty). There could be a design pattern to fix this issue that I am missing from my repertoire, but I’d really like to avoid having to write lots of, “if bill type is this, get this subclass, if bill type is this, etc” code.

What I am looking for from an answer is an explanation of potential drawbacks to this technique I may not be seeing that would justify looking for another solution to this problem.

Answer 1

It’s useful to link a product with a BillType entity if it’s possible to add, remove and modify bill types at runtime without any need to rebuild and redeploy a new version of the application. This is not the case with your example.

So if what you have is a static set of bill types, each defining a static behavior encapsulated by the BillType subclass, you could simply have a BillType enum instead. Each instance of this enum defining its own behavior. You don’t need an entity hierarchy and an additional table for this.

The code to calculate the InVal in the Product entity would be exactly the same:

BigDecimal computeInVal() {
    billType.calculateInVal(this);
}

The code to get all the bill types would be

return BillType.values();

And instead of the following code to associate a bill type to a product:

product.setBillType(em.find(BillType.class, ID_OF_CASE_BILL_TYPE));

you would simply have

product.setBillType(BillType.BY_CASE);