Hello.

To maximize the encapsulation, I'd like to model Cat like this:

public abstract class Cat {
protected Key getPrimaryKey();
protected void setPrimaryKey(Key k);
}

public abstract class Key {
public abstract String toString();
}

The objective of this design is to allow independence on using the internal representation of key e.g. change from long integer to UUID.

The problem goes on mapping: as the id is now an object, how to define the mapping file without using the composite-id method (as it is highly undesirable)?

Thx.

Use a custom user type propably. IMHO it would be better anyways to simply keep your key a String and use a UserType to map from the underlying database types. Note that with such IMHO ugly constructs, you will probably not be able to use some generators like increment, etc.

I am even not sure if you can use any generators besides assigned.

I'd like to know more on the disadvantages besides the coding effort.
As design is always a trade-off activities, I'd like to know more about the disadvantage on using this design from an object-oriented, object-relational mapping, and db schema design persepectives.

Let me list out what I believe I can gain:
1. Key internal type independence: now every object can be identified by instances of Key object, without exposing the actual type of the key.
2. PlaceHolder for the capturing Key's behaviour and operations: as we have defined a class Key we can further define its behaviours and some operations within the class
...

And The costs:
1. More code: making custom type.
...

Thx.

The costs:
1. More code
2. Additional model complexity
3. Creating Functionality you will most likely never need

What I would suggest: Stick to the YAGNI Principle and leave it out.

Actually, you can write your own id generator and use that.