Datenbankzugriffsschicht ohne mit Singletons um sich zu schmeißen?

Na, du kannst natürlich immer statt eines Singletons ein einziges Objekt erzeugen und das dann überall rumreichen. Wenn du dann noch ein paar mehr solcher Objekte hast, hast du überall x Parameter mehr in deinen Methoden und Konstruktoren, da würde ich dann doch irgendwann ein Singleton nehmen. Man muss ja nicht für alle theoretischen Fälle ein Design vorsehen. Mehrere Datenbanken wird wahrscheinlich nicht mal 0.1% aller Anwendungen brauchen.

dot

aaaaaaaaaüö schrieb:

Wenn du dann noch ein paar mehr solcher Objekte hast, hast du überall x Parameter mehr in deinen Methoden und Konstruktoren [...]

Meiner Erfahrung nach ist das nicht so schlimm. Wenn es viele sind ist das nur ein Zeichen dass am Design grundsätzlich was nicht stimmt.

aaaaaaaaaüö schrieb:

Man muss ja nicht für alle theoretischen Fälle ein Design vorsehen. Mehrere Datenbanken wird wahrscheinlich nicht mal 0.1% aller Anwendungen brauchen.

Gut. Aber ich seh keinen Grund diese 0.1% auszuschließen wenn mir das keinen Vorteil bringt!? Design und Implementierung werden durch ein Singleton jedenfalls sicherlich nicht einfacher. Das Singleton bringt nämlich einige nichttriviale Konsequenzen mit sich. Z.B. Initialisierungsreihenfolge, Multithreading (getInstance() gegen Race Condition absichern), Unit-Testing (globaler statischer Zustand), ...

Wie groß sind eigentlich die Teams in denen du programmierst? Wie stellst du sicher, das jeder die "einzelnen" Objekte übergibt und nicht selber falsch erstellt?

dot

aaaaaaaaaüö schrieb:

Wie groß sind eigentlich die Teams in denen du programmierst?

Ich hab bisher noch nie wirklich in größeren Teams gearbeitet, maximal 4 Leute.

aaaaaaaaaüö schrieb:

Wie stellst du sicher, das jeder die "einzelnen" Objekte übergibt und nicht selber falsch erstellt?

Das System zwingt einen doch schon dazu!? Ohne ein Objekt zu übergeben lassen sich die andren Objekte garnicht instanzieren. Ich seh da kein Problem, aber du wirst mir sicher gleich sagen dass mir einfach die Erfahrung fehlt worauf ich natürlich nichts entgegnen kann. Die potentielle Unfähigkeit meiner Teamkollegen ist für mich jedenfalls kein Argument für ein Singleton und ich wüsste nicht was passieren müsste dass sich daran was ändert.

hustbaer

Ist auch etwas seltsam steigende Komplexität (mehrere Objekte die rumgereicht werden müssen), als Argument für Singletons/globale Variablen anzuführen.

Mal ganz abgesehen davon, dass man mehrere Objekte zu einem zusammenfassen kann, wenn sie öfters zusammen gebraucht werden. Soll angeblich manchmal ganz gut funktionieren.

dot schrieb:

aaaaaaaaaüö schrieb:

Wie stellst du sicher, das jeder die "einzelnen" Objekte übergibt und nicht selber falsch erstellt?

Das System zwingt einen doch schon dazu!? Ohne ein Objekt zu übergeben lassen sich die andren Objekte garnicht instanzieren.

Mal ein Pseudocode wie du dir das vorstellst.

main
{
  DatabaseConnection db;
  foo(db);
}

foo( DatabaseConnection db )
{
   Query(db) q;
   q...
}

class Query( DatabaseConnection db )
{
...
}

Was hinder Teammember 46 daran dein Programm so zu erweitern und 2 DatabaseConnections anzulegen?

main
{
  DatabaseConnection db;
  foo(db);

  bar();
}

bar()
{
   DatabaseConnection db;
   foo(db);
}

foo( DatabaseConnection db )
{
   Query(db) q;
   q...
}

class Query( DatabaseConnection db )
{
...
}

Und dann kommen sie zu dir und behaupten deine DatabaseConnection hat einen Bug und speichert manchmal nicht richtig in der DB.

Wann würdet ihr dann überhaupt Singletons verwenden? Garnie?

dot

aaaaaaaaaüö schrieb:

Was hinder Teammember 46 daran dein Programm so zu erweitern und 2 DatabaseConnections anzulegen?

Nichts!?

aaaaaaaaaüö schrieb:

Und dann kommen sie zu dir und behaupten deine DatabaseConnection hat einen Bug und speichert manchmal nicht richtig in der DB.

Mit derart unfähigen Programmierern musste ich bisher zum Glück noch nicht arbeiten. Und selbst wenn rechtfertigt das nicht den Einsatz eines Singleton.

aaaaaaaaaüö schrieb:

Wann würdet ihr dann überhaupt Singletons verwenden? Garnie?

Exakt, zumindest nicht für einen globalen Zustand. Dafür ist und war Singleton nie gedacht (falls dir aufgefallen ist hab ich immer von "Singleton" gesprochen, die "" waren durchaus Absicht). Die Gründe hab ich ja schon genannt. Wenn du noch mehr Gründe wissen willst schau einfach mal hier oder hier

volkard

aaaaaaaaaüö schrieb:

Was hinder Teammember 46 daran dein Programm so zu erweitern und 2 DatabaseConnections anzulegen?

Nichts. Und das ist normalerweise absolut ok.
Was hindert den Programmierer daran, eine zweite Datei zu öffnen?
Klar darf man nicht zweimal zugleich in die selbe Datei schreiben.
Das war aber nie ein Problem.

Falls Du meinst, das Prog dürfe immer nur mit einer Datenbank reden, kannste das mit einem Singleton festmachen. Aber es kann auch sein, daß sich das Team davon eher genervt fühlt, als gut aufgehoben. Würdest Du selber den Schutz brauchen oder wollen? Falls ja, dann mach halt nen Singleton draus.

dot schrieb:

aaaaaaaaaüö schrieb:

Wann würdet ihr dann überhaupt Singletons verwenden? Garnie?

Exakt, zumindest nicht für einen globalen Zustand. Dafür ist und war Singleton nie gedacht (falls dir aufgefallen ist hab ich immer von "Singleton" gesprochen, die "" waren durchaus Absicht).

Die Frage bleibt. Wann würdet ihr dann überhaupt Singletons verwenden? Bis jetzt war ein Singleton für dich für garnichts gedacht.

dot

Korrekt. Potentielle Anwendungsfälle für ein Singleton sind extrem selten und man kann drüber diskutieren inwiefern der Pattern überhaupt den Grundfesten der OOP widerspricht. Ich hab schon viele Singletons gesehen und jeder einzige davon war ein Designfehler. Singleton wird eben ständig als bunte Verpackung für eine globale Variable verwendet. Das ist aber nicht wofür Singleton gedacht ist und nur weil man die globale Variable nichtmehr direkt als solche erkennt ist sie noch lange nicht verschwunden. Die Tatsache dass ein globaler Zugriffspunkt existiert ist eine Konseqzenz aber nicht der Sinn des Singleton Pattern.

volkard schrieb:

aaaaaaaaaüö schrieb:

Was hinder Teammember 46 daran dein Programm so zu erweitern und 2 DatabaseConnections anzulegen?

Nichts. Und das ist normalerweise absolut ok.
Was hindert den Programmierer daran, eine zweite Datei zu öffnen?
Klar darf man nicht zweimal zugleich in die selbe Datei schreiben.
Das war aber nie ein Problem.

Verwendest du private und protected oder programmierst du wie in Python in C++?

dot schrieb:

Korrekt. Es gibt extrem wenige Anwendungen für Singleton und man kann drüber diskutieren inwiefern der Pattern überhaupt den Grundfesten der OOP widerspricht. Ich hab schon viele Singletons gesehen und jeder einzige davon war ein Designfehler. Singleton wird eben ständig als bunte Verpackung für eine globale Variable verwendet. Das ist aber nicht wofür Singleton gedacht ist und nur weil man die globale Variable nichtmehr direkt als solche erkennt ist sie noch lange nicht verschwunden. Die Tatsache dass ein globaler Zugriffspunkt existiert ist eine Konseqzenz aber nicht der Sinn des Singleton Pattern.

Wie kannst du behaupten, du weißt wofür Singletons gedacht sind, wenn du behauptest, dass sie für nichts gedacht sind?

dot

Ich verwende eigentlich ausschließlich private und public, protected nur recht selten und wenn dann auf keinen Fall für Datenmember.

dot

aaaaaaaaaüö schrieb:

Wie kannst du behaupten, du weißt wofür Singletons gedacht sind, wenn du behauptest, dass sie für nichts gedacht sind?

Ich habe nicht behauptet dass Singletons für nichts gedacht sind, nur dass potentielle Anwendungsfälle für ein Singleton extrem selten sind. Woher ich weiß wofür Singletons gedacht sind? Ganz einfach:

Design Patterns, S. 127 schrieb:

Use the Singleton pattern when

There must be exactly one instance of a class [...]

[...]

Mit dem Singleton Pattern drückst du aus dass es eine inhärente Eigenschaft des Typs ist dass es nur eine einzige Instanz geben darf. Genau das sicherzustellen ist der Zweck des Singleton Pattern (hence the name). Und das ist etwas grundlegend Anderes als "ich brauch nur eine Instanz". Und mit globalen Variablen hats noch weniger was zu tun.

Das Problem ist nicht das Singleton Pattern an sich sondern die Tatsache dass es praktisch überall, verhältnismäßig viel zu oft und dabei ständig falsch verwendet wird. Nämlich als "Ersatz" für eine globale Variable.

Tja, das ist genau der Fall den ich beschreiben hab. Wenn es nur eine DatabaseConnection geben darf, damit DatabaseConnection funktioniert, dann mach ich halt ein Singleton draus. Das hat garnichts mit Ersatz für globale Variable zu tun. Da würde ich mal behaupten, dass es eher ein Designfehler ist, diese eine DatabaseConnection genau einmal anzulegen und überall rumzugeben und wenn das einer nicht macht geht es nicht mehr.

dot

aaaaaaaaaüö schrieb:

Wenn es nur eine DatabaseConnection geben darf, damit DatabaseConnection funktioniert [...]

Warum sollte es nur eine DatabaseConnection geben dürfen damit diese funktioniert, klingt irgendwie nach ziemlicher Frickelei!?

Wenn du mich fragst widerspricht das dem Konzept einer DatabaseConnection mir vorzuschreiben wie oft ich zu welcher Datenbank zu verbinden habe. Eine DatabaseConnection soll konzeptuell gefälligst auch einfach nur das sein: Eine Verbindung zu einer Datenbank. Und wenn meine Anwendung nur eine braucht dann macht sie nur eine und wenn sie mit 10 verschiedenen Datenbanken arbeiten will dann macht sie 10. Und wenn diese eine konkrete XYZDatabaseConnection da intern mehrere Verbindungen offen hält und meine Anfragen auf diese verteilt weil dies auf dieser konkreten Verbindung zu diesem konkreten Server in Kombination mit diesem konkreten Datenbanksystem momentan der performanteste Weg ist dann soll sie das bitteschön intern machen. Das ist ihr Job. Von außen interessieren mich solche Implementierungsdetails nicht. Und wenn ich Code hab der mit einer speziellen Datenbank arbeitet dann soll der diese spezielle DatabaseConnection verwenden. Nirgendwo brauch ich da ein Singleton oder gewinne auch nur irgendwas durch die Verwendung eines solchen.

dot schrieb:

aaaaaaaaaüö schrieb:

Wenn es nur eine DatabaseConnection geben darf, damit DatabaseConnection funktioniert [...]

Warum sollte es nur eine DatabaseConnection geben dürfen damit diese funktioniert, klingt irgendwie nach ziemlicher Frickelei!?

Wenn du mich fragst widerspricht das dem Konzept einer DatabaseConnection mir vorzuschreiben wie oft ich zu welcher Datenbank zu verbinden habe. Eine DatabaseConnection soll konzeptuell gefälligst auch einfach nur das sein: Eine Verbindung zu einer Datenbank. Und wenn meine Anwendung nur eine braucht dann macht sie nur eine und wenn sie mit 10 verschiedenen Datenbanken arbeiten will dann macht sie 10.

Ob es eine oder 10 Datenbanken gibt legt man in Pflichtenheften oder ähnlichem fest. Außerdem hatten wir gerade vorher gesagt, dass es nur eine geben soll und du wolltest die dann lieber überall herrumreichen, statt ein Singleton zu verwenden. Davon bin ich aus gegangen. Wieso sollte das "Überall rumreichen" Design überhaupt irgendwas bringen, wenn man, warum auch immer, plötzlich zwei Datenbanken braucht? Dann musst du überall zwei DatabaseConnections als Parameter einführen, wenn du ein irgendeiner unteren Funktion beide Datenbanken brauchst.

volkard

aaaaaaaaaüö schrieb:

volkard schrieb:

aaaaaaaaaüö schrieb:

Was hinder Teammember 46 daran dein Programm so zu erweitern und 2 DatabaseConnections anzulegen?

Nichts. Und das ist normalerweise absolut ok.
Was hindert den Programmierer daran, eine zweite Datei zu öffnen?
Klar darf man nicht zweimal zugleich in die selbe Datei schreiben.
Das war aber nie ein Problem.

Verwendest du private und protected oder programmierst du wie in Python in C++?

Du willst doch gar nicht dazulernen, sondern nur provozieren.