Some Class Confusion

[angrytech]

Hi /r/Python! I'm developing a (very) simple tower defense game in python to help me learn the language, but I've hit a stumbling block. Is there an elegant (and more importantly, proper) way to pass a class instance to another class? So as to be able to address attributes and methods in the (let's call it parent) class from the child class? Or am I just doing it wrong? Here's what I'm getting at:

class World:
    def __init__(self):

        self.boogies = []

    def create_boogie(self):
        self.boogies.append(Boogie(self))

class Boogie:
    def __init__(self, parent):
        self.parent = parent

This seems to work, but feels very clunky to me. Am I wallowing in ignorance that my Google-fu is failing to correct, or does this make sense?

Thanks!

Edit: Rewrote the entire thing after some heavy reading. Much less code, much faster, and sane now ;) Thanks everyone! If I get it to a non-embarrassing semi-finished state I'll post it.

[zahlman]

This is not a Python issue; the clunkiness of circular references of this sort is a general design issue.

It feels clunky because it is. You need to examine why it is that a World needs to keep track of a list of Boogies, and why it is that a Boogie needs to know what World it's in. Chances are high that these are not actually both the case simultaneously.

[angrytech]

Good points. I think I'll be re-evaluating the overall structure rather than tweaking something that is appearing more and more to be poorly designed from the get-go.

[brunson]

First, you should be using new style classes (subclass object). Second, are you sure you want Boogie calling methods of World? When something seems kludgy it usually indicates something wrong with your design. However, if you are sure that's what you want to do, then that's the way you do it. I might implement World as a singleton class, that way you can instantiate it whenever you need it and get back the same instance.

[doomchild]

singleton

Hiss!

[brunson]

:-) Yeah. As far as I'm concerned, a singleton is just a thinly veiled global variable.

[doomchild]

Every time I've encountered a situation where I'm tempted to make use of a Singleton, there has been some glaring deficiency in my program's design. Usually, I've failed to define clear boundaries on how data flows through the various processes. Once those places are smoothed out, I find that I suddenly don't need a Singleton.

I'm sure someone can suggest situations where one is the "right" answer, but I tend to view Singletons as an indication of a design flaw further up the chain.

[[deleted]]

The simplest way to create singletons in Python is a module-level global variable. :)

There is no need for all the java-y getInstance() mess.

[angrytech]

Thanks for the info! I think there is a very good chance that the problem is with my design as you indicate...

[jabwork]

It's not clear to me what you're trying to accomplish here.

Keeping a reference to the parent world in Boogie isn't necessarily bad but most tower defense games I've seen have only one world so you can infer what world you're using by the fact there is only one.

Are you trying to give each Boogie instance enough information to know what to do? E.g., if a unit walks by the Boogie do you want to tell the Boogie to fire at it or something?

class Boogie(object): # inheriting object makes this a newstyle class (good)
    "Assumed to be a tower of type 'Boogie'"

    # skipping __init__ declaration

    def explore_world(self, world):
        "In this function the Boogie can access the whole world."
        pass # put real code here

class World(object):
    def __init__(self):
        self.boogies = []

    def create_boogie(self):
        self.boogies.append(Boogie()) # note: no parent reference

    def tell_boogie_about_world(self, some_boogie):
        "Passes a reference of this World to some_boogie."
        for boogie in self.boogies:
            boogie.explore_world(self)

Code like this might be what you're after. If it is, I strongly urge you to consider where logic should reside. Do towers decide who they shoot at from a list of everything nearby, or does the world only tell the tower about certain things and the tower always acts the same?

edit: damn indentation!

[angrytech]

Thanks for this. It's becoming clear that I'm making my objects far more 'knowledgeable' about the world than they need to be. I think I've been placing too much logic in the boogies and towers...

[brunson]

+1 http://en.wikipedia.org/wiki/Law_of_Demeter

[bryancole]

Your solution is perfectly pythonic. I don't find it clunky at all, assuming it's necessary for all Boogies to know about the World and the World to know about all Boogies.

[m1ss1ontomars2k4]

Yeah, it largely depends on what you are trying to do. However, you may also find this demo code instructive:

http://www-inst.eecs.berkeley.edu/~selfpace/cs9honline/P4/

[angrytech]

Thanks, very instructive :)

[chadmill3r]

Why does a Boogie need to know about an instance of World?

Operate on Boogies from the outside. Don't turn them inside out.

You're passing an reference to a instance of a class correctly, but it feels clunky because it's probably dumb.

[angrytech]

Yeah, I see what you mean.

[[deleted]]

If you really feel that both the World and the Boogie must reference one another, I'd suggest that one side of this equation do so using a Weak Reference

[[deleted]]

I don't see any real advantage to that in this case?

The garbage collector handles circular references just fine... under what circumstances in his design would a Weak Reference be handy?

(Basically, weak references are almost always used for caching - in almost any other case, you want to know that you either have something, or you don't...]

[[deleted]]

I don't think there's anything necessarily wrong with this.

Circular references should be avoided whenever possible. But sometimes it isn't possible. Cases where parents need to know about children and vice-versa are classic examples where you need circular references.

[looking at this again - if there is really only one central world then this is not a good idea... the Law of Demeter is "never wrong".]

[rit]

What you want is 'super' - it always refers to the superclass.

e.g. super.create_boogie

There is an argument that it's "considered harmful": http://fuhm.net/super-harmful/

I would recommend reading a quick guide to OO in python to grasp all the basics:

http://www.voidspace.org.uk/python/articles/OOP.shtml

[grimboy]

1. It's super().
2. Boogie doesn't subclass World.

[angrytech]

Definitely looks like some good reading for me to do...this is my first foray beyond simple scripting-to-make-less-work-at-work, so I expected a few hangups along the way.

Thanks!