spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Man kann, vor allem im Hobby-Bereich, sowohl durch zu viel, als auch durch zu wenig Design(-entscheidungen) Probleme bekommen. Bei einem schlechten Design geht es eher in die Richtung, dass spätere Änderungen zu aufwendig werden, bei einem "zu guten" Design kann es eher in die Richtung gehen, dass durch den Aufwand für das Design die Motivation leidet.

Auch sollte man Diskussionen über Software Design differenziert betrachten: Eine konkrete Vorgehensweise in einem konkreten Fall kann durchaus weniger sauber als eine andere sein, allerdings sollte das nie eine direkte Aussage darüber sein, ob diese Vorgehensweise deswegen zu meiden ist. Das Singleton ist sehr leicht zu verstehen und wird deswegen als sehr einfach in der Verwendung angesehen. Wenn man also Zeit sparen will, dann kann ein Singleton in der Hinsicht einen Vorteil mit sich bringen. (Das Singleton ist an dieser Stelle nur ein Beispiel, es lässt sich ebenfalls auf die Events übertragen. Ich würde Singletons auch grundsätzlich nicht empfehlen, aber das ist eine andere Sache...)

Als Faustregel bei Entscheidungen zwischen "schön" und "schnell" mache ich es so, dass ich einen Schritt voraus denke. Auch wenn ich etwas noch dynamischer und abstraker machen könnte, dann mache ich das nicht unbedingt, sondern nur so, dass ich sozuagen einen Schritt/Erweiterung das nächste mal leicht machen kann. Und wenn es dann soweit ist, entscheide ich ob ich das Design nochmal ändere und noch mehr abstrahiere oder ich es für den Moment mal so lasse und die Erweiterung "schnell" reinpacke.

Das schöne ist, dass man dann nicht gleich aufgemschmissen ist und ein Haufen refactoring/umschreiben muss, wenn etwas neues kommt. Zusätzlich hat man dann allenfalls die Zeit das ganze noch "schöner" zu machen. Ebenfalls verliert man upfront nicht zu viel Zeit mit overengineering wenn ein Teil sowieso nie mehr angefasst wird oder wieder komplett raus fliegt.

Zitat von »LetsGo«

Eben nicht. Das ist doch der Punkt. Natürlich kann man es übertreiben aber in der Regel ist das Problem eher, dass es eben nicht durchdacht ist und man am Schluss ewig lang um ein Problem herumcoden muss, weil man es nicht gleich richtig gemacht hat.
Du hast aber schon Recht, dass man in solchen Diskussionen immer mehr designed als in der Realität notwendig

Schwierig schwierig. Ich hatte gerade in meinen drölfzig toten Projekten oft das Problem, zu komplex designed zu haben und TROTZDEM am Ende teilweise komplett refaktorisieren zu müssen. Da hast du die Zeit dann irgendwie doppelt verschwendet. Aber das ist natürlich auch zum Teil einfach Unfähigkeit meinerseits und zum anderen Teil auch der Unwille, sich später mit dem eher ungeliebten Thema Softwarearchitektur noch auseinanderzusetzen. Als Hobby tendiert man leider dazu, die Dinge schleifen zu lassen, wenn es ungemütlich wird.

Zitat von »drakon«

Als Faustregel bei Entscheidungen zwischen "schön" und "schnell" mache ich es so, dass ich einen Schritt voraus denke.

Das basiert aber natürlich auch auf Erfahrung. Man bekommt nach einiger Zeit ja so ein Bauchgefühl für die Arten der Implementierung. Ich muss zwar hauptberuflich gottseidank keine großen Softwaresysteme planen, sondern eigentlich "nur" vorhandene Architekturen erweitern (Eigene Plugins auf Eclipse RCP Basis mit verschiedenen Eclipse Technologien, z.B. EMF, GEF und wat weiß ich), aber man fuchst sich da halt ein und implementiert die "leichten Patterns" wenn nötig unbewusst. Allerdings muss ich sagen, dass der Code, den ich in der Firma schreibe zum Teil unter aller Sau ist, aber er funktioniert und ist rechtzeitig fertig. Die Ansprüche aus meinen Hobbyprojekten dürfte ich hier garnicht stellen, obwohl es streng genommen anders herum sein müsste .

visitor pattern halte ich für den größten Mist überhaupt. Habe derzeit große Freude damit.

Zitat von »Fireball«

visitor pattern halte ich für den größten Mist überhaupt. Habe derzeit große Freude damit.

Stichwort Debugging?

Zitat von »Fireball«

visitor pattern halte ich für den größten Mist überhaupt. Habe derzeit große Freude damit.

Nun, wenn alle Sprachen double-dispatch könnten, bräuchte man das Pattern nicht.

Das Pattern hat schon seine Daseinsberechtigung, aber wenn man neue Elemente hinzufügt, dann muss man alle Besucher anpassen. Deswegen sollte man es nur einsetzen, wenn dies wirklich selten der Fall ist.