1

I'm working on a gui app with cpp and gtkmm3. In this app, some widgets require the singleton pattern to implement such as window (because i want just one window in all over the app) this is my header file:

class MyWindow : public Gtk::ApplicationWindow {

public:
    MyWindow(BaseObjectType *pWindow, Glib::RefPtr<Gtk::Builder> builder);
    ~MyWindow();
    MyWindow(MyWindow const&) = delete;
    void operator=(MyWindow const&) = delete;
    static MyWindow* getInstance();

private:
    MyWindow();

};

and source file is :



MyWindow::MyWindow(){}

MyWindow::MyWindow(BaseObjectType *pWindow, Glib::RefPtr<Gtk::Builder> refBuilder)
        : Gtk::ApplicationWindow(pWindow),
          builder(refBuilder) {

}

MyWindow::~MyWindow() {}

MyWindow *MyWindow::getInstance() {
    static MyWindow *window;
    return window;
}

my question is: Is there a more appropriate and reasonable pattern instead singleton pattern ? Is using this pattern suitable for the interface widgets and gui app ?

mohamadp91
  • 47
  • 9
  • very often a singleton can be replaced by not-a-singleton. Its not a pattern, because its just a class like any other of which you create one instance – 463035818_is_not_an_ai Dec 02 '21 at 18:40
  • btw your `MyWindow` is kinda broken. `getInstance` does not return an instance but just a pointer that points nowhere and there is no way to actually create an instance – 463035818_is_not_an_ai Dec 02 '21 at 18:43
  • Yes.But in this case, I have a class that needs to be used in exactly a few other classes. – mohamadp91 Dec 02 '21 at 18:46
  • That's just an example. I'm using Glade and with Gtk::Builder it works properly. – mohamadp91 Dec 02 '21 at 18:49
  • 1
    the question is about opinions, hence offtopic. A singleton is a global in disguise and for why globals should be avoided you can read eg https://stackoverflow.com/q/19158339/4117728. Imho a logger is a valid case for a global/singleton because you need it in all code no matter what that code is actually dealing with, a window is not that – 463035818_is_not_an_ai Dec 02 '21 at 18:54
  • @463035818_is_not_a_number a main application window might, though - for GUI applications, which in certain frameworks are heavily tied to so called main windows. Which gives us a global variable of a normal, non-singleton class. Actually, loggers often follow the same rule - Logger class itself is a normal class, but there is a globally accessible logger instance. As a matter of fact, this is what `std::cout` is. :) – SergeyA Dec 02 '21 at 18:56
  • @SergeyA I don't disagree ;). Nevertheless, its a matter of choice and opinions. – 463035818_is_not_an_ai Dec 02 '21 at 19:01

1 Answers1

2

The major problem with the Singleton design pattern is that it gives you:

  1. a single instance AND
  2. global access.

The single instance aspect of the singleton is what people usually are looking for (like in your case), but not global access.

The usual "alternative" to this is to declare a MyWindow instance and then inject it to anyone who needs it. This is known as dependency injection. So you have something like:

void DoSomeThingOnWindow(MyWindow& p_window)
{
    p_window.DoSomething();
}

// At the beginning:
MyWindow window;

// Everywhere else:
DoSomeThingWithTheWindow(window);

instead of:

void DoSomeThingOnWindow()
{
    // Global access:
    MyWindow* window = MyWindow::getInstance();
    window->DoSomething();
}

// Everywhere:
DoSomeThingWithTheWindow();

The "bad" side of dependency injection over a singleton is that it will not enforce the single instance. However, if you use it everywhere and carefully, you can pass a single instance all around and not have global access, which will have so much more benefits.

BobMorane
  • 3,870
  • 3
  • 20
  • 42
  • Do you mean that instead of each class requesting MainWindow, we provide it for that class anyway? – mohamadp91 Dec 05 '21 at 10:21
  • Yes, you provide it as a reference to your single instance. One of the effect of this is that the dependence to the window now becomes clear from the using classes, in opposition to the singleton where it is hidden. – BobMorane Dec 05 '21 at 13:15