Design Pattern : Static Array/List in Class Object

Question

I'm a CS alumni, but we didn't learn much by the way of OOP, or Design Patterns. I've heard the phrase C with iostreams and thought it fitting. Anyway that's besides the point. I am just curious about what I perceive would be a very simple design pattern.

Have any of you played the game Starcraft? You know how you can select/deselect units? Back to that in a second. Suppose I have a Unit class, and I wanted it to keep track of all the units that were selected. I had the idea that I could create a static list/arrray inside the Unit class, and the units themselves could add or remove themselves from the array as they were selected/deselected.

That's just one example, there could be other applications of this "pattern". Say you wanted to maintain a list of visible "tabs" in a web browser or w/e, you could have them add a reference to themselves in a a static array in the class.

The idea is that you could just call Unit.GetSelected() and get a pointer/reference to all of the "selected" or "opened" units/tabs. I am aware that there are other maybe better ways of solving these problems, but that is also besides the point. What would this pattern be called?

Answer 1

This anti-pattern would be named whatever you like. I'm not sure I've seen it named before, though I would heartily recommend against getting cozy with it. I've seen this in games occasionally when someone thinks it's a good idea to have a global list of "all of the units in the game". Even if that's a good idea, that shouldn't be the responsibility of the unit - it's the responsibility of the game.

For your example, only the UI should know or care what's selected. Your game objects certainly should not.

In a more general sense, having a static that a type knows about tends to be tight coupling - making your code inflexible, hard to test, and hard to use concurrently.