Pytanie dotyczące singletonów (implementacja i zastosowanie)

Z powodu nadmiaru informacji o podstawach wzorców projektowych muszę wrzucić pewne (być może) głupie pytanie.

#include <iostream>

class Singleton
{
    private:
        static Singleton* instance;
        Singleton();
    public:
        static Singleton* getInstance();
};

Rozumiem,ze do tej klasy mogę śmiało dodać metody odpowiedzialne za np. renderowanie planszy,zapis stanu gry,przechowywanie danych o graczu,uruchomienie gry ? Po prostu każdy taki singleton musi mieć te rzeczy,które są ujęte w tym kodzie i mogę śmiało tutaj dodawać resztę metod ?
No i czy singletony nadają się do tych operacji o których pisze ?

I teraz główne pytanie - czy singletonem mogłaby być klasa Game odpowiedzialna w Tic-Tac-Toe za sprawdzanie czy ktoś wygrał lub czy jest remis albo np. w Snake'u odpowiedzialna czy doszlo do zderzenia weza z swoim ogonem lub sciana planszy ? oraz zliczeniem uzyskanych punktów ?
Czy mozna singleton traktować jako takiego nadzorce sprawdzającego inne obiekty występujące w programie ?

Wielu uznaje singletony jako anty wzorzec (w tym ja).
To nadal jest zmienna globalna, tyle że w fikuśnym opakowaniu.
IMO singleton nadaje się jedynie w dwóch przypadkach:

• narzędzie logowania
• obsługa funkcji aplikacji (popatrz np QApplication)

W każdym innym wypadku prędzej czy później singleton doprowadzi do powstania kodu, który jest trudny w utrzymaniu i praktycznie nieużywalny w innych aplikacjach.

Czyli poznając wzorce projektowe lepiej uznać Singleton za coś co trzeba unikać jak tylko się da ?

Generalnie tak. Popatrz np. na klasę QApplication i QCoreApplication. Przy czym użycie singletonów często oznacza sztywność interfejsu - prawie wszystko da się zrealizować bez nich, więc o ile nie jest to ćwiczenie na implementację singletona - staraj się go nie używać.

Ja bym powiedział raczej „za coś, co ludzie wymyślili, poużywali, po czym doszli do wniosku, że nie warto”. Ma on tendencję do utrudniania życia bardziej (w szczególności przy testowaniu) niż ułatwiania.

W bardzo wielu przypadkach (na intuicję także w Twoim), wystarczy zablokować możliwość kopiowania i przypisywania obiektu a później sensownie (w małej aplikacji) obsługiwać ten obiekt. "Zamordyzm singletona" jest często zbędny :)

Ja bym nawet poszedł o krok dalej i po prostu miał „dżentelmeńską umowę” odnośnie nie stosowania więcej niż jednej kopii. To zazwyczaj wystarcza.

Dopiero kiedy wydaje nam się, że do duplikacji mogłoby dojść przez przypadek, warto zastanowić się nad programowaniem defensywnym, ale osobiście nie uważam, żeby utrudnianie sobie życia w imię utrudniania celowo złego wykorzystania kodu miało sens…

Althorion napisał(a):

Ja bym powiedział raczej „za coś, co ludzie wymyślili, poużywali, po czym doszli do wniosku, że nie warto”. Ma on tendencję do utrudniania życia bardziej (w szczególności przy testowaniu) niż ułatwiania.

Widzę, np na gruncie C++ plus, model użycia Z RZADKA niosący coś pozytywnego. W Javie już nie ma tego plusa (inna sekwencja startu / ładowania).

W odróżnieniu od statycznej zmiennej zawierającej instancję obiektu (bo to najbliższa "konkurencja"), może być lazy (leniwy po polsku???).
Jakaś funkcjonalność, która ma się zainicjować stosunkowo późno itd...
Ale zgadzam się w ogólnym sensie.

I teraz główne pytanie - czy singletonem mogłaby być klasa Game odpowiedzialna w Tic-Tac-Toe za sprawdzanie czy ktoś wygrał lub czy jest remis albo np. w Snake'u odpowiedzialna czy doszlo do zderzenia weza z swoim ogonem lub sciana planszy ? oraz zliczeniem uzyskanych punktów ?
Czy mozna singleton traktować jako takiego nadzorce sprawdzającego inne obiekty występujące w programie ?

To się nazywa God Object i bardzo trudno się potem z czymś takim pracuje ;)

Jeśli chodzi o sam Singleton, to warto rozumieć, ze problemem nie jest fakt że masz jakiś obiekt którego w programie jest jedna instancja (ot choćby jakis bezstanowy serwis może mieć taką charakterystykę). Problemem jest sposób używania i tworzenia singletonów, który utrudnia albo wręcz uniemożliwia testowanie i modyfikacje kodu. Bo masz gdzieś w kodzie wywołanie takiego statycznego getInstance i niewiele sie z tym da zrobić -> nie podmienisz tej implementacji w teście (bez cudów w stylu powermocka), nie możesz łatwo dostarczyć innej implementacji tego obiektu itd.
Z tego też względu, nadal nie idealnie, ale lepiej już mieć przynajmniej Factory (bo można dodać tam nowe implementacje) albo jakiś ServiceLocator (bo możemy rejestrować inne implementacje, podmieniać w teście to co taki locator zwróci itd) zamiast takiego klasycznego Singletona ze statycznym getInstance.

Dziękuje wszystkim za wyczerpujące odpowiedzi.
Mam ostatnie pytanie (odbiegające od tematu).Otóż jeśli dobrze zrozumiałam to ponizsze klasy z mojego projektu:

#ifndef MAINWINDOW_H
#define MAINWINDOW_H
#include "ratingform.h"
#include <QMainWindow>
#include <QVBoxLayout>
#include "averageratings.h"

QT_BEGIN_NAMESPACE
namespace Ui { class MainWindow; }
QT_END_NAMESPACE

class MainWindow : public QMainWindow
{
    Q_OBJECT
    QVector<RatingForm*>ratingForms;
    QVBoxLayout *boxLayout;
    AverageRatings *wAverage;
    QString message;
    bool errorFlag;
    void showMessage(QString text);
    void checkValueLineText();
public:
    MainWindow(QWidget *parent = nullptr);
    ~MainWindow();
    void layoutRefresh(QVector<RatingForm*>&forms);

private slots:
    void on_quantityBox_valueChanged(int arg1);
    void on_averageButton_clicked();

private:
    Ui::MainWindow *ui;
};
#endif // MAINWINDOW_H

#ifndef AVERAGERATINGS_H
#define AVERAGERATINGS_H
#include <QMainWindow>
#include <stack>
#include "ratingform.h"

class AverageRatings
{
    int quantityRatings;
    std::stack<double>ratings;

public:
    AverageRatings(): quantityRatings(0){};
    inline void setQuantityRatings(int a){quantityRatings=a;}
    void setRatings(QVector<RatingForm*>forms);
    double calculateAverage();
};

#endif // AVERAGERATINGS_H

I jeśli dobrze zrozumiałam co czytałam to te dwie klasy tworzą związek jednokierunkowy,gdzie klasa MainWindow posiada wskaźnik do obiektu klasy AverageRatings ???
No i z tego co się dowiedziałam związki dwukierunkowe to błąd bo są wolniejsze i zaleca się stosowanie związków jednokierunkowy.

No i z tego co się dowiedziałam związki dwukierunkowe to błąd bo są wolniejsze i zaleca się stosowanie związków jednokierunkowy.

Nie wiem skąd takie porady, ale sugeruje ignorowanie takich źródeł. (powołujących się na szybsze - wolniejsze).