Designpatterns werden IMO aber gerade auch in Hobbyprojekten zum Teil rein aus Selbstzweck eingesetzt.
Software wie z.B. Eclipse ist auch deshalb so erfolgreich, weil sie gut designed ist und implementierende Dritthersteller ebenfalls Plugin- basierte Infrastrukturen bieten wie z.B. EMF, die nur durch relativ konsequenten Einsatz von Design Patterns entsprechende Verbreitung finden. Dazu braucht's eine stabile Basis.
Was allerdings unnötig ist (aber sicherlich interessant
):
In einer Anwendung oder von mir aus auch einem Spiel, dessen Code vielleicht 1-3 Leute sehen, zu viel Zeit auf Wiederverwendbarkeit und Erweiterbarkeit zu verschwenden. Dann programmiert man nämlich das Framework, aber nicht mehr das Spiel, und versenkt unzählige Stunden damit sich zu fragen, warum man trotz konsequentem Einsatz von verschiedensten Design-Patterns immer noch irgendwo casten muss...
Oder:
Zum Beispiel die Änderungen durch GameObjects per Event System / Observer Pattern einer Game Instanz mitzuteilen, z.B. um Punkte aufzurechnen. Warum nicht einfach eine shared Instanz eines Structs oder einer Klasse übergeben, der ich solche Ergebnisse direkt mitteile? Oder das Game direkt als Member der GameObjects halten? Weil es nicht
SCHÖN ist? Weil ich
VIELLEICHT in Zukunft noch andere Objekte haben
KÖNNTE, die auf diese Änderungen reagieren sollen? Darf ich Sounds zum Beispiel nicht aus dieser shared class abspielen, weil der Soundmanager (!) da nix zu suchen hat? Ich meine, spielt es denn in diesem Kontext wirklich eine Rolle, wer hier Sounds abspielen darf, mal abgesehen von einem persönlichen Unrechtsempfinden?
Ich persönlich halte Software Architektur für eine ziemliche Bitch. Eine 100% erfolgreiche Planung anhand von Design-Patterns setzt nämlich quasi schon im Vorfeld 100% Kenntniss der Anforderungen an die Software voraus. Das gibt es natürlich so gut wie nie. Software wird also ständig an sich ändernden Anforderungen angepasst, und da kann es dann auch schonmal passieren, dass grundlegende Designänderungen stattfinden (Worst Case). In solchen Fällen hätte man wahrscheinlich mehr Zeit gespart, wenn man ursprünglich quick & dirty runterprogrammiert und danach nach Bedarf refaktorisiert hätte.
Ich hatte Anti- Patterns immer eher als eine Philosophie betrachtet: Nämlich grundsätzlich den Einsatz von Patterns zu hinterfragen und im Zweifel drauf zu verzichten... Naja.
Jedenfalls kenne ich ein paar Hobby- Projekte (inklusive eigener), die auf Grund von Overdesign an ihrer eigenen Sinnlosigkeit erstickt sind
Also anstatt den Einsatz von Gettern/Settern zu diskutieren oder über den Sinn und Unsinn von Singletons zu diskutieren, fände ich es besser, wenn man für sich selbst generelle "Design"- Vorgehensweisen festlegt, da finde ich z.B. die Tips von Tobiking bzgl. der Dependencies gut, da sie auch direkt das Design beeinflussen werden. Ansonsten ist im Endeffekt eher das Ergebnis wichtig. Es ist sicherlich spaßig, sich über ein mies designtes Projekt zu beömmeln, aber wenn es ein FERTIGES Projekt ist, ist es mehr wert, als 100 unfertige, super- designte Projekte zusammen, die nie bis zur Öffentlichkeit durchdringen.
Eine Ausnahme von all diesen Regeln sind halt Projekte wie Libraries oder Projekte, die auf Grund ihrer Erweiterbarkeit ein gut durchdachtes Design benötigen, um dem User sinnvolle und eindeutige Vorgaben zu liefern, wie er mit dem Framework / der Lib zu arbeiten hat. Da darf sich nämlich meistens auch langfristig nichts mehr dran ändern.