Einführung in Design Patterns

#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::?

nep

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ß;)

Maxi

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?

evilissimo

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

nep

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

evilissimo

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

Tc++H

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.

nep

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?

nep

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

Erhard Henkes

Zu Observer:
http://www.henkessoft.de/C++/C++ Fortgeschrittene/C++_Fortgeschrittene.htm#3.1._Observer

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...

Fedaykin

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.

Artchi

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.

Sovok

super artikel

d_496

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.