Einführung in Design Patterns

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.

nep

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?

Mr. N

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!

Don06

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

nep

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

Mr. N

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

Sovok

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

bEKAR

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

phcn.fraggle

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

Super Artikel, danke auch von meiner Seite!

fr33g

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