Einführung in Design Patterns



  • dia schrieb:

    Mit welchem Programm hast du diese schönen Diagramme gemacht?

    Die sehen aus als wären die mit dem Program gemacht worden das du als Nick trägst 😉

    BR
    Vinzenz



  • Oh ja das stimmt, den Copy-Konstruktor hab ich vergessen 🙄
    Den sollte man besser protected machen, hier in dem Beispiel spielts aber keine Rolle (zudem ist das C++-spezifisch, in andern Sprachen braucht man das nicht)

    @dia
    Die Diagramme hab ich mit ArgoUML erzeugt. Gibt aber schöneres 😉



  • nep schrieb:

    Oh ja das stimmt, den Copy-Konstruktor hab ich vergessen 🙄
    Den sollte man besser protected machen, hier in dem Beispiel spielts aber keine Rolle (zudem ist das C++-spezifisch, in andern Sprachen braucht man das nicht)

    @dia
    Die Diagramme hab ich mit ArgoUML erzeugt. Gibt aber schöneres 😉

    Ach echt? 😮 Die von DIA sehen auch so aus :p
    BR
    Vinzenz



  • Sehr schöner Artikel, könntest du eventuell auch noch ein paar exoten erläutern?



  • Warum machst du die doSomeThing Funktion static? Wenn das Singleton static ist, dann muss doch die Funktion nicht mehr static sein.



  • Gute Frage 🙄
    Ist natürlich unnötig, auch wenn sich nichts dran ändert



  • Ich hab paar Fragen zu dem Observer-Pattern.

    Es ist ja für mich eigentlich schon verwirrend genug, dass nicht das Subject der eigentliche Observer ist, weil er reagiert ja eigentlich auf die Zustandsänderung, indem er die Observer benachrichtigt. Die Observer beobachten für mich also eigentlich gar nichts, sondern warten eher, bis sie mal von der Seite angestubst werden.

    Aber ok, was ich eigentlich wissen wollte, warum bekommen die Observer einen Zeiger des Subjects, das sie benachrichtigt? Warum müssen die den haben?



  • Naja da hast du programmiertechnisch gesehen auch nicht unrecht. Das Subjekt muss die Observer natürlich benachrichtigen (also wie du es nennst "von der Seite anstubsen"). Aber genau das ist es ja was die Observer "beobachten", sie sind abhängig vom Subject und beobachten Zustandsänderungen. Wenn sich aber etwas am Zustand geändert hat, dann muss das Subjekt dieses den Observern auch irgendwie mitteilen; die können das ja nicht riechen 😉

    Und genau deswegen bekommen auch die Observer einen Zeiger des Subjects. Sobald sie benachrichtigt wurden, wissen sie ja, dass sich etwas am Zustand des Subjektes geändert hat. Und nun will ein Observer normalerweise natürlich auch wissen was sich am Zustand geändert hat (also z.B. neue Daten usw...), und diese Änderungen muss man beim Subject abfragen, und das geht eben über diesen Zeiger





  • Gibt es das Programm (bei den Strategy Mustern) auch komplett (also lauffähig) zum ausprobieren irgendwo, ohne das ich noch die Sortieralgorythmen einfügen muss und so, weil ich damit irgendwie probleme habe...



  • Hmm der artikel ist sehr gut, vor allem das strategie pattern ist interessant sowie das mit den observern und eigentlich das mit den adaptern auch. Obwohl man dort hätte auch selber drauf kommen können. Wenn ich einen vorschlag machen dürfte was ggf noch mit rein könnte, wären Factory classes. Ich setze die selber ab und an mal ein und die sind sehr hilfreich.



  • Fedaykin schrieb:

    Obwohl man dort hätte auch selber drauf kommen können.

    Jeder der schon länger programmiert und noch nie etwas über Pattern gelesen/gehört hat, hat schon mal unwissend diese u.ä. Patterns genutzt. Das liegt in der Natur der Sache... sprich in der Natur der Objektorientierung. Patterns sind einfach nur noch mal eine schriftliches festhalten.



  • super artikel 👍



  • Hallo,

    dem kann ich mich nur anschließen. Super Artikel, vor allem mit den
    minimalen C++ Gerüsten, die man direkt verwenden kann.
    Ich habe eine Frage zum Observer-Pattern, und zwar der Abbildung
    unten zum Thema GUIs, wo auch das Adapter-Pattern mit einfließt.
    Muß da nicht die Aggregation zwischen ConcreteObserver und MyWindow
    anders herum sein, da ja mein ConcreteObserver ein Handle auf MyWindow
    braucht, um dessen Schnittstelle zu adaptieren, aber umgekehrt
    MyWindow kein Handle auf den ConcreteObserver haben muß? Der
    ConcreteObserver wäre hier also die Gesamtheit und MyWindow ein Teil
    dieser Gesamtheit. Die Raute müßte also bei ConcreteObserver sein?
    Ich bin nämlich gerade dabei, genau dieses Muster anzuwenden und es
    würde mir sehr helfen, da Klarheit zu kriegen.

    Weiter so und beste Grüße,

    Peter.



  • Danke erst mal.

    @d_496:
    Ja, du hast mit allem vollkommen recht, ConcreteObserver adaptiert die Schnittstelle von MyWindow. Da hab ich die Aggregation im UML-Diagram falsch rumgesetzt. Wie du schon sagtest, müsste die Raute genau anders rum sein. Werd ich wohl heute abend noch korrigieren.

    @Smiling:
    Ich hab glaube ich irgendwo noch das Projekt rumfahren, aber glaub auch ohne konkrete Sortieralgorithmen. Wo sind denn deine Probleme?



  • Wieso ist eigentlich alles auf dem Heap? Und dann auch noch ohne Smart-Pointer?

    Das ist doch ein sicheres Rezept für unnötige Fehler!



  • Vielleicht hat er früher mal Java/C# oder ähnliches programmiert. Sowas sieht man oft, das solche Leute dann mit Value-Semantik und RAII Probleme haben.

    Gruß
    Don06



  • Aha...

    Nun ja, warum soll ich da Smart Pointer reinbringen? Das verwirrt viele Leute eher, da eher wenige Leute mit SmartPointer arbeiten, und ich mich auch nicht zu sehr auf C++ fokussieren wollte.

    Und wenn man mit Polymorphie arbeitet, dann muss das Zeugs nun mal dynamisch allokiert werden



  • nep schrieb:

    Aha...

    Nun ja, warum soll ich da Smart Pointer reinbringen? Das verwirrt viele Leute eher, da eher wenige Leute mit SmartPointer arbeiten, und ich mich auch nicht zu sehr auf C++ fokussieren wollte.

    Und wenn man mit Polymorphie arbeitet, dann muss das Zeugs nun mal dynamisch allokiert werden

    Smart-Pointer wären IMHO besser, ja. Dieses schreckliche übermäßige Verwenden von rohen Pointern, obwohls in C++ nicht nötig ist, sorgt in meiner Erfahrung für enorm viele Fehler.

    Zum Thema "nicht auf C++ fokussieren"... wenn du C++ nicht nutzen willst, nimm ne andere Sprache, aber bitte kein verkrüppeltes C++.



  • ich bin auch gegen smart pointer aus ähnlichem grund wie nep
    einfach weil die meißten c++ mit rohen pointern gelernt haben und
    die beispiele mit rohen pointern verständlich und durchsichtig sind

    dass smart pointer in realer umgebung sinnvoller sind ist richtig aber
    ein ganz anderes thema


Anmelden zum Antworten