What is the design pattern of a program that uses global arrays to store variables?

Question

Specifically, I mean code structured in a way where storage is global. Bare with me, as my terminology is all over the place. If I want to create a variable, I "load" it into a global cache. Any time I want to refer to this variable, I use an index.

It feels like the opposite of OOP, where there's a ton of abstraction and most objects inherit from some other object, etc...

I think OpenGL employs something like what I'm trying to put a name to (i.e. one has to "bind" variables)?

I just can't seem to put the right words into Google to find what I'm looking for, so I thought I'd pop a simple question here. Thank you for your help!

• freakish: The name of this design pattern is: bad code.
• whatsisname: There isn't one. There isnt a named pattern for every conceivable implementation of things.
• whatsisname: It's not a singleton. This aspect of openGl isn't implementing any particular design pattern, it's a result of the somewhat unique quirks of the interface across the PCI bus to the independent graphics hardware. Its constraints and therefore resulting design really doesn't exist in "normal" software taking place entirely in the CPU.
• Euphoric: Storing "variables" into "global storage" and accessed via "index" is called a database.
• Kilian Foth: This is what the computer actually does. All our computer languages and frameworks do is hide that stark fact behind a representation that is easier to work with for humans.

Answer 1

You don’t have to know the name of the pattern to write the code. Most patterns were written before they were named.

Some patterns were given names before we even had a book about patterns. I think that’s what’s happened here.

The point of naming a pattern is to make it easier to talk about. These names make me think about what you describe:

• Global array
• Offset + index = address
• Pointer
• Reference

All of which map into system memory which is global (and an array). What makes a variable global is everywhere knowing about it.

You won’t find these names in pattern books mostly because we understood this stuff before we understood patterns. So we just gave them names.

What your description doesn’t make me think of is indexing into a database which is a thing but I don’t think it’s your thing.

• Kilian Foth: +1 for "Most patterns were written before they were named."
• Scene: +1 Thank you for the helpful clarification! The list of names you give makes it nice to have a label to wishy washy concepts in my head.
• Jörg W Mittag: "Most patterns were written before they were named." – I would go further: "ALL patterns were written before they were named." Patterns are discovered, not designed.
• cmaster - reinstate monica: Global arrays, offsets/indices, pointers and references are not patterns. They are abstractions in programming languages. A pattern would be a lazily allocated buffer, for instance, or a pointer linked list.
• candied_orange: @cmaster-reinstatemonica I can see why you might think that way. Just understand that there is more than one patterns book.

Answer 2

I wouldn't really say this is a conventional "design pattern".

The issue here isn't just the global scope of access, but the fact that you're looking things up each time by "index", rather than using the compiler facilities (like named variables).

As others have said, this sounds somewhat like how a database works. But that is only from the perspective of its external API, where the whole point is to provide an abstraction of storage, including allowing permanent records to be referred to in a machine-independent and session-independent way (because those things will change over the life of the record, and the reference must stay valid).

It's not really how database engines work internally as executable programs.

As a technique for storing "variables" as we usually know them within running programs, this is either just extravagant complexity and reimplementation in bespoke software of the things that are adequately provided by hardware and standard compilers, or it is designed to overcome unusual memory constraints where perhaps there needs to be shared memory between two processes, a system for accessing it, and an inability to compile the two processes simultaneously so as to guarantee a specific memory layout.

Even if the technique is legitimate, there's the potential there won't be a specific name for it because it isn't used often enough by enough practitioners, but is instead used (and perhaps, autonomously invented by) by a very small number of those creating applications under highly specific circumstances, for whom the technique is just an unnamed facet of how their application works (and of which facet their understanding is entirely non-verbal).

Answer 3

It's called "using global variables". Usually there is no design and no pattern involved, and if you did call it a pattern, general consensus is that it is an anti-pattern. (Anti-pattern is just like a pattern, but causes problems instead of helping you).

• Christophe: Yes! And sometimes it's wrapped into a singleton for the good conscience ;-)

Answer 4

To me this sounds similar to how file handles, window handles etc. are used. Particularly when writing applications for (older?) Windows OS.

https://en.wikipedia.org/wiki/Handle_(computing)

The life cycle, memory management etc. is handled by the "kernel" and the "user level" code passes a handle into "system calls" to read/write/render.

It doesn't necessarily make for a bad pattern at all. I think the key to keeping it manageable is to make sure the "handles" are opaque objects (indexes/pointers fit that bill) and only the "kernel" code actually reads/writes to the data. This is actually very object oriented, it just turns the "usual" syntax of object.method(...) "inside out" (i.e. method(object, ...)) so the biggest downside is likely to be name-spacing the method names.

Answer 5

The word "dictionary" comes to mind here. One might argue that a dictionary is a design pattern, but I'm inclined to just call it a data structure. In any case, this seems messy in the context that you're describing. Such a dictionary would have to have untyped values in it to be much use. That translates to much type checking and casting, which can ultimately impact application performance and become a maintenance nightmare in the long run. The perfect storm is where one part of a program places a value of Type A at a given index in the dictionary, and another part replaces that value with an instance of type B, and both are expected to work well. In the long run, this causes a mess.

If you're thinking about designing this way, DON'T.