1

I have 6 classes as shown in the image below. I want all of these to be instantiated only once and at the same time, I would like to avoid singletons. Info class object will be created first in the application which reads the information of the system from a file. After this objects A, B, and C need to be created based on the info. After this Server1 and Server2 objects need to be created. Server1 objects want to access A object and Server2 wants to access A, B, C and Server1 objects.

Class heirarchy

How to solve this problem without using the singleton?

Thanks!
Subbarao

Improve this question
4
  • 2
    Have you considered dependency injection? BTW: It's pretty much irrelevant that you are using C++ here, you'd face the same issues and have the same solutions in many other languages. Commented Apr 4, 2018 at 4:52
  • Just do what you described. Commented Apr 4, 2018 at 5:01
  • Ulrich, Thanks for the suggestion on dependency injection, which I need to learn. I need to use C or C++ as the target platform is an embedded platform with very limited memory. Commented Apr 4, 2018 at 5:04
  • If you do not need to access these objects globally from any part of your code, then dependency injection is the way to go. If you do need global access, then you may consider using a service locator, read more here: gameprogrammingpatterns.com/service-locator.html Commented Apr 4, 2018 at 5:04

3 Answers 3

Reset to default
1

If you want an object to be created only once, then you need to count number of time it was created, otherwise there are always possibility that you or another programmer will accidentally create another instance. Usually that is done with the help of local static variable, and that is basically singleton.

Hard part is how to arrange access to your object across the program. That could be global variable, static method, or dependency injection that depends on your architecture. You can create all objects inside some class and then use getters to access them.

The bottom line is, that if your want to guarantee that the object can be created only once, then you are looking for some kind of singleton implementation.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

0

You could create normal classes then due to the usage architecture of your classes, only one instance of each class should ever reasonably be created. This is using dependency injection to replace singletons.

Some factory/main-like method would handle the loading/creation and passing of these instances to each of their dependents. No instance should ever need to exist as a singleton instance, but rather as a variable within a function.

// No need for singleton patterns, // but only one instance is ever created // by the program's main function. int main() { Info info = Info::LoadFromSystem("info.xml"); A a = A::CreateFromInfo(&info); B b = B::CreateFromInfo(&info); C c = C::CreateFromInfo(&info); // dependency injection (use pointers or references, same essential thing) Server1 server1 = new Server1(&a); Server2 server2 = new Server2(&server1, &a, &b, &c); server1.Run(); server2.Run(); // cleanup return 0; }

Meeting Singletons Halfway

A common pattern often used in frameworks is the "default instance" style of singleton. This frees up the class to be reinstantiated for other simultaneous use but creates a default instance that can be relied upon for most cases.

In C++, the example might be like this, although it creates a requirement to handle shutdown of the app and destroy the default instance:

class MostlySingle { private: static MostlySingle *_default = NULL; public: static MostlySingle *createDefault(Info &info) { if (_default != NULL) { // throw exception } _default = new MostlySingle(info); return _default; } static MostlySingle *default() { return _default; } static void destroyDefault() { delete _default; _default = NULL; } } int main() { // app startup MostlySingle::createDefault(Info::default()); auto instance = MostlySingle::default(); instance.send("Hello, world!"); // app shutdown MostlySingle::destroyDefault(); return 0; }
Improve this answer

5 Comments

I will add that dependency injection allows for abstraction via interfaces, so that A, B and C could take on different internal functionality without affecting the code that uses them, such as the servers.
Nick, I liked the idea. However, in the above example, you are creating pointers, which goes to the heap. I am not sure whether it is possible to avoid heap. Second thing is due to injection, the destructor of a is called twice. Once when server1 is deleted and once when server2 is destructed. Correct me if I am wrong.
I was just showing a way of using this non-singleton method. Whether you use pointers or references or stack-variables is mostly irrelevant to the design principle. You will still need pointers or references to pass instances around.
Why A::CreateFromInfo(info); can't be called twice?
@Yola It can be called twice, to create two identical instances, but the point is not to. Creating only one instance of a class does not necessitate a singleton pattern. A singleton is useful for forcing only one instance to ever be created.
0

Create them at the beginning of your program, remove the copy and move constructors from these classes and pass them down to the classes that depend on them. You can also make sure in the constructors that just an instance exists through a static class variable for each class incrementing a counter for a static variable. If it reaches 2, throw an exception. This way you will guarantee uniqueness.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.