[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] your opinion: singleton-pattern vs. modules vs. classes



On Mon, 3 Mar 2008 18:15:21 +0100, "Olaf Nowacki" <ioa@xxxxxxx> wrote:
> i'm not sure if i got this right: you
> - use an "ordinary" class
> - make an instance in a module and
> - excess this instance only via the module?
> 
> maybe you can provide an example?

In my sound module "conch," I did something like this:
class Jukebox:
    ...

j = Jukebox()

And then in another module:
import conch
conch.j.DoStuff()

I later decided that this was stupid. Why make a class if I'm only going to
make one instance of it and then have to refer to module.object.function(),
when Python treats modules themselves as objects too? In the current
version of "conch," I have the data and functions just be part of the
module itself, so that the function calls from outside become like
"conch.DoStuff()".

Come to think of it, I'm still using my tile engine as a singleton class.
Maybe it'd make sense to redo it the same way. The one drawback I can think
of is that you might want two copies of the class/module someday, eg.
keeping two tiled landscapes in memory instead of having to rebuild one
every time you switch. Even so, unless _everything_ about the tile engine
is likely to change, it'd be pretty simple to store multiple "slots" for
the relevant data and just set the equivalent of a pointer to the one you
want at any given moment.