What is the best way to model an object (for hibernate) which has an optional object (child) depending on it's state?

For example:
Item has a Rejection if Item.state == IS_REJECTED.
Rejection has state describing why, reject code, comments etc.

Thanks in Advance.

There's two ways to look at this.

#1 is that an Item class has a reference to a Rejection class because the item itself is "rejectable". In this case, just map the Item class with a reference to the Rejection class.

#2 is that an Item and a "RejectedItem" are conceived differently. Here an Item does *not* have a reference to a Rejection, but a RejectedItem would. In thins case RejectedItem is a subclass of Item, adding an additional property named rejection. This would be mapped in Hibernate using some form of subclass mapping (depending upon the underlying db structures).

Its not so much a question regarding Hibernate. Its a question about which makes the most sense in your system. Hibernate can handle either.

Thanks Steve.

Subclassing seems extreme, but I've been playing with references (#1),
and my real question is this:

from the db side, I'd expect something like this:
Item
-----------------------
item_id | state_code

Rejection
---------------------------------
reject_id | item_id | state....

one-to-one, foreign key in the rejection.

But from the app side, I'd expect to see
parent.deleteItems();
that would cascade deletes to the applicable rejections, which
can't exist without an item.

however;

Item
--------------------------------------
item_id | state_code|rejection_id


would be really ugly because a.) bidirectional fkey-pkey makes delete
tough and b.) Item table/reject ID will be very sparse and ugly:

Item
---------------------------------------
1 | 0 | <null>
2 | 0 | <null>
...<n>
99| 1 | 1

My next try is to use State Pattern, externalize the state and subclass that so as a RejectState has a reference to Rejection (ouch).
Does that make sense?

Sure. It all depends on the app requirements. But that's the cool thing about a good OR tool like Hibernate. It lets you code the app domain objects the way the app requirements dictate and then map that to the db.

Personally, I'd ask whether that's really what you want to model in the OO realm. Not knowing all your requirements, it sounds like an optional association or subclassing of the item into a rejected-item is more aligned with what your trying to model. But then again I really don't know the requirements the way you do.

If state is actually representing a state-machine or workflow progression, then it would be more conducive to model it the way you mention.

After revisiting the state pattern, I'm convinced this is the way to go.
I'd like to have:
if (item.isRejected()) ...
instead of:
if (item instanceof RejectedItem)...
Because an item's state will change dependent upon the user's actions at any given moment, as well as external conditions.

Thanks for the feedback!