spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Stilfrage hin oder her.
Wenn man nicht in mehrere Fenstern rendern will, warum sollte man sich dann nicht die lästige Tipparbeit sparen?

Weil static-Design immer Mist und ein Zeichen für schlechtes Design ist.

Wieso ist es schlechtes Design, wenn man sich über sein Design Gedanken gemacht hat und nach nachvollziehbaren Gründen so entschieden hat?

Zitat von »BlueCobold«

Weil static-Design immer Mist und ein Zeichen für schlechtes Design ist.

Finde ich nicht - In einigen Fällen macht es durchaus Sinn.

Z.B. Ein Resourcenmanager: hierbei würde es den Code tierisch unübersichtlich machen, wenn man jedem Klassenkonstruktor einen Zeiger auf den Resourcenmanager übergeben müsste - Das würde auch auf das selbe hinauskommen, da die Variable trotzdem von überall bearbeitet werden kann => für den mehraufwand hat man überhaupt keinen Gewinn. Wenn man dann noch einen Meyers-Singleton nutzt, ist man immer auf der sicheren Seite.

mfg CBenni::O

Zitat von »BlueCobold«

Weil static-Design immer Mist und ein Zeichen für schlechtes Design ist.

Das kommt denke ich auf die Definition von "gutem Design" an. Für mich ist gutes Design ein Design, welches mit möglichst wenig Aufwand das Ziel erreicht und dabei allen Anforderungen entspricht.

Ob das Singleton Pattern an sich auf schlechtes Design deutet ist da denke ich eher Geschmackssache. Und über den kann man bekanntlich streiten, sollte man aber nicht

Zitat von »CBenni::O«

Z.B. Ein Resourcenmanager: hierbei würde es den Code tierisch unübersichtlich machen, wenn man jedem Klassenkonstruktor einen Zeiger auf den Resourcenmanager übergeben müsste - Das würde auch auf das selbe hinauskommen, da die Variable trotzdem von überall bearbeitet werden kann => für den mehraufwand hat man überhaupt keinen Gewinn. Wenn man dann noch einen Meyers-Singleton nutzt, ist man immer auf der sicheren Seite.

Nein, falsch.
Ich kann Dir immer prima Situationen nennen, in denen es mit nur einem statischen Ressourcen-Manager nicht funktioniert. Den Fehler habe ich aber auch schon gemacht und werde ihn nicht nochmal machen. Ich sehe auch kein Problem in einer Methode einen zusätzlichen Parameter zu übergeben. Tipp-Faulheit des Programmierers ist das zwar ein Grund, aber keine Entschuldigung.

Nein, xardias, gutes Design ist wartbar. Singletons sind nie wartbar und oft lässt sich aufgrund eines Singletons eine Software nicht mehr auf neue Anforderungen anpassen.

Zitat von »BlueCobold«

Nein, xardias, gutes Design ist wartbar. Singletons sind nie wartbar und oft lässt sich aufgrund eines Singletons eine Software nicht mehr auf neue Anforderungen anpassen.

Natürlich kann man auch Singletons warten.

Wenn die Anforderungen überschaubar sind und die Flexiblität auf neue Anforderungen einzugehen selbst keine Anforderung ist, dann spricht IMO nichts dagegen sowas wie Singletons zu verwenden. Nicht jede Software muss auf Jahre supported und gewartet werden.

Das Problem ist, dass man vor lauter Flexiblität, Wiederverwendbarkeit, Wartbarkeit und Erweiterbarkeit schnell das Ziel aus den Augen verlieren kann.

Ich wiederhole mich nur ungerne. Wenn ich mein Design durchdacht habe dann kann ich auch nur Singletons benutzen.

Gutes Design zeichnet sich dadurch aus das es durchdacht ist. Nicht das es OOP und Wartbar und Skalibar ist. Wenn das nicht gefordert ist muss ich mich darum nämlich nicht kümmern.

Wie Ihr meint. Irgendwann werdet Ihr auch mal erwachsen und es selber rausfinden.

Aber natürlich mag es *kleine* Software geben, die Singletons nutzen kann. Ich habe auch schon solche geschrieben, keine Bange. Generell sollte man aber gleich lernen ordentlich zu arbeiten und nicht mit Singletons aus Faulheit rumzuschlampen. Jedes Singleton-Design lässt sich meiner Meinung nach durch Dependency-Injection sauberer lösen.
Und das ist nicht nur meine Meinung, sondern das werdet Ihr auch von großen Software-Häusern und Professoren hören.
Aber ja, es dauert etwas, bis man das eingesehen hat.

@Môr:
Durchaus richtig. Das trifft nur leider fast nie zu. Speziell bei Hobby-Entwicklern ist die Verwendung von Singletons üblich und die Entscheidung oft aus falschen Gründen getroffen worden.
Fakt bleibt, dass man sie (fast) nie braucht, aber immer aus Schreib-Faulheit eingesetzt werden. Speziell in einem *Framework*, dass dazu gedacht ist, dass man für *neue* Dinge benutzt, ist die Wahl eines Singletons eine ganz schlechte Idee, da nie vorher klar ist, wofür das Framework mal verwendet wird und ob dann das Single-Design überhaupt funktioniert. Und da sind wir plötzlich wieder bei der Skalierbarkeit.

Ich habe in meinem Framework auch ein Singleton. Allerdings für die Application-Class. Diese wird nur einmal pro Spiel verwendet und daher war hier ein Singleton sinvoll.
Daher denke ich auch nicht das dies die Wartbarkeit oder Flexibilität einschränkt. Hier erreiche ich genau das was ich erreichen wollte. Alle Informationen die für das gesamte Spiel gelten können da drin vereint werden. Man muss sich nur vorher Gedanken machen. Dann ist gegen ein Singleton nichts einzuwenden.

Komisch wird es nur wenn sie überhand nehmen.