Alternative to storing a mapping of Outcomes in the Wheel class

41 views
Skip to first unread message

Philip Blankenau

unread,
Jun 15, 2018, 2:58:05 PM6/15/18
to Building Skills Books
Hi everyone,

When writing my player classes I have been having to instantiate a wheel in each class to get an outcome.  This seems kind of wonky.  We also end up with what seems like a lot more object creation that we need.  The book states that a singleton is another option, but I have read elsewhere that singletons are an antipattern.  Are there some other good ways to do this without a singleton?

Thanks,
Phil

Philip Blankenau

unread,
Jun 20, 2018, 12:08:33 PM6/20/18
to Building Skills Books
There are 150 outcomes by my count.  Would it be foolish to store a mapping of all 150 outcome names to their odds in an Outcome class variable?  Then my plan was to create an Outcome class method called 'from_name()' to construct instances of Outcome using the mapping.  I can see why it's nice to have that mapping produced programmatically but is this a decent alternative approach?  As a self-taught programmer, I sometimes wonder if I am doing something the pros would frown on.

Thanks,
Phil

Steven F. Lott

unread,
Jun 20, 2018, 7:43:53 PM6/20/18
to building-s...@googlegroups.com
Any number of instances less than a million is  irrelevant and small. Seriously.

The only time you’d ever need to think about so few objects is (1) each object is over 1mb in size or (2) you’re on a micro-python running on a tiny processor with 32k RAM. 

 Python caches hundreds of common objects when it starts running. An additional 150 isn’t worth optimizing. 

Sent from my iPhone
--
You received this message because you are subscribed to the Google Groups "Building Skills Books" group.
To unsubscribe from this group and stop receiving emails from it, send an email to building-skills-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages