Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

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.

share|improve this answer
+1, Cool train of thought. – NoChance Jun 3 '12 at 19:51
Ha ha thank you. I wish my English was more fluent. This site helps me to practice the writing – user7071 Jun 3 '12 at 19:55
Your English and OO are perfect :) – NoChance Jun 3 '12 at 20:11
Great! So I have the right idea, thank you for the detailed response. Makes perfect sense. – user1424667 Jun 3 '12 at 21:59

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.