I have a general coding standard question. Is it bad practice to initialize and create an object in multiple methods depending on the outcome of a users choice. So for example if the user quits a poker game, create the poker hand with the cards the user has received, even if < 5, and if the user played till the end create object to show completed hand to show outcome of the game. The key is that the object will only be created once in actuality, there are just different paths and parameters is will receive depending on if the user folded, or played on to the showdown.
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
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 :
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.