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

Meiner Erfahrung nach hängt es von der Methodik und dem Grad des Vorabentwurfs ab, wann Muster angewendet werden. In einem agilen Prozess sehe ich typischerweise, dass sich ein Muster relativ schnell herauskristallisiert, wenn sich die Absicht des Codes entwickelt und dann entsprechend refaktorisiert wird.

Auch auf die Gefahr hin, das Offensichtliche zu sagen: Unit-Tests mindern einen Großteil des Risikos, aber je früher man sie durchführt, desto besser. Ich habe nie eine größere Umstrukturierung des Codes vorgenommen, um ein neues Muster zu implementieren, da der damit verbundene Aufwand selten einen signifikanten Nutzen gezeigt hat. Es sei denn, das Projekt steht kurz davor, in eine neue Phase der Entwicklung einzutreten.

Kleine Refactorings, die sich auf ein oder zwei Methoden beschränken, sind während der Laufzeit eines Projekts durchaus üblich, aber sie erfolgen unter dem Vorwand, dass es so etwas wie "vollständigen Code" nicht gibt :)

Answer 2

IMO gibt es keine Regeln oder allgemeine Situationen. Entwurfsmuster werden verwendet, wenn sie angemessen sind. Manchmal weiß man das beim Entwurf, manchmal beim Kodieren und manchmal beim Refactoring.

Meistens wende ich ein Entwurfsmuster nicht eins zu eins an. Sie müssen angepasst werden. Entwurfsmuster sind wie ein Katalog von Erfahrungen. Man kennt einfach einige gängige oder typische Muster und passt sie an die Lösung an, die man braucht. (Anmerkung: Es sind Muster, keine Lösungen.)

Answer 3

Vergessen Sie das Buch nicht Design Patters Es kann C++ abdecken, aber das spielt keine Rolle, es sind alles Muster. Außerdem ist das Buch sehr gut.

Und man lernt die Muster nicht, um sie zu implementieren, das ist der falsche Weg, man lernt sie, um mit anderen Programmierern über den Code sprechen zu können. Es ist mehr eine Erweiterung deiner normalen Sprache als irgendetwas anderes. Verwenden Sie es in Ihrem Code, wenn Sie es brauchen, aber nicht vorher :-)

Answer 4

Ich werde hier einen anderen Ansatz wählen und weder Bücher erwähnen noch auf alle diese Punkte einzeln eingehen.

In meinem Fall war die beste Auswirkung, die ich hatte, dass ich atmen konnte. SOLID . Imho kann man viele Szenarien und Muster mit diesen Grundsätzen in Verbindung bringen, und wenn man eine sich entwickelnde Code-Basis-Mentalität verfolgt, werden in der Regel die Bedürfnisse für all diese anderen Muster deutlich.

Was die Hinweise angeht, lange Methoden => Refactor. Selbst wenn es sich nur um einen Wechsel zu Methoden in derselben Klasse handelt, da dieser Zwischenschritt normalerweise den nächsten Schritt offenbart.