Naming Convention "ManagerKlasse"

[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é~

[brotbernd]

NewSoftzzz schrieb:

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

Dann übergibst du halt eine nicht konstante Referenz.

NewSoftzzz schrieb:

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.

Und was spricht dagegen?
Klar, ein Singleton spart wie eine globale Variable etwas Schreibarbeit und Überlegung. Es ist auf den ersten Blick einfach bequem, eine global verfügbare Instanz von etwas zu haben, wo man einfach draufrumarbeiten kann. Schreibarbeit ist bei einem längeren Projekt aber die geringste Arbeit.

Aus deinem 3 Post in diesem Thread schließe ich, dass Du wohl noch nicht ein einziges mal mit einem Singleton gearbeitet hast. Es sollte dir vielleicht komisch vorkommen, dass Du Dich trotzdem mit Deiner Meinung so auf diese Muster versteifst, während dir hier viele erfahrene C++ler davon abraten, zumindest in dem Kontext, den Du bisher hier durchblicken liest. Das ein Framework die Modellierung eines Singletons vorschreibt, kann ich mir nicht vorstellen.

[NewSoftzzz]

brotbernd schrieb:

Dann übergibst du halt eine nicht konstante Referenz.

Wenn aber wieder jede Action eine nicht konstante Referenz zu der Instanz der Users Klasse hat, dann seh ich wiederum keinen Unterschied mehr zum Singleton.

brotbernd schrieb:

Aus deinem 3 Post in diesem Thread schließe ich, dass Du wohl noch nicht ein einziges mal mit einem Singleton gearbeitet hast.

Wurde dir in deiner Kindheit nicht beigebracht keine Vorurteile zu haben?

Ich arbeite schon lange mit Singletons und mein aktuelles Projekt (>20k Zeilen Code) hat auch mehrere und bisher hatte ich noch nie ein Problem damit.

Ob ich jetzt über "Instance()" auf die nicht konstante Referenz der Users Instanz zugreife oder ob meine Action Klasse als Member Variable eine nicht konstante Referenz zu der Users Instanz hat... Ich kann einfach den Unterschied nicht erkennen!

mfg, René~

[l'abra d'or]

NewSoftzzz schrieb:

Ob ich jetzt über "Instance()" auf die nicht konstante Referenz der Users Instanz zugreife oder ob meine Action Klasse als Member Variable eine nicht konstante Referenz zu der Users Instanz hat... Ich kann einfach den Unterschied nicht erkennen!

Ob ich entscheide wer Schreibzugriff bekommt, oder sich jeder überall über instance() Schreibzugriff holen kann (ungefragt, ungeschützt!) ist doch ein immenser Unterschied! Aus der Sicht der Action-Klasse ist es natürlich egal...

[brotbernd]

NewSoftzzz schrieb:

brotbernd schrieb:

Aus deinem 3 Post in diesem Thread schließe ich, dass Du wohl noch nicht ein einziges mal mit einem Singleton gearbeitet hast.

Wurde dir in deiner Kindheit nicht beigebracht keine Vorurteile zu haben?

Wurde dir in deiner Kindheit nicht beigebracht was das Wort Vorurteil bedeutet? Ein Vorurteil zu haben, wäre z.B. die Meinung zu vertreten, jeder der grüne Haare hat und so dumm argumentiert hätte noch nie ein Singleton implementiert. Ich habe einfach nur aus einer Frage, die ziemliche Unsicherheiten zeigt geschlossen, dass du mit Singleton keine Erfahrungen hast. Das war wohl falsch. Ist doch total egal. Mir geht das sowas vom am *** vorbei wie viele Zeilen Code du schon geschrieben hast. Von mir aus kannst du jede Funktion in ein Singleton schreiben, was geht mich das an. Hier geben die nur alle gut gemeinte Ratschläge. Über diese kannst du entweder nachdenken oder sagen "Nein danke, ich mach das anders".

[NewSoftzzz]

brotbernd schrieb:

Ich habe einfach nur aus einer Frage, die ziemliche Unsicherheiten zeigt geschlossen, dass du mit Singleton keine Erfahrungen hast.

Das ist auch ein Vorurteil. Wikipedia dir "Vorurteil"!

mfg, René~

[l'abra d'or]

NewSoftzzz schrieb:

brotbernd schrieb:

Ich habe einfach nur aus einer Frage, die ziemliche Unsicherheiten zeigt geschlossen, dass du mit Singleton keine Erfahrungen hast.

Das ist auch ein Vorurteil. Wikipedia dir "Vorurteil"!

Nein, das läuft unter "Erfahrung".

// edit: aber eigentlich sind wir hier seit der dritten Antwort am Thema (-> naming convention!) vorbei...

[NewSoftzzz]

l'abra d'or schrieb:

Nein, das läuft unter "Erfahrung".

Rechtsgerichtete Menschen haben üblicherweise auch "Erfahrung" mit unhöflichen und kriminellen Ausländern und trotzdem ist es ein Vorurteil, wenn sie Ausländer mit unhöflich oder kriminell verbinden *seufz*.

mfg, René~

[DerKuchen]

Godwin hat wieder zugeschlagen!

Zum eigentlichen Thema:

Wenn es nicht anders geht, würde ich das Teil UserManager nennen.

[NewSoftzzz]

DerKuchen schrieb:

Wenn es nicht anders geht, würde ich das Teil UserManager nennen.

Hey vielen vielen dank für einen konstruktiven Beitrag zum Threadthema

Ja, UserManager hatte ich mir auch schon überlegt, aktuell bin ich bei Users, aber das ist leicht mal zu verwechseln mit User, deswegen hab ich ja diesen Thread überhaupt erst geöffnet.

Wenn hier keine andere Idee mehr kommt (anscheinend gibt es ja keine anderen guten gebräuchlichen Namen für sowas) werd ich das dann mal auf UserManager umbenennen.

mfg, René~