I'm coding in C++. I have a server that will have clients connect to it, and each client gets spun off into its own thread for communication. This server is hosting a game, so there is information that must be shared between all client threads, as well as any other threads I choose to spawn off. This data is like level data, players online, etc, so all threads might possible have to access any of the data at any time. When I was doing this in C#, I just had a static static with all static fields. Is there a superior way to do this? I really don't want to have to deal with passing a reference to a specific object everywhere, but I figure my current implementation goes against OOP etc. Would this be a good case for using a singleton design pattern? Any other ideas are welcomed!
C++ Singleton – Best Way to Have a Central Data Repository
csingleton
Related Solutions
If it works for you, then in that sense it is correct.
In a broader sense, I think a lot of people would see it as a kind of anti-pattern if you were using it in the following fashion:
class Foo
{
public void Bar()
{
int value = StaticData.getInstance().getUsefulPropertyValue();
// do stuff with value
}
}
This is considered an anti-pattern because the fact that Foo depends on StaticData is hidden within Foo's implementation. This tightly couples Foo and StaticData. In this specific situation it may not be that big of a problem because StaticData is unchanging, but in the general situation this makes it harder to test the parent class.
For example, if Foo was actually depending on the singleton DatabaseAccess then unit testing Foo would be impossible. Foo would require the presence of a database to be tested which is a) inconvenient, and b) no longer technically a unit test!
You can get around this by using Dependency Injection:
class Foo
{
private DatabaseAccess databaseAccess;
// Here we use Constructor Injection to inject Foo's dependencies into it.
// NOTE: The dependency on DatabaseAccess is made explicit by being a part of Foo's constructor signature.
// This makes it clear that Foo cannot be created without an instance of DatabaseAccess. It therefore depends on it.
public Foo(DatabaseAccess databaseAccess)
{
this.databaseAccess = databaseAccess;
}
public void Bar()
{
// NOTE: We are no longer plucking its dependency out of thin air!
int data = this.databaseAccess.getTheCoolestIntegerEver();
}
}
Functionally, this code is very similar, but in terms of testability and maintainability it is far superior.
Also, note that DatabaseAccess may still very well be a singleton. The key take-away here is to never access your singletons with a static getInstance() method.
Best Answer
3 main ways of doing this:
Use a global static object, its gets constructed at startup and can be a good pattern as it is very simple. Simple can often = good.
Use a singleton. You now have the object created later, and its still a single object. you fetch this object as needed. This is a "step-up" as you have more control about initialisation of the object compared to the global.
Use an 'Inversion of Control' object. This is basically passing the object into each class in the constructor, so each object has its private member pointer to the object. This is another step-up as it allows much easier access to the 'global', and also allows you to switch the injected object on a class by class basis.
Ultimately it depends, the IoC pattern is very fashionable at the moment, but I tend to prefer the global TBH. It depends as well what data you're putting into it, and if its a read-only or a read-write object.