Naming Convention "ManagerKlasse"

[NewSoftzzz]

l'abra d'or schrieb:

Als ganz normale Klasse? Nur weil du in deinem Programm nur eine Instanz brauchst, schreibst du dir keinen Singleton.

????

Wie denn dann wenn ich nur eine Instanz brauche? Als globale Variable oder wie (wobei natürlich ein Singleton prinzipiell nix anderes als eine globale Variable ist)?

Was ist so schlimm an einem Singleton und was gibt es für Alternativen?

Die Users Klasse hält bei mir alle User Objekte in einem Vector (somit ständig im RAM) und hat Funktionen, die dann über alle User iteriert und anschließend Nutzdaten ausgibt (beispielsweise eine Highscore Liste, eine Who is Online Liste usw).

mfg, René~

[l'abra d'or]

NewSoftzzz schrieb:

Was ist so schlimm an einem Singleton und was gibt es für Alternativen?

Globale Variablen sollte man meiden.

Die Users Klasse hält bei mir alle User Objekte in einem Vector (somit ständig im RAM) und hat Funktionen, die dann über alle User iteriert und anschließend Nutzdaten ausgibt (beispielsweise eine Highscore Liste, eine Who is Online Liste usw).

Das ist noch immer kein Grund für ein Singleton. Schau dir doch an was ein Singleton ist. Das ist ein Design Pattern, das für die Situation gedacht ist, dem User zu verbieten mehr als eine Instanz zu erstellen, Zugriffe geschehen von allen Übersetzungseinheiten aus genau auf diese eine Instanz.
Und selbst die Benutzung ein und der selben Instanz über mehrere ÜEs ist noch kein Argument für ein Singleton. Wofür gibt es Referenzen?

[NewSoftzzz]

Ist ja schön und gut, aber du hast mir IMMER noch nicht erklärt was die Alternative ist..

Ich möchte ALLE User im RAM haben. (Klasse 'User'). Und jede User Instanz soll natürlich nur einmal im RAM Liegen. Wie speichere ich jetzt alle User im RAM wenn nicht in einem Singleton?

mfg, René~

[theta]

Du erzeugst halt nur eine Instanz von Users, welche dann die User Objekte enthält. Fertig.

[NewSoftzzz]

theta schrieb:

Du erzeugst halt nur eine Instanz von Users, welche dann die User Objekte enthält. Fertig.

Das ist doch ein Singleton?

[l'abra d'or]

NewSoftzzz schrieb:

Das ist doch ein Singleton?

Nein, das ist eine Klasse, von der halt grad nur eine Instanz erzeugt wird.

[theta]

Nein. Ein Singleton ist ein Mechanismus, der sicherstellt, dass genau eine Instanz erstellt wird. Du darfst das aber auch von beliegbigen Klassen nur eine Instanz erzeugen.. auch wenns nicht erzwungen wird. Und genau das macht doch hier sinn.

[Nexus]

NewSoftzzz schrieb:

Das ist doch ein Singleton?

Seit wann ist etwas, von dem man nur eine Instanz erstellt, automatisch ein Singleton?

[NewSoftzzz]

Ihr wollt mir also sagen, ich soll kein Singleton benutzen, weil ich die User Klasse auch als Singleton benutzen kann ohne dass ich es zum Singleton mache.. Hä?

static Users &Instance()
{
	static Users staticUsers;
	return staticUsers;
}

Das ist doch genau das was ihr sagt, ich habe EINE Instanz der Klasse Users, die ich als Referenz rausgebe.

Ich verstehe immer noch nicht warum ich jetzt KEINEN Singleton benutzen soll? Nur damit ich theoretisch auch mehrere Instanzen von Users erstellen kann, was aber gar keinen Sinn macht?

Und wenn ich keinen Singleton erzeuge, wo speicher ich dann eigentlich die eine Instanz von der ihr immer redet?

mfg, René~

[theta]

[NewSoftzzz]

theta schrieb:

Statt so blöd zu gucken erklär mir lieber mal was du meinst?

Ein kurzes Code Beispiel von Users als NICHT Singleton und der Zugriff darauf wäre ganz nett.

mfg, René~

[Nexus]

NewSoftzzz schrieb:

Ich verstehe immer noch nicht warum ich jetzt KEINEN Singleton benutzen soll? Nur damit ich theoretisch auch mehrere Instanzen von Users erstellen kann, was aber gar keinen Sinn macht?

Lies doch nochmals die Posts in diesem Thread. Das Singleton-Pattern hat gewisse Nachteile, deren In-Kauf-Nehmen sich nicht immer auszahlt.

Nur weil etwas nur einmal instanziiert werden soll, rechtfertigt das noch kein Singleton. Aber das wurde ja schon gesagt.

[NewSoftzzz]

Nexus schrieb:

Nur weil etwas nur einmal instanziiert werden soll, rechtfertigt das noch kein Singleton. Aber das wurde ja schon gesagt.

Ja, aber ich kenne die Alternative immer noch nicht. Solange ich nicht verstehe, was die Alternative zum Singleton ist kann ich auch nicht die Nachteile verstehen? Also wie gesagt, wie wäre es mit nem kurzen Codebeispiel oder ein Link zu ner Erklärung was ihr meint?

Das Einzige was ich mal gesehen habe war folgendes:

main.cpp

User user;

andere.cpp

extern User user;

Und das soll soviel besser als ein Singleton sein?

mfg, René~

[l'abra d'or]

NewSoftzzz schrieb:

theta schrieb:

Statt so blöd zu gucken erklär mir lieber mal was du meinst?

Ein kurzes Code Beispiel von Users als NICHT Singleton und der Zugriff darauf wäre ganz nett.

Man redet gegen eine Wand... Auch du könntest ETWAS ausführlicher werden.
EIn Singleton VERBIETET das Erstellen von mehr Instanzen. Wenn du das aber nicht VERBIETEN willst, macht ein SIngleton einfach keinen Sinn!
Ohne Singleton programmieren solltest du eigentlich können.
Und ohne genaueren ANgaben kann man auch nciht sagen, wo du deine Users abspeichern sollt.
Trotzdem ein Stück Code, der garantiert nicht kompiliert, da ich das jetzt nicht im Compiler test...

class User {
  // irgend was
};
class Users {
    std::vector<User> userList;
};

class IWantUsersA {
    Users& u;
public:
    IWantUsersA(Users& u) : u(u) {}
};

class IWantUsersB {
    Users& u;
public:
    IWantUsersB(Users& u) : u(u) {}
};

int main() {
    Users u;
    IWantUsersA a(u);
    IWantUsersB b(u);
}

Users muss natürlich nicht in main erzeugt werden, das kann auch in einer beliebigen anderen klasse passieren.

[Nexus]

NewSoftzzz schrieb:

Ja, aber ich kenne die Alternative immer noch nicht.

theta schrieb:

Du erzeugst halt nur eine Instanz von Users, welche dann die User Objekte enthält. Fertig.

Diese Instanz muss ja nicht unbedingt global sein.

Und hier noch ein paar Gründe gegen globale Variablen.

[NewSoftzzz]

Hi,

Erstmal danke für das Codebeispiel.

l'abra d'or schrieb:

EIn Singleton VERBIETET das Erstellen von mehr Instanzen. Wenn du das aber nicht VERBIETEN willst, macht ein SIngleton einfach keinen Sinn!

Ich *WILL* es aber verbieten! Die existierenden User sind ein globaler Zustand, da macht eine globale Instanz Sinn. Ich kann nicht an irgendeiner Codestelle einen User löschen und an einer anderen Stelle mit dem gelöschten User weiterarbeiten.

Was spricht jetzt noch gegen ein Singleton?

mfg, René~

[NewSoftzzz]

Vielleicht sollte ich noch erwähnen, dass meine Applikation ein Echtzeitserver mit Scheduler und (potenziell) Tausenden Netzwerkclients ist?

mfg, René~

[theta]

NewSoftzzz schrieb:

Vielleicht sollte ich noch erwähnen, dass meine Applikation ein Echtzeitserver mit Scheduler und (potenziell) Tausenden Netzwerkclients ist?

mfg, René~

Ja, sicher. Das ändert typischweise alles. Benutze dann am besten Singleton-Mediator-Strategy-Factory-Builder mit Pipes&Filters (und nicht zu vergessen nimm unbedingt Visitor).

Edit
Oh vergessen.. und mach das als Sigleton.

[Nexus]

NewSoftzzz schrieb:

Vielleicht sollte ich noch erwähnen, dass meine Applikation ein Echtzeitserver mit Scheduler und (potenziell) Tausenden Netzwerkclients ist?

Lieber nicht. Das "Ich hatte einen MMORPG Server programmiert, also eine Echtzeitapplikation. Dort gab es pro Sekunde ca. 10.000 - 100.000 solcher Methodenaufrufe und die Umstellung von c-strings auf static const std::strings hat was gebracht." konnten wir nämlich auch nicht ganz ernst nehmen.

[brotbernd]

NewSoftzzz schrieb:

Was spricht jetzt noch gegen ein Singleton?

Die Frage beim Singleton ist, was denn dafür spricht, und ob diese Argumente schwerer wiegen als alle bekannten Nachteile globaler Instanzen.
Deine Anforderungen sprechen, wie schon mehrfach argumentiert noch nicht für ein Singleton.

// user.hpp
class User;
class UserPredicate;
class Users
{
  void AddUser(const User& user);
  void DeleteUser(const UserPredicate& p);
  const User& FindFirstUser(const UserPredicate& p) const;

private:
  std::vector<User> users_;
};

// usergui.hpp
class UserGUI
{
public:
  void ShowUser(const Users& users) const;
  void ShowUser(const Users& users, const UserPredicate& p) const;
};

// main.cpp
int main()
{
  Users user;
  user.Add(User("NewSoftzzz"));

  UserGUI ui;
  ui.ShowUser(user, NamePredicate("NewSoftzzz"));

  return 0;
}

Welchen Vorteil hat hier ein Singleton in user.hpp? Ich sehe keinen. Ich sehe nur den Nachteil, dass usergui.cpp sich ganz einfach durch ein #include "user.hpp" nicht konstanten Zugriff auf alle User holen kann und lustig darin rum editieren kann. In der oben gezeigten Lösung entscheidet main (oder wo auch immer die Users Instanz gespeichert ist), der GUI nur eine konstante Referenz der User zu übergeben. Die UI soll was anzeigen, mehr nicht.