Einführung in Design Patterns



  • 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



  • Sovok schrieb:

    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

    Tut mir leid aber das ist großer Mist.
    Zum einen würde es sicher ausreichen kurz zu erläutern, was ein smart pointer ist.
    Beu Tutorials ist es wichtig immer den richtigen und sichersten weg zu wählen, damit andere davon lernen können. Warum also nicht smart pointer benutzen. An der Verständnis kann es sicherlich nicht liegen, denn:
    Foo *bar = new Foo();
    bar->blub()
    oder
    auto_ptr<Foo>bar(new Foo());
    bar->blub();
    ist alles andere als ein riesiger schwer zu verstehende Unterschied.
    Das einzige was nötig wäre, ist dem Leser kurz zu vermitteln was so ein Zeiger Container macht. Also bei zerstörung des containers automatisch den Inhalt freigeben und somit Speicherlecks zu verhindern und ansonsten die Nutzung des Objektes wie immer von statten geht.
    Das ist ebenso verständlich wie mit rohen pointern plus zusätzlicher Sicherheit. Solche Grundlegenden Dinge sollten auch in so einem Tut genutzt und wenn nötig kurz erklärt werden.

    Wenn etwas beibringen, dann auch richtig.

    Schöne Grüße



  • also erstmal Danke für diesen Artikel! Habe dadurch endlich nach 2 Tagen eine funktionierende Observer Subject Struktur hinbekommen. Es gibt noch einen kleinen Fehler

    class ConcrecteSubject : public Subject

    da hast du ein c zu viel. Ansonst Danke für diesen Artikel ich teste jetzt mal das Strategie Pattern!

    // ConcreteSubject.h //
    #include <string>
    #include "Subject.h"
    
    using namespace std;
    
    class ConcrecteSubject : public Subject
    {
    
    private:
        string data;
    
    public:
        void setData(string _data) { data = _data; }
        string getData() { return data; }
        ConcreteSubject() : Subject() {}
    };
    

    Gruß bEKAR



  • Super Artikel, genau danach habe ich gesucht und auf anhieb gefunden 😉 👍



  • Super Artikel, danke auch von meiner Seite! 👍



  • Sehr guter Artikel, dickes Dankeschön auch von mir 👍

    Lg freeG



  • Vielen Dank für den Artikel!
    Im Adapter-Pattern habe ich zwei Fehler entdeckt resp. in der Erzeugung der Objekte über den Iterator:
    1. begin() und end() sind doch Funktionen also sollte man die Klammern nicht vergessen
    2. sollte man den Iter inkrementieren und nicht die Liste

    Deine Version:
    //alle gemoetrischen Figuren anzeigen
    list<Shape*>::iterator iter = shapes.begin();
    for ( ; iter != shapes.end; shapes++ )
    (*iter)->display();

    Verbesserte Version:
    //alle gemoetrischen Figuren anzeigen
    list<Shape*>::iterator iter = shapes.begin();
    for ( ; iter != shapes.end(); iter++ )
    (*iter)->display();

    Habe mir nur den Adapter angeschaut möglicherweise gibts im Artikel weitere Fehler



  • Guter Artikel, steckt viel Arbeit drin.

    Eine Seite die ich nicht mehr missen möchte ist diese:
    https://dotnetcodr.com/architecture-and-patterns/


Anmelden zum Antworten