 |
JLI Spieleprogrammierung
|
| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
David
Super JLI'ler
Alter: 39
Anmeldedatum: 13.10.2005
Beiträge: 315
Medaillen: Keine
|
 Verfasst am: 17.06.2007, 11:17 Titel: |
 |
|
| Noch ein Wort zum Singletonpattern. Singletons sind grundlegend nicht besser als globale Variablen und somit ebenfalls "böse". Darum sollten das Pattern mit allergrößter Vorsicht, wenn überhaupt, eingesetzt werden. |
|
| Nach oben |
|
 |
The Lord of Programming
Living Legend
Alter: 37
Anmeldedatum: 14.03.2003
Beiträge: 3122
Medaillen: Keine
|
| Verfasst am: 17.06.2007, 13:17 Titel: |
|
|
| David hat Folgendes geschrieben: | | Singletons sind grundlegend nicht besser als globale Variablen [...] |
Hmm, gewissermaßen schon. Man sollte nicht vergessen, dass man bei Singletons immerhin noch ein ähnliches Muster hat wie wenn man die globalen Variablen in einen namespace steckt. Beides Mal sind die Variablen nicht "einfach"(= ohne das "Gehuddel" davor, d.h. entweder _global:: oder CLASSmysingleton::Instance(). ) erreichbar. Namenskonflikten ist somit vorgebeugt.
Was genau ist denn deiner Meinung nach an Singletons (oder auch an namespaces?) so böse?
_________________
www.visualgamesentertainment.net
Current projects: RDTDC(1), JLI-Vor-Projekt, Tetris(-Tutorial), JLI-Format
(1) Realtime Developer Testing and Debugging Console
Anschlag, Anleitung zum Atombombenbau, Sprengkörper...
Hilf Schäuble! Damit er auch was findet... |
|
| Nach oben |
|
|
manu
Super JLI'ler
Alter: 35
Anmeldedatum: 09.03.2006
Beiträge: 327
Wohnort: allgäu (DE)
Medaillen: Keine
|
| Verfasst am: 17.06.2007, 13:47 Titel: |
|
|
| The Lord of Programming hat Folgendes geschrieben: |
Was genau ist denn deiner Meinung nach an Singletons (oder auch an namespaces?) so böse? |
warscheinlich das andere es gut finden  |
|
| Nach oben |
|
|
David
Super JLI'ler
Alter: 39
Anmeldedatum: 13.10.2005
Beiträge: 315
Medaillen: Keine
|
| Verfasst am: 17.06.2007, 13:48 Titel: |
|
|
Hi!
Namespaces sind nicht "böse" oder "schlecht". Hab ich nie behauptet. Namespaces sind toll um Namenskonflikte zu vermeiden und Code besser zu organisieren. Was zum Thema Namespaces nicht toll ist, ist die using Direktive von C++. Diese halt ich für ein "Misskonstrukt", aber das ist ein anderes Thema.
Am Singletonpattern gibts einiges zu kritisieren. Zum einen das bereitstellen globaler Daten, was im Grunde nichts anderes ist als wenn man globale Variablen verwendet. Es macht in diesem Aspekt der Funktionalität von Singletons überhaupt keinen Unterschied ob ich eine globale Variable oder ein Singletonobjekt verwende (=> ja, Singletons haben noch andere Funktionalitäten).
Das Argument mit den Namespaces find ich nicht haltbar. Du greifst ja direkt auf die Klasse zu um per statischer Methode (schonmal schlecht) eine Instanz der Klasse zu bekommen. Das hat nichts mit dem Sinn von Namespaces zu tun.
| CPP: | extern foo bar;
// irgendwo anders
void blubb()
{
bar.xyz = 150;
}
|
| CPP: | class foo : public singleton
{};
// irgendwo anders
void blubb()
{
foo::instance().xyz = 150;
}
|
Nur weil da der :: Operator verwendet wird ist das nicht Sinngleich mit einem in einen Namespace verpackten Objekt.
Desweiteren ist es nicht unbedingt sinnvoll globale Daten Progarmmweit zu teilen, warum auch? Außerdem werden Abhängigkeiten zwischen Objekten so versteckt und sind nicht auf einen Blick sichtbar, was die Arbeit mit solchem Code enorm verkompliziert. Gerade in Teams.
Alles in allem gibt es meist eine bessere Designlösung als globale Objekte.
Der zweite Grund Singletons zu verwenden ist, das immer nur ein Objekt der Klasse existieren kann (was Singletons von globalen Variablen unterscheidet). Ein Singleton kümmert sich allerdings schon um das bereitstellen der globalen Instanz, der Klasse eine zweite Zuständigkeit zu geben verletzt die SRP-Regel für OO-Design.
Auch hier gibt es im Normalfall eine bessere Alternative, in Form einer Factory z.B.
Dann gibt es Probleme mit statischen Objekten. Statische Objekte ermöglichen das tragen von Status (plural) über den gesamten Programmverlauf hin, was schlecht ist! Beim Unit testen gibts da die tollsten Probleme wenn die Tests nicht unabhängig voneinander sind und das ist durch verwendung statischer Objekte eben gefährtet. Es macht kein Sinn "Module" zu testen wenn die Tests abhängig von anderen Gegebenheiten sind.
Ein weiterer Kritikpunkt ist die extrem enge Abhängigkeit zwischen Klassen die Singletons fordern. Es wird damit unmöglich Objekte durch z.B. "mock objects" auszutauschen, wieder für unit testing. Außerdem muss ein Singleton immer ein konkretes Objekt sein (wie globale Variablen auch), d.h. es ist nicht möglich eine Abstrakte Klasse zu erstellen und verschiedene Spezialisationen zu übergeben, der Austausch von Funktionalität ist also auch nicht gewährleistet.
Was also tun? Im Grund ist die gängigste Lösung die übergabe von Referenzen an die Objekte, oder Methoden (zur not eine globale Referenz) um die Implementierungsdetails nicht global sichtbar- und möglicherweise austauschbar zu machen.
Auf jedenfall ist die Verwendung von Singletons, genau wie von globalen Objekten, ein krasser Designmangel der (meistens) ausgebügelt werden kann. Also merke: Singletons nur dann verwenden wenn es wirklich keine bessere Lösung gibt. Und dann auch nur sehr, sehr vorsichtig!
| manu hat Folgendes geschrieben: | | The Lord of Programming hat Folgendes geschrieben: |
Was genau ist denn deiner Meinung nach an Singletons (oder auch an namespaces?) so böse? |
warscheinlich das andere es gut finden |
Danke für die hochqualifizierte Meinung... |
|
| Nach oben |
|
|
AFE-GmdG
JLI MVP
Alter: 45
Anmeldedatum: 19.07.2002
Beiträge: 1374
Wohnort: Irgendwo im Universum...
Medaillen: Keine
|
| Verfasst am: 17.06.2007, 20:44 Titel: |
|
|
Ein weiteres Problem von Singletons ist die nicht vorhersagbare Initialisierungsreihnfolge. Dies wird besonders dann extrem, wenn mehrere Singletonklassen verwendet werden, die sich gegenseitig referenzieren.
Desweiteren sind Singletons in aller Regel nicht vernünftig löschbar - also delete funktioniert nicht richtig oder es wird bei nächstbester gelegenheit gleich wieder eine Instanz erstellt.
Auch böse:
| CPP: | if(singletonKlasse.GetInstance() != NULL) {
delete singletonKlasse.GetInstance();
} |
FALLS es nämlich zu diesem Zeitpunkt noch keine Instanz gab, wird eine erzeugt, nur weil der Vergleich aufgerufen wurde...
_________________
| CPP: | float o=0.075,h=1.5,T,r,O,l,I;int _,L=80,s=3200;main(){for(;s%L||
(h-=o,T= -2),s;4 -(r=O*O)<(l=I*I)|++ _==L&&write(1,(--s%L?_<(L)?--_
%6:6:7)+\"World! \\n\",1)&&(O=I=l=_=r=0,T+=o /2))O=I*2*O+h,I=l+T-r;} |
|
|
| Nach oben |
|
|
xardias
JLI Master
Alter: 38
Anmeldedatum: 28.12.2003
Beiträge: 804
Wohnort: Palo Alto, CA
Medaillen: Keine
|
| Verfasst am: 17.06.2007, 21:05 Titel: |
|
|
An der Stelle vielleicht ein Hinweis zu einer Alternative zur Verwendung von Singletons bei objekten welche "global" verfügbar sein sollen.
Ein Konzept welches ich Großtenteils von Java Inversion of Control Containern abgeschaut habe, es macht etwas mehr arbeit, aber es fördert modulares objektorientiertes entwickeln.
Grundsätzlich verwenden die meisten hier glaube ich Singletons für Systemklassen wie Wrapperklassen zum Zugriff auf Eingabegeräte, Ressourcen, oder Ausgabegeräte.
Diese lassen sich auch schön zu Modulen zusammenfassen, Module sind in diesem Fall Klassen welche instanzen von allen sog. Services beinhalten die das Modul bereitstellt. Beispiel:
| Code: |
namespace opengl
{
[...]
class RenderWindow
{
public:
virtual void addRenderListener(RenderListener* listener) = 0;
virtual void removeRenderListener(RenderListener* listener) = 0;
virtual int getWidth() = 0;
virtual int getHeight() = 0;
[...]
};
class OpenGLModule: public Module
{
private:
RenderWindow* _renderWindow;
[...]
public:
static const char* getModuleName(){ return "OpenGLModule"; };
virtual void initialize();
virtual void configure();
RenderWindow* getRenderWindow(){ return _renderWindow; }
[...]
};
}
|
Dieser code ist alles was ein anderes Modul (z.B. ein Modul dass die spiellogik enthält) kennen muss um darauf zuzugreifen. D.h. man ist implementierungsunabhängig und kann das Modul auch relativ einfach aus einer DLL laden.
Abhängigkeiten zwischen den Modulen kann man einfach auflösen indem man Instanzen der Module übergibt, oder das ganze über eine Modul Registrierung macht, was dann in etwa so aussieht:
| Code: | class TestModule: public Module
{
public:
static const char* getModuleName(){ return "TestModule"; };
virtual void initialize()
{
opengl::OpenGLModule* openGLModule = getDependency<opengl::OpenGLModule>();
opengl::RenderWindow* renderWindow = openGLModule->getRenderWindow();
// erstelle irgendwelche services und übergib renderWindow als parameter
}
}; |
So hat man für den groben Überblick alle Abhängikeiten in Abhängigkeiten zwischen Modulen abstrahiert und im kleinen hat man die genauen abhängikeiten der Services in eine datei ausgelagert.
Ein weiteres konzept was ich aber noch nicht geschafft habe elegant einzubauen sind sog configuration points (siehe z.b. apache hivemind). Jedes modul kann listen oder maps bereitstellen in denen andere module werte eintragen können. Dies können z.b. listen von listenern sein, oder registrierungen für bestimmte events, oder listen für das Strategy Pattern. So macht man vorhandene Module leicht erweiterbar.
Wenn irgendwer dieses kranke zeug interessant findet kann ich den code mal bereitstellen und etwas detailiertere informationen dazu. Ich arbeite mitlerweile ganz gerne so, vor allem da man meiner erfahrung nach serviceorientiert mehr auf logische aufgabenteilungen und ein sauberes interface achtet. |
|
| Nach oben |
|
|
The Lord of Programming
Living Legend
Alter: 37
Anmeldedatum: 14.03.2003
Beiträge: 3122
Medaillen: Keine
|
| Verfasst am: 18.06.2007, 20:15 Titel: |
|
|
Gut, verstehe ich. Allerdings sind da ein paar Dinge, bei denen ich (bei meinem aktuellen Wissensstand?) nicht zustimmen kann...
| David hat Folgendes geschrieben: | | Das Argument mit den Namespaces find ich nicht haltbar. Du greifst ja direkt auf die Klasse zu um per statischer Methode (schonmal schlecht) eine Instanz der Klasse zu bekommen. Das hat nichts mit dem Sinn von Namespaces zu tun. |
Ich finde dein Argument nicht haltbarer als meines. Mag sein, dass man per statischer Methode drauf zugreift und dass das schlecht ist(ich muss zugeben, dass ich mich in dem Bereich noch nicht ausreichend weitergebildet habe). Dennoch finde ich es auf das Argument der Namenskonflikte bezogen Jacke wie Hose ob man jetzt einen namespace oder einen Singleton verwendet. Natürlich heißt der gleiche Operator nicht, dass das intern genau gleich abläuft. Trotzdem ist für mich in dieser Hinsicht entscheidend, dass man bei beidem nicht direkt zugreift, sondern indirekt über Verwendung des Operators. Genau das ist das Argument der Namespaces: Die Variablen werden in einen separaten "Space" abgekapselt, um genau diesen ungehemmten Zugriff zu verhindern und die Variablen selbst hinter einem Identifier(=Name des namespaces bzw. Name der Singletonklasse) zu verstecken.
| David hat Folgendes geschrieben: | Desweiteren ist es nicht unbedingt sinnvoll globale Daten Progarmmweit zu teilen, warum auch? Außerdem werden Abhängigkeiten zwischen Objekten so versteckt und sind nicht auf einen Blick sichtbar, was die Arbeit mit solchem Code enorm verkompliziert. Gerade in Teams.
Alles in allem gibt es meist eine bessere Designlösung als globale Objekte. |
Klar, oft ist es sinnlos. In anderen Fällen wiederum verkompliziert es den Code enorm, wenn man ständig Referenzen von oder Zeiger auf Variablen quer durch das gesamte Programm von Funktion zu Funktion reichen muss. Was ist daran kompliziert, per namespace/Singleton auf globale Variablen zuzugreifen, deren Abhängigkeit genau darin "definiert ist", dass sie eben ziemlich über allem stehen und deshalb überall bekannt sein sollen?
| David hat Folgendes geschrieben: | | Der zweite Grund Singletons zu verwenden ist, das immer nur ein Objekt der Klasse existieren kann (was Singletons von globalen Variablen unterscheidet). |
Hmm...hat jemand gesagt, dass Singleton==globale Variable? Ich dachte, die Diskussion dreht sich um den Vergleich von globalen Variablen und Membern der Singletonklasse. Von globalen Variablen können genauso viele gleichnamige Objekte existieren wie sie es innerhalb einer Singletonklasse können: genau eines. Oder habe ich den Nebensatz in Klammern falsch verstanden?
| David hat Folgendes geschrieben: | | Singletons nur dann verwenden wenn es wirklich keine bessere Lösung gibt. Und dann auch nur sehr, sehr vorsichtig! |
Ich möchte betonen, dass ich dem zustimme. Ich fand nur ein paar deiner Punkte für diskussionswürdig 
_________________
www.visualgamesentertainment.net
Current projects: RDTDC(1), JLI-Vor-Projekt, Tetris(-Tutorial), JLI-Format
(1) Realtime Developer Testing and Debugging Console
Anschlag, Anleitung zum Atombombenbau, Sprengkörper...
Hilf Schäuble! Damit er auch was findet... |
|
| Nach oben |
|
|
David
Super JLI'ler
Alter: 39
Anmeldedatum: 13.10.2005
Beiträge: 315
Medaillen: Keine
|
| Verfasst am: 18.06.2007, 20:35 Titel: |
|
|
| The Lord of Programming hat Folgendes geschrieben: |
| David hat Folgendes geschrieben: | | Das Argument mit den Namespaces find ich nicht haltbar. Du greifst ja direkt auf die Klasse zu um per statischer Methode (schonmal schlecht) eine Instanz der Klasse zu bekommen. Das hat nichts mit dem Sinn von Namespaces zu tun. |
Ich finde dein Argument nicht haltbarer als meines. Mag sein, dass man per statischer Methode drauf zugreift und dass das schlecht ist(ich muss zugeben, dass ich mich in dem Bereich noch nicht ausreichend weitergebildet habe). Dennoch finde ich es auf das Argument der Namenskonflikte bezogen Jacke wie Hose ob man jetzt einen namespace oder einen Singleton verwendet. Natürlich heißt der gleiche Operator nicht, dass das intern genau gleich abläuft. Trotzdem ist für mich in dieser Hinsicht entscheidend, dass man bei beidem nicht direkt zugreift, sondern indirekt über Verwendung des Operators. Genau das ist das Argument der Namespaces: Die Variablen werden in einen separaten "Space" abgekapselt, um genau diesen ungehemmten Zugriff zu verhindern und die Variablen selbst hinter einem Identifier(=Name des namespaces bzw. Name der Singletonklasse) zu verstecken. |
Ich weiß nicht genau wieso du namespaces und Singletons in Beziehung bringst. Ein Namespace erlaubt es Namen doppelt zu vergeben. Ein Singleton nicht.
| The Lord of Programming hat Folgendes geschrieben: |
| David hat Folgendes geschrieben: | Desweiteren ist es nicht unbedingt sinnvoll globale Daten Progarmmweit zu teilen, warum auch? Außerdem werden Abhängigkeiten zwischen Objekten so versteckt und sind nicht auf einen Blick sichtbar, was die Arbeit mit solchem Code enorm verkompliziert. Gerade in Teams.
Alles in allem gibt es meist eine bessere Designlösung als globale Objekte. |
Klar, oft ist es sinnlos. In anderen Fällen wiederum verkompliziert es den Code enorm, wenn man ständig Referenzen von oder Zeiger auf Variablen quer durch das gesamte Programm von Funktion zu Funktion reichen muss. Was ist daran kompliziert, per namespace/Singleton auf globale Variablen zuzugreifen, deren Abhängigkeit genau darin "definiert ist", dass sie eben ziemlich über allem stehen und deshalb überall bekannt sein sollen? |
Es geht nicht im komplizierten Code sondern um die Sichtbarkeit von Abhängigkeiten. Wenn Singletons verwendet werden ist diese Sichtbarkeit nicht gegeben und um Abhängigkeiten festzustellen muss die Implementation durchforstet werden, was nicht besonders ideal ist. Gerade, wie gesagt, bei Teams die an einem Projekt arbeiten macht es keinen Sinn das jeder jedes Modul auswendig kennen muss.
| The Lord of Programming hat Folgendes geschrieben: |
| David hat Folgendes geschrieben: | | Der zweite Grund Singletons zu verwenden ist, das immer nur ein Objekt der Klasse existieren kann (was Singletons von globalen Variablen unterscheidet). |
Hmm...hat jemand gesagt, dass Singleton==globale Variable? Ich dachte, die Diskussion dreht sich um den Vergleich von globalen Variablen und Membern der Singletonklasse. Von globalen Variablen können genauso viele gleichnamige Objekte existieren wie sie es innerhalb einer Singletonklasse können: genau eines. Oder habe ich den Nebensatz in Klammern falsch verstanden? |
Niemand sagte das. Ich hab zu Beginn in den Raum geworfen das Singletons eigentlich globale Variablen sind, mit einem kleinen Unterschied.
Aber von einem Objekt können mehrere globale Instanzen bestehen (es sei denn man regelt die Objekterzeugung anders). |
|
| Nach oben |
|
|
xardias
JLI Master
Alter: 38
Anmeldedatum: 28.12.2003
Beiträge: 804
Wohnort: Palo Alto, CA
Medaillen: Keine
|
| Verfasst am: 19.06.2007, 00:39 Titel: |
|
|
Ich sehe es ebenfalls so, dass Singletons das Problem nicht viel eleganter lösen als globale variablen es tun.
In prozeduraler programmierung war es üblich globale variablen zu verwenden, da man sonst wirklich in teufels küche gekommen wenn man jeder funktion sämtliche benötigten objekte übergeben müsste.
Aber bei gutem objekt orientierten design sollte man meiner meinung nach globale objekte (seien es nun singletons oder globale variablen) so gut es geht meiden.
Anfangs mögen abhängigkeiten unter singleton klassen noch überschaubar sein, aber ab einer gewissen komplexität wird das ganze einfach unübersichtlich.
Wo ist das Problem einer Klasse die eine spezielle aufgabe übernimmt die benötigten Instanzen zu übergeben die sie zur erfüllung ihrer aufgabe benötigt? So sieht man auf einen blick was diese klasse tut und womit sie es tut.
Ich will Singletons ja nicht ganz ablehnen, aber ich würde sie nur in ganz seltenen Fällen verwenden. Eine Logging Klasse würde mir als Beispiel einfallen, aber da hört es auch schon langsam auf.
Vielleicht muss man hier einfach zwischen striktem Objekt Orientierten (modularen) Programmieren und "Praktisch orientiertem" Programmieren unterscheiden (Was auf einen mix aus prozeduraler und objekt orientierter programmierung hinnausläuft). Was davon jetzt das wahre ist muss jeder für sich entscheiden, aber in ersterem haben Singletons recht wenig existenzberechtigung. |
|
| Nach oben |
|
|
The Lord of Programming
Living Legend
Alter: 37
Anmeldedatum: 14.03.2003
Beiträge: 3122
Medaillen: Keine
|
| Verfasst am: 19.06.2007, 16:22 Titel: |
|
|
| David hat Folgendes geschrieben: | | Ich weiß nicht genau wieso du namespaces und Singletons in Beziehung bringst. Ein Namespace erlaubt es Namen doppelt zu vergeben. Ein Singleton nicht. |
Was kann ich hier bei Namespaces doppelt vergeben, was ich bei Singletons nicht kann?
| CPP: | int var1=10;
int var2=20;
namespace _namespace1
{
int var1;
int var1; //error C2086: Neudefinition
int var2;
}
namespace _namespace2
{
int var1;
int var1; //error C2086: Neudefinition
int var2;
}
class Singleton1
{
Singleton1() {}
public:
static Singleton1& Singleton(void) { static Singleton1 singleton; return singleton; }
~Singleton1() {}
int var1;
int var1; //error C2086: Neudefinition
int var2;
};
class Singleton2
{
Singleton2() {}
public:
static Singleton2& Singleton(void) { static Singleton2 singleton; return singleton; }
~Singleton2() {}
int var1;
int var1; //error C2086: Neudefinition
int var2;
}; |
| CPP: | //WinMain...
//Zugriff auf "globale Variablen", die in Namespaces/Singletons versteckt sind
_namespace1::var1=30;
Singleton1::Singleton().var1=40;
_namespace2::var1=50;
Singleton2::Singleton().var1=60; |
Vielleicht meinst du auch etwas anderes, aber genau davon rede ich. Durch Verwendung eines Namespace/Singletons ist es möglich, mehrere Variablen mit dem Namen "var1" oder "var2" zu haben, auch wenn diese beiden Namen schon vorher vergeben sein sollten(durch Einbindung eines Headers z.B.). Namenskonflikte sind somit zwischen den Singletons/Namespaces/globalen Variablen nicht möglich.
_________________
www.visualgamesentertainment.net
Current projects: RDTDC(1), JLI-Vor-Projekt, Tetris(-Tutorial), JLI-Format
(1) Realtime Developer Testing and Debugging Console
Anschlag, Anleitung zum Atombombenbau, Sprengkörper...
Hilf Schäuble! Damit er auch was findet... |
|
| Nach oben |
|
|
David
Super JLI'ler
Alter: 39
Anmeldedatum: 13.10.2005
Beiträge: 315
Medaillen: Keine
|
| Verfasst am: 19.06.2007, 17:14 Titel: |
|
|
Nein, es geht nicht um die Instanz sondern um das Singleton selbst:
| CPP: | class Singleton;
class Singleton; // zack!
|
Und hier nimmst du halt auch wieder Namespaces:
| CPP: | namespace foo
{
class Singleton;
}
namespace bar
{
class Singleton;
}
|
|
|
| Nach oben |
|
|
The Lord of Programming
Living Legend
Alter: 37
Anmeldedatum: 14.03.2003
Beiträge: 3122
Medaillen: Keine
|
| Verfasst am: 19.06.2007, 19:06 Titel: |
|
|
Hmm, sorry, aber ich verstehe nicht, wieso das ein Argument gegen Singletons sein soll. Dieses Verhalten ist doch völlig normal und hat nichts mit Singletons zu tun. Genauso wird folgendes zu einem Kompilerfehler führen:
| CPP: | class foo;
class foo; |
Verstehst du denn, was genau ich gemeint habe?
_________________
www.visualgamesentertainment.net
Current projects: RDTDC(1), JLI-Vor-Projekt, Tetris(-Tutorial), JLI-Format
(1) Realtime Developer Testing and Debugging Console
Anschlag, Anleitung zum Atombombenbau, Sprengkörper...
Hilf Schäuble! Damit er auch was findet... |
|
| Nach oben |
|
|
David
Super JLI'ler
Alter: 39
Anmeldedatum: 13.10.2005
Beiträge: 315
Medaillen: Keine
|
| Verfasst am: 19.06.2007, 19:19 Titel: |
|
|
| The Lord of Programming hat Folgendes geschrieben: | Hmm, sorry, aber ich verstehe nicht, wieso das ein Argument gegen Singletons sein soll. Dieses Verhalten ist doch völlig normal und hat nichts mit Singletons zu tun. Genauso wird folgendes zu einem Kompilerfehler führen:
| CPP: | class foo;
class foo; |
Verstehst du denn, was genau ich gemeint habe? |
Ja, ich weiß was du meinst. Allerdings ist das kein Argument gegen Singletons sondern einfach ein Gegenargument zu deinem Argument für Singletons! |
|
| Nach oben |
|
|
The Lord of Programming
Living Legend
Alter: 37
Anmeldedatum: 14.03.2003
Beiträge: 3122
Medaillen: Keine
|
| Verfasst am: 20.06.2007, 12:59 Titel: |
|
|
Lass dir doch nicht alles aus der Nase ziehen
Fest steht, dass Singletons wie du an meinem Codebeispiel sehen kannst, wie auch Namespaces Namenskonflikten vorbeugen können. Genau das ist ein entscheidendes Argument, wieso globale Variablen so schlechtgeredet werden. Da dieses Argument weder bei Singletons noch bei Namespaces angewendet werden kann, sind sowohl Singletons als auch Namespaces in dieser Hinsicht besser als "reine" globale Variablen.
Genau das hab ich in meinem ersten Post zu diesem Thema geschrieben und darauf beläuft sich meine Argumentation.
Bist du jetzt immer noch der Meinung, deine unerläuterten Anmerkungen/Andeutungen seien hierzu ein Gegenargument?
Dann bitte erläutere es auch
_________________
www.visualgamesentertainment.net
Current projects: RDTDC(1), JLI-Vor-Projekt, Tetris(-Tutorial), JLI-Format
(1) Realtime Developer Testing and Debugging Console
Anschlag, Anleitung zum Atombombenbau, Sprengkörper...
Hilf Schäuble! Damit er auch was findet... |
|
| Nach oben |
|
|
David
Super JLI'ler
Alter: 39
Anmeldedatum: 13.10.2005
Beiträge: 315
Medaillen: Keine
|
| Verfasst am: 20.06.2007, 13:05 Titel: |
|
|
Ja, bin immer noch der Meinung. Singletons erlauben nur ein Objekt, darum ist es absolut irrelevant ob Namenskonflikte auftreten können oder nicht. Wo es eine Rolle spielen könnte wären evtl Typendefinitionen, aber dann haben wir das gleiche Problem wie bei globalen Variablen.
Noch eine Anmerkung: Besser als Singletons oder globale Variablen sind globale Referenzen!! |
|
| Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
Powered by phpBB © 2001, 2005 phpBB Group
Deutsche Übersetzung von phpBB.de |
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Medaillen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
