Wie wenden Sie Entwurfsmuster an?

Question

Aus der Sicht eines Buches könnte man sagen, dass Muster x in Szenario y anwendbar ist, aber ich möchte hier ein wenig tiefer gehen. Hier sind also meine Fragen:

1. Wann entscheiden Sie zum ersten Mal, dass Sie Design Patterns verwenden werden? Entscheiden Sie sich alle für Entwurfsmuster, bevor Sie programmieren?
2. Gibt es irgendwelche DPs, die Sie anwenden, nachdem Sie mit der Codierung fertig sind (kleine Refactorings)? Wenden Sie DP an, während Sie den Code pflegen?
3. Welche Entwurfsmuster werden bei der Entwicklung überwiegend angewendet?
4. Was sind die DPs, die Sie anwenden, während Tweaking/Refactoring Code?
5. Gibt es irgendwelche Hinweise im Code (technische, nicht funktionale), die darauf hindeuten, dass Sie einen DP anwenden sollten (z. B. zu viele ifs, doppelte Abfertigung, Multithreading)? Wenn ja, könnten Sie die DPs und ihre Catchpoints nennen?
6. Benutzen Sie irgendwelche Micro-DPs, die Ihnen ein gutes Gefühl bei dem von Ihnen geschriebenen Code geben (auch wenn andere Sie dafür hassen :p)?

Bearbeiten:
Ich möchte hinzufügen, dass ich DPs durch "Head First Design Patterns" gelesen habe und obwohl es eines der besten Bücher ist, um das Muster zu verstehen. Ich glaube nicht, dass ich in der Lage war, die Pizza-Beispiele auf reale Szenarien zu übertragen.

Ich denke, dass dies eines der einflussreichsten Bücher über DV ist, aber wir können immer noch ein Buch haben, das die verschiedenen beliebten Geschäftsszenarien aufzählt, die ein bestimmtes Muster neben diesem Muster erfordern. Dieses Wissen ist meiner Meinung nach noch weitgehend implizit. Ein solches Buch wäre ein sehr gutes Nachschlagewerk, finden Sie nicht auch :))

Answer 1

1. Es kommt darauf an, wie Sie den Code schreiben. Wenn es sich um ein großes Projekt handelt, entscheide ich mich vor der Programmierung. Wenn ich dann mit dem Schreiben des Codes beginne und mir Stellen auffallen, an denen Entwurfsmuster verwendet werden sollten, überarbeite ich den Code.

2. Ja, wie bereits erwähnt.

3. in 99,99 % der Fälle: Fabrik-Muster , Singleton (Wie jeder verwende ich es an vielen Stellen, weil es einfach zu implementieren ist, und in der Praxis neige ich dazu, es beim Refactoring des Codes zu entfernen). Dann: Objekt-Pool (wenn ich Ressourcen habe, die ich wiederverwenden möchte - einige meiner Projekte sind Spiele und ich brauche eine gute Verwaltung der Ressourcen), Strategy und Template Method (weil sie großartig für die Entkopplung sind und den Zweck erfüllen, den Code einfach zu erweitern). Dann ist der Adapter etwas, das man verwendet, wenn man eine Bibliothek verwenden möchte, ohne sich auf sie zu verlassen (Entkopplung).

4. Dasselbe wie oben, wenn ich sie noch nicht benutzt habe. Es funktioniert auch in umgekehrter Weise. Wenn ich keinen Grund finde, ein Entwurfsmuster zu verwenden, lasse ich es weg oder überspringe es beim Schreiben des Codes (das passiert ständig mit Singleton und von Zeit zu Zeit mit Factories. Manchmal verwende ich eine Fabrik, die auch ein Singleton ist, um mir die Objekte zu liefern, die eigentlich Singletons sein sollten; ich bin mir nicht sicher, ob das klug ist, aber es funktioniert für mich).

5. Der einzige Codehinweis, den ich mir vorstellen kann, ist die Anzahl der Verweise auf eine Klasse. Sie können auch PMD , jDepend y Regeln für die Architektur um die Stellen zu erkennen, an denen die Klassen zu viele Abhängigkeiten enthalten. Ich bin mir nicht sicher, ob dies ein Tipp zum Programmieren ist. In der Entwurfsphase und nicht nur dort, wenn Sie sich für ein Entwurfsmuster entscheiden, denken Sie einfach an die Vorteile. Ich habe festgestellt, dass Software Gestaltungsprinzipien sind extrem wichtig, um zu verstehen, wann und warum man ein Entwurfsmuster (nicht) verwenden sollte, aber sie sind vielen Programmierern, die mit Entwurfsmuster .

6. Ich bin mir nicht sicher, was Sie mit Micro DP meinen. Ich versuche, DPs nur dann einzusetzen, wenn ich Gründe dafür finde und wenn die Vorteile größer zu sein scheinen als die Probleme. Ich vermeide den übermäßigen Einsatz, weil man dadurch Zeit mit der Implementierung und Wartung von Factory Patterns verliert, statt mit echter Software.

Answer 2

Zwei gute Bücher, die sich mit dem Thema wie y wenn (nicht) zu verwenden sind Design Patterns:

• Musterschraffur (von John Vlissides von der GoF)
• Refactoring nach Mustern (von Josh Kerievsky)

Answer 3

Ich glaube, dass zumindest diejenigen, die Design Patterns neu erlernen, dazu neigen, ein Pattern zu sehr anzuwenden; wenn man einen Hammer hat, beginnt alles wie ein Nagel auszusehen. Ein besserer Weg ist es, die Alternativen für eine API und ihre jeweiligen Vorteile und Kompromisse zu betrachten und dann die jeweils geeignete auszuwählen. Ein Entwurfsmuster ist eher eine terminologische Hilfe, die es den Entwicklern ermöglicht, effektiv zu vermitteln, was sie tun, als dass es einen Leitfaden dafür liefert, wie man Code schreiben sollte. Das heißt, einige Dinge wiederholen sich im Code, und es ist einfacher, Ihrem Kollegen zu sagen, dass Sie eine Fabrik verwendet haben, als zu erklären, dass Sie ein Objekt hatten, das Sie weitergegeben haben und das andere Objekte erzeugt hat...., aber nur weil es den Begriff der Fabriken gibt, heißt das nicht, dass Sie versuchen sollten, alles, was Sie sehen, zu einer Fabrik zu machen. Ist das sinnvoll?

Answer 4

Ein Entwurfsmuster beschreibt eine allgemeine, wiederverwendbare Lösung für ein wiederkehrendes Problem in einem bestimmten Kontext. Sie wenden ein Muster an, wenn Sie ein oder mehrere Entwurfsprobleme identifizieren, die ein Muster lösen kann. Dies kann während des ursprünglichen Entwurfs, während der Codierung, während der Wartung usw. geschehen. Es gibt kein absolutes Rezept, IMO.

Siehe auch

• Schreiben von Software-Mustern
• Muster in Kurzform

Answer 5

1 & 2

Ich halte es für den falschen Ansatz, sich entweder blind für ein Lieblingsmuster zu entscheiden oder erst zu programmieren und dann nach einem bekannten Muster umzugestalten. Wenn man ein Problem sieht, muss man die Ähnlichkeit zu anderen Problemen erkennen, die mit bekannten Mustern gelöst werden können.

Muster sind kein Kochbuch für den Erfolg; sie sind eine Faustregel. Die Lektüre von Fallbeispielen in einem Buch über Muster kann Ihnen helfen, Probleme zu erkennen und Sie vor dem einen oder anderen Fehltritt bewahren.

3: Welche Muster vorherrschen, hängt sehr stark von der Domäne ab. Zustandsmuster, Proxies und Fassaden sind bei Anwendungen, die viel mit anderen Systemen kommunizieren, sehr verbreitet. GUI-Anwendungen haben andere Anforderungen, usw.

In meiner Branche (Bankwesen): Ich sehe eine Menge der folgenden GOF-Muster: Fabrikmethode, Singleton, Adapter und Fassade. Verhaltensmuster werden mehr oder weniger von den vorherrschenden Java-ee 14 Schichten von Antipatterns getötet, die vor 10 Jahren Mode du jour waren.

4: Beim Refactoring - wenn ein Muster Ihnen hilft, verwenden Sie es. Es gibt keine Klasse von Mustern, die beim Refactoring besser geeignet sind.

5: Ich denke, dass der Hauptindikator für ein bestimmtes Muster eher mit dem Problem und seiner Ähnlichkeit zu anderen Problemen zusammenhängt, die mit einem bestimmten Muster gelöst wurden. Ja, wenn der Code riecht, deutet das darauf hin, dass er möglicherweise umgeschrieben werden muss, und das Problem sollte erneut analysiert werden. Manche Probleme sind zwar kompliziert und können nicht reduziert werden, aber die meisten schon, und ein Muster kann helfen, das Problem ein wenig zu organisieren.

Allerdings. Als Folge der Beobachtung, dass komplexe Probleme komplexe Lösungen erfordern, neigen dicke Menschen dazu, komplexen Code zu schreiben. So können z. B. Zustandsmuster (die ich sehr schätze) die Dinge in unvorstellbarem Ausmaß verkomplizieren, wenn sie übermäßig genutzt werden.

6: Meine Kollegen scheinen mich zu mögen, also übertreibe ich wahrscheinlich nicht. Ich selbst bin eher genervt von der übermäßigen Verwendung von Factories und Factory Methods in Code, der sich wahrscheinlich nicht ändert oder in verschiedenen Implementierungen gleichzeitig existiert - und wenn er irgendwann geändert wird, muss er sowieso neu geschrieben werden. Das ist reine Zeitverschwendung, verkompliziert den Code und verzögert die Fehlersuche.