Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: data structure question

by daxim (Chaplain)
on Aug 30, 2013 at 11:49 UTC ( #1051610=note: print w/ replies, xml ) Need Help??


in reply to data structure question

Don't. That's the "God object" anti-pattern.

Keep the variables separate, but move them into the smallest possible scope. That is to say, define them in the function/block where they are needed, not everything at once at the top.


Comment on Re: data structure question
Replies are listed 'Best First'.
Re^2: data structure question
by SuicideJunkie (Vicar) on Aug 30, 2013 at 14:06 UTC

    It does have its uses however.

    In my game, I have a $universe hash, containing all the ships and maps and other info. The ships contain their component layout and stats, and the components contain their shapes and stats.

    When calling functions, I only pass the sub-structure that is needed, but when it comes time to save the game or reload from disk, it only requires a single call to storable or yaml which never has to change. Much simpler than having a growing set of independent things to save.

    There are, of course, still plenty of local variables in small scopes, but anything that has to outlive the program itself goes into my $universe.

      it only requires a single call to storable

      That's the justification for this amazingly sub-optimal design? ಠ_ಠ The hash key names are tight coupling, the location of the "sub-structure" is an implicit contract. That's badly reinventing the facilities of high-level programming Perl/ecosystem provides you with. It's perfectly possible to have a universe object that refers to other objects, but the design would be much more robust against changes.

        The substructures are just unblessed object references to keep it simple. :)

        I'm not sure what you mean by worrying about the key names or location of the substructure... each portion of the code concerns itself with one layer and knows where it keeps its own things. The mapview has a 2d hash with ships in it, and doesn't care about the details. The shipview has a ship ref with components in it, and doesn't worry about the details. The aim screen has a single component ref and is at the bottom level of detail (its also stacked on top of a mapview so you can see what you're aiming at).

        Its not an *enforced* separation, but I like the straps on my straightjackets to be loose :)

Re^2: data structure question
by Anonymous Monk on Aug 30, 2013 at 11:51 UTC
    thanks, that was an encouraging answer!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1051610]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (9)
As of 2015-08-03 06:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The oldest computer book still on my shelves (or on my digital media) is ...













    Results (26 votes), past polls