Singletons

Page 2 of 3 1 2 3
05/25/2013 16:51 Padmak#16
Welches Spiel ist eigentlich egal, ich meine es so:
Code:
class MainCharacter : public pSingleton<MainCharacter>
{
...
private:
    pInventory* m_inventory;
    pCharacterInfo* m_character_info;
    ...
};
wobei pCharacterInfo halt so Sachen wie Name, Level etc hält. MainCharacter ist dabei der eigene Hauptcharakter, existiert also nur einmal^^
Der Code da ist mehr oder weniger Pseudocode, verdeutlicht aber wie alles aufgebaut ist. Was spricht da dagegen?

Padmak
05/25/2013 16:59 Schlüsselbein#17
Du hast ja sicherlich noch Klasen für Level, einen Controller usw. So wie du es jetzt machst, muss jede Klasse wissen, dass es das Singleton verwenden soll/muss.

Warum nicht einfach dem Controller das Erzeugen überlassen? Dieser erzeugt Level, Maincharakter und evtl. noch die anderen benötigten Klassen und gibt dann zB. Level den Charakter als Parameter beim erzeugen mit.
Damit ist das Level unabhängiger, es muss nicht wissen, wo der Charakter herkommt oder wie er erzeugt wird. Es wird gesetzt und das Level verwendet stumpf diesen Charakter.

Mal etwas praktischer Gedacht: Wenn du jetzt plötzlich ein Multiplayergame möchtest, in dem es mehrere Hauptcharaktere gibt, bricht dir das ganze auseinander, da alles auf dem Singleton aufbaut. Ohne Singleton wären die vorzunehmende Änderungen weniger.
05/25/2013 17:15 Padmak#18
Du stellst mich vor Probleme, der Code ist so richtig aber ich kann dir nicht sagen warum, weil ich nichts verraten darf. Ich bin mir deiner Einwände schon bewusst, es ist aber so vorgegeben und darum sieht auch der Code so aus^^
Ich hab aber noch immer nicht zu 100% verstanden, was das Problem dabei ist, wenn eine Klasse von einer anderen Wissen muss ob sie ein Singleton ist oder nicht. Die Klasse muss doch mitsamt ihrer Funktionen eh bekannt sein, wo ist da der Unterschied? Das einzige, was ich mir noch vorstellen könnte: der benutzenden Klasse die Instanz mitteilen, dann muss die Klasse vom Singleton nix wissen.. wäre das akzeptabler?

Padmak
05/25/2013 17:49 Schlüsselbein#19
Quote:
der benutzenden Klasse die Instanz mitteilen, dann muss die Klasse vom Singleton nix wissen.. wäre das akzeptabler?
Definitiv! Allen anschein nach wird die Klasse hier doch sowieso nicht von _jeder_ anderen Klasse benötigt (wies z.B. bei einem ganz einfachen Logger wäre).
Deshalb nochmal die Frage: Wer braucht alles Zugriff auf den Maincharacter?

Hier nochmal ausführlicher (mal wieder aus meinen Bookmarks) von Stackoverflow:
[Only registered and activated users can see links. Click Here To Register...]
Da auch gerne mal ein Blick auf die weiterführenden Links werfen.
05/25/2013 18:52 Padmak#20
Bookmarked..
Guter Thread, werd ich mir alles mal reinziehen^^
... und meinen Code leicht umbauen
Danke!

Padmak
05/26/2013 01:02 Master674b#21
Um Singletons kommt man nicht herum, auf einer gewissen Ebene müssen sie die Brücke zwischen statisch und dynamisch bilden, deswegen finde ich diese Diskussionen total schwachsinnig.

Ich verfolge da einfach das Prinzip schnell auf ins dynamische, wobei ein Singleton im Prinzip auch nur ein smart-pointer bei mir ist :0
05/26/2013 06:03 dready#22
@master

Die Diskussion als schwachsinning abzutun ist irgendwie hrm.
Natürlich braucht man Singeltons an gewissen Punkten :P
Hat ja hier glaub auch niemand abgestritten, denk es geht Schienenbein hier eher darum das es gerne mal zuviel Verwendet wird, das hat ja nichts damit zu tun das es nicht gebiete gibt wo es eben benutzt werden sollte. Also das es ihm nicht um Stellen geht wo es notwendig ist, sondern dann wenn das Design des ganzen unsauberer ist als nötig und deshalb sowas genutzt wird.

Im Endeffekt ist es doch immer das selbe, Programmierer sind ein faules Völkchen und ein Design ist besser desto besser es in einzelteile aufgesplittet ist.

Es hilft "fremden" Codern den Code schneller zu verstehen, spart damit Zeit, und wo man Zeit spart, spart man Geld. Unabhängier Code lässt sich leichter warten, besser Testen, schneller verstehen. Natürlich ist das in 95% der Fälle nicht umbedingt relevant, in einem Großen Projekt wo x Leute am Code rumwurschteln und strenge Deadlines zu halten haben ist es aber eben Sinnvoll, also warum nicht versuchen es von anfang an so zu machen ?
05/26/2013 15:14 dowhile#23
Quote:
Originally Posted by Master674b View Post
Um Singletons kommt man nicht herum, auf einer gewissen Ebene müssen sie die Brücke zwischen statisch und dynamisch bilden, deswegen finde ich diese Diskussionen total schwachsinnig.

Ich verfolge da einfach das Prinzip schnell auf ins dynamische, wobei ein Singleton im Prinzip auch nur ein smart-pointer bei mir ist :0
Ja, sicher, es gibt auch einige Einsatzorte, in denen die Vorteile von Singletons eindeutig überwiegen. Oft aber eben nicht. Mich würde aber interessieren, an welche Situationen du denkst, wenn du sagst, dass Singletons teilweise unbedingt nötig sind.

Was genau meinst du mit dynamisch?

Ich finde übrigens nicht, dass die Diskussion schwachsinnig ist. Natürlich, man kann vieles mit Singletons lösen, und das funktioniert dann auch. In kleinen Anwendungen, die wir als Hobby-Programmierer (oder zumindest ich) schreiben, ist man meistens eh alleine und muss nur selten wirklich eine Klasse austauschen.
Wenn man so denkt, braucht man aber auch keine Kommentare (kosten Zeit, blähen den Quelltext auf) und generell so gut wie keine Entwurfsmuster ...
05/26/2013 21:29 Master674b#24
Quote:
Originally Posted by dowhile View Post
Ja, sicher, es gibt auch einige Einsatzorte, in denen die Vorteile von Singletons eindeutig überwiegen. Oft aber eben nicht. Mich würde aber interessieren, an welche Situationen du denkst, wenn du sagst, dass Singletons teilweise unbedingt nötig sind.

Was genau meinst du mit dynamisch?

Ich finde übrigens nicht, dass die Diskussion schwachsinnig ist. Natürlich, man kann vieles mit Singletons lösen, und das funktioniert dann auch. In kleinen Anwendungen, die wir als Hobby-Programmierer (oder zumindest ich) schreiben, ist man meistens eh alleine und muss nur selten wirklich eine Klasse austauschen.
Wenn man so denkt, braucht man aber auch keine Kommentare (kosten Zeit, blähen den Quelltext auf) und generell so gut wie keine Entwurfsmuster ...
Dynamisch ist alles was aufm Heap liegt. Irgendwo muss deine Anwendung ja eine Wurzel haben, deswegen bietet sich ein Singleton da an um schnell von statischen Funktionen überzusetzen auf Memberfunktionen.
05/26/2013 22:50 MrSm!th#25
Die Methoden liegen aber nicht mit auf dem Heap, ich hoffe, ich habe dich da falsch verstanden.
05/26/2013 22:57 Master674b#26
Quote:
Originally Posted by MrSm!th View Post
Die Methoden liegen aber nicht mit auf dem Heap, ich hoffe, ich habe dich da falsch verstanden.
Das Objekt aber - "this" liegt auf dem Heap.
05/27/2013 02:20 MrSm!th#27
Und inwiefern bringt das nun Dynamik im Vergleich zu... - ja zu was eigentlich? - rein?
05/27/2013 05:25 Schlüsselbein#28
Quote:
wobei ein Singleton im Prinzip auch nur ein smart-pointer bei mir ist :0
Bitte um genauere Erklärung. Was meinst du damit?

Quote:
Das Objekt aber - "this" liegt auf dem Heap.
In welchem Zusammenhang?

Wieso soll das Singleton irgendwas direkt mit Objekten auf dem Heap zu tun haben? Wenn du einen smart_ptr brauchst, warum benutzt du keinen?
05/27/2013 14:10 Master674b#29
Singletons sind meiner Meinung nach die eleganteste Lösung um überhaupt dynamische Objekte zu erzeugen, ich glaube ihr habt das falsch verstanden. Die dynamischen Objekte brauchen allesamt eine Referenz, die wiederum im Singleton selbst als Objekt gehalten wird.

Das Singleton selbst kann natürlich auch dynamisch sein, sprich je nach Bedarf initialisiere ich hier z.B. den Manager auf DirectX 9 oder 11. Deshalb verwende ich für Singletons an sich auch gerne smart pointer.
05/27/2013 15:47 MrSm!th#30
Du meinst...du speicherst einfach alle dynamischen Objekte in ner Sammelsingleton?
Page 2 of 3 1 2 3