Creating Objects

You are correct, trying to eliminate unnecessary lifecycle control from your model. You spotted entity in question and scrutinized it's right to have independent lifecycle. So you nearly answered your own question and just need a confirmation about it being a good practice. It is good improvement of your model. Yes.

If poker player has hand, does it mean the hand is an object ?

Lets check it: Can hand exist without player ? Can player have more than one hand ? Can player have series of hands over time, but no more than one hand at a time ? Can non-existence of hand be treated as an "empty hand" which still allows for hand object to exist ?

If I understand game correctly, the hand is an attribute, not an object. Player is the only entity, which has a lifecycle. Hand is a slot with fixed capacity, an attribute, so no individual creation or destruction is needed for hand, when player is an object.

Treat object lifecycle as meaningful part of model. Object should be able to express existence of particular thing X, as well as null in place of the object expresses non-existence of X

Object must be created no earlier and no later than particular event/transition in your model requires it. Object must be destroyed exactly with the same considerations. If model contains 2 related classes, where objects have nested lifecycles, nest the classes, so one should be a contaner of other. If lifecycles of this 2 classes match exactly, then eliminate duplicates, demote one of classes to be an attribute.

A slightly different view on the problem - no, it's not always bad practice to initialize and create an object multiple times. There's even a pattern named Value Object that makes heavy use of object recreation if necessary.

A Hand could perfectly be an object, and a pretty good choice for a value object for that matter.

When you think of it, the poker domain is largely about hands - comparing players hands, adding cards to a hand, calculating probabilities from a hand, etc. So why not make Hand a first class domain object ? Yet a hand is quite anonymous, if there's an identity to it, it rather belongs to the player than the hand of cards itself. As Rocket Surgeon pointed out, chances are that Player is the only entity (with an identity), but not necessarily the only object.

I see several benefits to making Hand a (value) object :

• You gain a lot of readability from making the concept explicit - passing a Hand around as a parameter, or comparing 2 Hands, is much more meaningful and immediately intention revealing than passing or comparing Players or arrays of Cards.

• You can reuse the Hand anywhere you want, even outside of a Player.

• If you go the value object route, you can make a Hand immutable. Thus you don't have to worry about changes in its state, wondering when and by whom your hand was modified. Threads that need to access your hand in parallel can do it without fear of concurrent modification problems.

Now from your original question, I'm not sure whether you're talking about a business Hand object or a graphical Hand object ("create object to show completed hand to show outcome of the game"). The instantiation and reuse of graphical objects is a whole other story.