Naming Convention "ManagerKlasse"

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

[NewSoftzzz]

Das Problem ist, dass ich ein Framework benutze und IoC, dadurch ist ein Singleton ganz praktisch sonst müsste ich das Framework umprogrammieren um dort immer eine Referenz / einen Pointer auf die Users Klasse durchzureichen..

mfg, René~

[theta]

Das Problem ist, dass ich ein Framework benutze und IoC, dadurch ist ein Singleton ganz praktisch

Da erschliesst sich mir der Zusammenhang leider nicht...

[NewSoftzzz]

theta schrieb:

Da erschliesst sich mir der Zusammenhang leider nicht...

Wie gesagt, durch das IoC habe ich einen gewissen Kontext, der enthält jetzt nur den Request, den Response und die Action. Wenn ich jetzt auf die Users Klasse nicht als Singleton zugreifen wollen würde, müsste ich mir eine Referenz dazu irgendwo reinbasteln, entweder in die Request Klasse, in die Response Klasse oder in die Action Klasse.

Desweiteren gibt es ja Actions die nicht konstanten Zugriff auf die Users brauchen, beispielsweise wenn sich ein neuer User registriert.

mfg, René~