spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Builder und Visitor sind bei mir regelmäßig zu finden.

Factory habe ich schon oft benutzt, insbesondere wenn man zur Laufzeit eine DLL lädt und diese neue Arten von Objekten bereitstellt (Plug-in).

Du hast scheinbar (wie viele andere auch immer wieder) das Problem von der falschen Seite aus angegangen.
Es hört sich für mich zumindest so an wie "ich hab tolle Patterns, weiß aber nicht, wo ich sie einsetzen soll". Du suchst also nach einem Problem für deine Lösung

Erst wenn du ein Problem lösen willst kannst du gucken, ob das nicht schon mal getan wurde (denn groß etwas anderes sind Patterns ja nicht. Öfter auftauchende Probleme können halt mit dem gleichen Muster behoben werden)

Factory ist ja eigentlich ein Klassiker, den man immer wieder benötigt. Was ich noch einigermaßen häufig verwende, ist Decorator. Eine prima Möglichkeit, bestehenden Objekten kleine Funktionalitäten oder Eigenschaften hinzuzufügen (z.B. Logging). Das Observer-Pattern benötige ich ebenfalls häufiger in der Webentwicklung, wenn man verschiedene Teile der Seite, die das gleiche Objekt mit unterschiedlichen Viewmodels abbilden, synchron halten will. Dependency Injection steht bei mir ebenfalls hoch im Kurs, vor allem wenn die Anwendung an sich bereits sehr abstrakt gehalten ist.

In der Praxis habe ich allerdings schon häufiger erlebt, dass ein paar "ganz Schlaue" die Verwendung von Designpattern und einen hohen Abstraktionsgrad deutlich übertrieben haben. Es bringt halt auch nicht viel, wenn ich super lesbaren und den SOLID-Prinzipien entprechenden Quellcode habe, dafür das Synchronisieren von 40.000 Artikeln aber 8 Tage dauert statt 8 Minuten, nur weil da mit Generika, Reflection und Factories nur so um sich geworfen wurde. Hier wird meiner Meinung nach zu oft das Kundenbedürfnis und die Benutzbarkeit der Applikation vernachlässigt. Natürlich kann man das nicht pauschalisieren, aber ich habe leider schon in zu vielen Projekten gesehen, dass zu theoretische Entwicklung zulasten von Performance geht. SOA ist da ebenfalls ein Kandidat, wenn man die einzelnen Bestandteile zu granular macht. Im Beispiel mit den Artikeln von oben hat man sich dafür entschieden, das Synchronisieren, Mergen, und Validieren von Artikeln, sowie das Generieren von Artikelnummern alles als einzelne Webservices zu designen, immer alles artig abstrakt und mit Reflection, und schon dauert so ein Sync mit 40.000 Artikeln 8 Tage. Insofern bin ich immer sehr vorsichtig, wenn irgendwelche frisch Studierten ohne Praxiserfahrung (PS: Ich darf sowas sagen, ich habe selber studiert ) mit Designpattern um sich werfen, das ist nämlich auch nicht immer der heilige Gral.

Also nicht dass wir uns hier missverstehen: Ich will nicht pauschal gegen Designpattern und Abstraktion stänkern, ich verwende das selbst ebenfalls, ich will nur sagen, dass diese Muster OFT nur den Punkt Code-Ästhetik und Wartbarkeit/Lesbarkeit bedienen, aber nicht immer die Lösung eines fachlichen oder technischen Problems

Benutz mal die Forensuche, zu dem Thema gibt es schon einige Threads. Vielleicht findest du da noch interessante Infos für dich. Ansonsten nutze ich teilweise die hier genannten und zusätzlich schon mal Strategy und State. Ansonsten gibt es viele interessante Pattern. Proxy, Command und Interpreter sind Patterns die man nicht unbedingt oft benötigt, die aber gut helfen können. Observer ist etwas was man teilweise schon mal benutzt (manchmal vielleicht ohne es zu wissen).
Wenn dich das Thema interessiert, ich hab mir im Studium "Entwurfsmuster von Kopf bis Fuß" gekauft und da öfter im Zug drin gelesen. Hab dann natürlich ein paar Patterns nach programmiert und teilweise in meinen Projekten verwendet. Am Anfang neigt man dazu mit Patterns um sich zu schmeißen und mit der Zeit lernst du dann wann so ein Pattern sinnvoll sein kann und wann nicht. Ich denke das bringt einen schon irgendwo weiter da du eben etwas dabei lernst.

Zitat von »Sylence«

Du hast scheinbar (wie viele andere auch immer wieder) das Problem von der falschen Seite aus angegangen.
Es hört sich für mich zumindest so an wie "ich hab tolle Patterns, weiß aber nicht, wo ich sie einsetzen soll". Du suchst also nach einem Problem für deine Lösung

Im Prinzip war das bei mir genau so. Schlimm ist das wie ich finde aber erst mal nicht. Solange man nicht bei der Arbeit bei wichtigen Projekten mit so einem Quatsch anfängt und sich zu Hause privat austobt darf man ja auch gern auf die Nase fallen. Und wie gesagt man lernt was dabei. Hinterher siehst du dann selbst ein dass Patterns kein Allheilmittel sind, hast aber hoffentlich verstanden wie du mit Patterns an Probleme ran gehen kannst. Bei mir ist es zum Beispiel so dass ich halt einige Patterns kenne und eben auch schon mal testweise verwendet habe und wenn dann ein Fall kommt wo mir so ein Pattern eben helfen könnte dann fällt mir (hoffentlich) ein dass ich da ja schon etwas fertiges kenne was ich zumindest als Vorbild nehmen kann.

Mein Vorschlag wäre also erst mal ein paar Patterns anzusehen und ruhig mal damit rum zu spielen um selbst Vor- und Nachteile zu sehen.

Kann auch diese Buch empfehlen, welches es komplett im Netz gibt.
http://gameprogrammingpatterns.com/contents.html
Du kannst es dir aber zum Beispiel auch auf deutsch bei Amazon kaufen

Im Grunde ermöglichen Designpatterns nur über häufig vorkommende Strukturen zu sprechen(Deswegen haben manche Patterns auch mehr als einen Namen). Man gab ihnen einen Namen um besser kommunizieren zu können und Neulingen zu zeigen, wie man bestimmte Probleme geschickt löst.

Also... Schau sie dir an, überlege dir einmal was man damit umsetzen könnte und denke nicht weiter drüber nach. Sobald du ein Problem hast, das sich mit einem entsprechenden Pattern lösen lässt wirst du wahrscheinlich sowieso selbst drauf kommen.

Jedes Design Pattern wurde als Lösung für ein bestimmtes Problem entworfen, z.B. das Singleton Design Pattern, wenn man nur eine Instanz der Klasse haben will und es keine weitere Instanz der Klasse geben darf.

In Java wäre folgendes ein Singleton Design Pattern:


Hier noch ein Beispiel, wie man die Instanz nutzt: