When several classes need to access the same data, where should the data be declared?

Question

I have a basic 2D tower defense game in C++.

Each map is a separate class which inherits from GameState. The map delegates the logic and drawing code to each object in the game and sets data such as the map path. In pseudo-code the logic section might look something like this:

update():
  for each creep in creeps:
    creep.update()
  for each tower in towers:
    tower.update()
  for each missile in missiles:
    missile.update()

The objects (creeps, towers and missiles) are stored in vector-of-pointers. The towers must have access to the vector-of-creeps and the vector-of-missiles to create new missiles and identify targets.

The question is: where do I declare the vectors? Should they be members of the Map class, and passed as arguments to the tower.update() function? Or declared globally? Or are there other solutions I'm missing entirely?

When several classes need to access the same data, where should the data be declared?

Answer 1

When you need a single instance of a class throughout your program, we call that class a service. There are several standard methods of implementing services in programs:

• Global variables. These are the easiest to implement, but the worst design. If you use too many global variables, you will quickly find yourself writing modules that rely on each other too much (strong-coupling), making the flow of logic very difficult to follow. Global variables are not multithreading-friendly. Global variables make tracking the lifetime of objects more difficult, and clutter the namespace. They are, however, the most performant option, so there are times when they can and should be used, but use them spareingly.

• Singletons. About 10-15 years ago, singletons were the big design-pattern to know about. However, nowadays they are looked down upon. They are much easier to multi-thread, but you must limit their use to one thread at a time, which is not always what you want. Tracking lifetimes is just as difficult as with global variables.
  A typical singleton class will look something like this:

  class MyClass
  {
  private:
      static MyClass* _instance;
      MyClass() {} //private constructor
  
  public:
      static MyClass* getInstance();
      void method();
  };
  
  ...
  
  MyClass* MyClass::_instance = NULL;
  MyClass* MyClass::getInstance()
  {
      if(_instance == NULL)
          _instance = new MyClass(); //Not thread-safe version
      return _instance;
  
      //Note that _instance is *never* deleted - 
      //it exists for the entire lifetime of the program!
  }
  

• Dependency Injection (DI). This just means passing the service in as a constructor parameter. A service must already exist in order to pass it into a class, so there's no way for two services to rely on each other; in 98% of the cases, this is what you want (and for the other 2%, you can always create a setWhatever() method and pass in the service later). Because of this, DI doesn't have the same coupling problems as the other options. It can be used with multithreading, because each thread can simply have its own instance of every service (and share only those it absolutely needs to). It also makes code unit-testable, if you care about that.

  The problem with dependency injection is that it takes up more memory; now every instance of a class needs references to every service it will use. Also, it gets annoying to use when you have too many services; there are frameworks that mitigate this problem in other languages, but because of C++'s lack of reflection, DI frameworks in C++ tend to be even more work than just doing it manually.

  //Example of dependency injection
  class Tower
  {
  private:
      MissileCreationService* _missileCreator;
      CreepLocatorService* _creepLocator;
  public:
      Tower(MissileCreationService*, CreepLocatorService*);
  }
  
  //In order to create a tower, the creating-class must also have instances of
  // MissileCreationService and CreepLocatorService; thus, if we want to 
  // add a new service to the Tower constructor, we must add it to the
  // constructor of every class which creates a Tower as well!
  //This is not a problem in languages like C# and Java, where you can use
  // a framework to create an instance and inject automatically.
  

  See this page (from the documentation for Ninject, a C# DI framework) for another example.

  Dependency injection is the usual solution for this problem, and is the answer you will see most highly upvoted to questions like this on StackOverflow.com. DI is a type of Inversion of Control (IoC).

• Service Locator. Basically, just a class that holds an instance of every service. You can do it using reflection, or you can just add a new instance to it every time you want to create a new service. You still have the same problem as before - How do classes access this locator? - which can be solved in any of the above ways, but now you only need to do it for your ServiceLocator class, rather than for dozens of services. This method is also unit-testable, if you care about that sort of thing.

  Service Locators are another form of Inversion of Control (IoC). Usually, frameworks that do automatic dependency injection will also have a service locator.

  XNA (Microsoft's C# game programming framework) includes a service locator; to learn more about it, see this answer.

---

By the way, IMHO the towers should not know about the creeps. Unless you are planning on simply looping over the list of creeps for every tower, you'll probably want to implement some nontrivial space partitioning; and that sort of logic doesn't belong in the towers class.

Answer 2

I personally would use polymorphism here. Why have a missile vector, a tower vector, and a creep vector..when they all call the same function; update? Why not have a vector of pointers to some base class Entity or GameObject?

I find a good way to design is to think 'does this make sense in terms of ownership'? Obviously a tower owns a way to update itself, but does a map own all the objects on it? If you go for global, are you saying that nothing owns the towers and creeps? Global is usually a bad solution - it promotes bad design patterns, yet it is much easier to work with. Consider weighing up 'do I want to finish this?' and 'do I want something that I can reuse'?

One way around this is some form of messaging system. The tower may send a message to the map (which it has access to, perhaps a reference to its owner?) that it hit a creep, and the map then tells the creep it's been hit. This is very clean and segregates data.

Another way is to just search the map itself for what it wants. However, there may be issues with update order here.

Answer 3

This is a case in which strict object oriented programming (OOP) breaks down.

According to the principles of OOP, you should group data with related behavior using classes. But you have a behavior (targeting) that needs data that are not related to each other (towers and creeps). In this situation, many programmers will try to associate the behavior with part of the data it needs (e.g. towers handle targeting, but don't know about creeps), but there's another option: don't group the behavior with the data.

Instead of making the targeting behavior a method of the tower class, make it a free function which accepts towers and creeps as arguments. This might require making more of the members that are left in the tower and creep classes public, and that's OK. Data hiding is useful, but it's a means, not an end in itself, and you shouldn't be a slave to it. Besides, private members aren't the only way to control access to data — if data isn't passed into a function and it isn't global, it's effectively hidden from that function. If using this technique lets you avoid global data, you might actually be improving encapsulation.

An extreme example of this approach is the entity system architecture.