Multiton? (Singleton Variante)

Coolcat

Was haltet ihr von folgendem Gebilde:

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

nicht viel.

Ich verstehe das nicht. Wozu brauchst du ne andere Instanz der Engine um das Menü zu zeichnen?

miller_m

verstehe das auch nicht so ganz (sinn)
meinst du sowas?

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

Coolcat

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

@miller_m:
Ja ginge auch, aber dann müsste ich das in der Grafikengine hardcoden. Die Grafikengine soll aber möglichst universell sein. Daher diese Konstanten.
Intern ist das dann einfach ein statischer Vektor, eine Map o.ä....

Coolcat

machs doch ganz normal wie es jeder machen würde

miller_m

wäre dann eine art factory?!?!? die halt nur eine instanz rausrückt

Coolcat

wie es jeder machen würde

Und wie würde es jeder machen?

Coolcat

Also eine Factory ist was anderes....

...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.

miller_m

Coolcat schrieb:

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.

Coolcat

@miller_m:
Also ja du bist nah dran... Thx das du dir mühe gibst mich zu verstehen...

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

miller_m

Coolcat schrieb:

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

Coolcat

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

miller_m

Coolcat schrieb:

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.

Coolcat

ok, mag sein

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

Coolcat

Machs wie alle Engines und implementier nen Szenenmanager, dann kannste im Spiel verschiedene Szenenmanager verwenden je nach Status deines Spiels.

und wo genau ist der vorteil von dem hier:

//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.

Coolcat

@gueststar:
Saug dir hier (legal) das erste Kapitel von "Game Programming Gems 1"
http://www.edv-buchversand.de/mitp/chapter.php?cnt=chapter&id=itp-0923&lng=
(ca. 600 kb)

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

Coolcat