Zur Erinnerung, ein (einfaches) Singleton sieht ungefähr so aus:

class Singleton {
public:
	//! gibt Singleton-Instanz zurueck
	Singleton& getSingleton() {
		static Singleton singleton;
		return singleton;
	}

private:
	//! Konstruktor
	Singleton() { }

	//! Destruktor
	~Singleton() { }
};

Für meine Anwendung (eine Grafikengine für die Uni) will ich mir nicht die Möglichkeit verbauen mehrere Engines gleichzeitig laufen zulassen. Zum Beispiel wäre es schön, wenn man neben dem eigentlichen Spiel auch noch ein Menü, das mit der selben Engine läuft, hätte (in vielen Spielen läuft ja z.B. eine gescriptete Szene im Hintergrund). Oder die Möglichkeit mehrere Unterschiedliche Schauplätze zu haben, ich denke Anwendungen gibt es zu hauf...

Meine Idee ist es, das Singleton so zu erweitern, dass es mehrere Instanzen geben kann. Wenn man also die Instanz des Spiels braucht ruft man getSingleton(GAME) auf. Wenn man dagegen das Menü braucht ruft man getSingleton(MENU) auf, usw...
Dabei sind GAME bzw. MENU einfach nur Konstanten (oder Enum etc.)
Wird getSingleton() mit einer Konstante aufgerufen für die es noch keine Instanz gibt wird eine neue erzeugt. Ansonsten wird die bestehende zurückgegeben.

Vermutlich widerspricht das ziemlich dem Singleton-Konzept, daher hab ich es mal Multiton getauft. (falls das schon einen Namen hat, dann sagt ihn mir bitte )

Also was haltet ihr von diesem Multiton?

mfg,
Coolcat

class Engine : public Singleton
{
    public:
        Menu *GetMenu() { return menu; }

    private:
        Menu    menu;
};

int main()
{
    Engine engine;
    Menu *p = engine.GetMenu();
}

ziemlich einfaches beispiel aber somit könntest du auch gewährleisten das es nur ein menü existiert

nicht viel.

Argumente?

Wozu brauchst du ne andere Instanz der Engine um das Menü zu zeichnen?

Dadurch könnte das Hauptmenü während des Spiels im Speicher bleiben und ich kann während das Spiel läuft (bzw. noch im Speicher ist) im Hauptmenü sein. Ich kann also ohne nachladen umschalten. Besonders wichtig ist das wenn z.B. ein Strategiespiel an verschiedenen Schauplätzen (z.B. Planeten) stattfindet. Man könnte also ohne laden hin- und herschalten. (ggf. ein paar Sachen nachladen wenn der Speicher nicht reicht, aber zumindest ohne alles komplett neu zu initialisieren)

Coolcat

Coolcat

wie es jeder machen würde

Und wie würde es jeder machen?

...aber ich merke schon an eueren Reaktionen, dass meine Idee wohl ziemlicher Müll sein muss Ich denke ich werd es dann auf die konventionelle Art machen.

Also eine Factory ist was anderes....

wieso du brauchst halt eine basisklasse.
halten könntest du zb: in einer map<enum, basisklasse*> bei einem zugriff wird das objekt erstellt und zurückgegeben falls schon eine instanz vorhanden ist wird diese zurückgegeben. bin ich jetzt so annährend richtig was du dir vorstellst?
du könntest mir allerdings noch dein universell erklären.

Ich verstehe ich dich jetzt so, das du ein extra Menu und ein Game von Engine ableitest.
Also da alle Instanzen (also für GAME, MENU, usw.) identisch sind brauch ich ja nicht von einer Basisklasse "Engine" ableiten.
Mit universell meine ich eben genau dies. Also die Klasse ist so universell, dass man damit sowohl das Spiel selbst als auch das Menü machen kann.

Es wäre dann eine Factory, die nur Objekte vom Typ Engine erzeugt. (was dann keine Factory in dem Sinne mehr ist, vorallem, weil die Factory in die Klasse Engine eingebaut wäre)

Coolcat

Ich verstehe ich dich jetzt so, das du ein extra Menu und ein Game von Engine ableitest.

irgendwie so etwas, sprich von einer schnittstelle die vernünftig ist. blos nicht von engine halt.

class EngineObj; // virtuelle basisklasse
class Menu : public EngineObj;
// usw
class Engine
{
    map<enum, EngineObj*> objlst;

    public:
        EngineObj *get(enum) { }
};

Coolcat schrieb:

Also da alle Instanzen (also für GAME, MENU, usw.) identisch sind brauch ich ja nicht von einer Basisklasse "Engine" ableiten.

aber könntest du sie in einem container speichern.
game hat nichts mit der engine zu tun. zwischen game und engine sollte eine klare trennung sein.

[edit]
tags

game hat nichts mit der engine zu tun.

Hä?
Warum kann GAME (bzw. genauso MENU) nicht einfach eine Instanz von Engine sein die für das Spiel zuständig ist?

Ich meine das ungefähr so:

class Multiton {
public:
    Multiton& getMultiton(int typ) {
        Multiton* mt = mtMap[typ];
        if (mt) { return *mt; }
        mt = new Multiton();
        mtMap[typ] = mt; 
        return *mt;
    }

private:
    static map<int,Multiton*> mtMap;

    //! Konstruktor
    Multiton() { }

    //! Destruktor
    ~Multiton() { }

    //! alles freigeben, was in mtMap ist...
    static void destruct() { /*...*/ } 
};

Edit: ^^ Tippfehler im Quellcode

Warum kann GAME (bzw. genauso MENU) nicht einfach eine Instanz von Engine sein die für das Spiel zuständig ist?

ist vermutlich eine streit frage, aber für ist es so das game die engine als schnittstelle benutzt.

also ich sag erstmal thx@all, ich werde nochmal etwas über dem Design grübeln....

Coolcat

//hier tolle globale enums:

[...]

  getSingleton(GAME);
  getSingleton(MENU);

gegenüber dem hier:

//tolle, globale variablen
engine game,menu;

[...]

  game;
  menu;

ist imho beides nicht so prall.

Und schau dir dann mal Seite 10ff und 32ff an.
Das Buch ist auch sonst sicher interesant...

Coolcat