Einführung in Design Patterns



  • Das freut mich, dass der Artikel gut ankommt 🙂
    Also prinzipiell spricht nichts gegen ein Fortsetzung, wobei ich demnächst aber einen anderen Artikel anfange. Aber danach, warum nicht 🙂

    hemem schrieb:

    #include <iostream>
    #include "singleton.h" // Die Singleton-Klasse von oben
    
    using namespace std;
    
    int main()
    {
        // Hier wird tatsächlich das Singleton-Objekt in der Instance-Methode instanziiert und zurückgegeben
        Singleton s1 = Singleton::Instance();       
    
        // Hier wird nun einfach das bereits weiter oben instanziierte Objekt zurückgegeben
        Singleton s2 = getSingletonInstance(); // !
       
        s1.doSomething();
    
        // Adressen des Objektes ausgeben: Diese sind immer gleich, d. h., es handelt sich immer um dasselbe Objekt
        cout << hex << &getSingletonInstance() << endl; // !
        cout << hex << &getSingletonInstance() << endl; // !
    
        return 0;
    }
    

    // ! fehlt da nicht ein Singleton::?

    Wenn du dir den Quellcode anschaust, dann siehst du, dass getSingletonInstance eine normale Funktion außerhalb der Singleton-Klasse ist (welche eben dazu dient, dass man nicht ständig über Singleton::Instance drauf zugreifen muss). D.h. da fehlt nichts 🙂



  • hi zu Observer Pattern hab ich gerade was gefunden:
    http://www.ddj.com/dept/cpp/184403873
    viel spaß;)



  • aber müsste ein singleton nicht auch den zuweisungsoperator protected oder private machen? Denn sonst kann man ja doch meherere Instnazen erstelln, wie man sieht:

    Singleton s1 = getSIngletonInstance();
    Singleton s2 = getSinbgleTonInstnace();

    s1 und s2 sind verschiedene Insstanzen, weil die rüberkopiert worden sind. Da muss doch eigentlich ne Referenz hin, oder?
    also Singleton& s1=getSingletonInsance();

    oder?



  • Maxi schrieb:

    s1 und s2 sind verschiedene Insstanzen, weil die rüberkopiert worden sind. Da muss doch eigentlich ne Referenz hin, oder?
    also Singleton& s1=getSingletonInsance();

    Ganz genau, weil der Copy Constructor nicht beachtet wurde: http://msdn.microsoft.com/msdnmag/issues/03/02/CQA/



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



  • 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?


Anmelden zum Antworten