Diese Seite ist unverschlüsselt! Um sicherzustellen, das Ihr Passwort nicht ausgelesen werden kann, sollten Sie auf die verschlüsselte Seite wechseln!

    Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » Das Observerpattern
Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: [ 1 ] [ 2 ] > 3 < [ 4 ]
020
30.08.2006, 13:17 Uhr
stephanw
localhorst


In Java gefällt mir das Prinzip mit Listenern etc. irgendwie besser, weil nicht alle Events in einer Methode ankommen (wie in Observer::update() ), sondern in der dafür vorgesehenen. Damit wird der Observer-Code klarer. Nachteil: da die Events dann nicht mehr durch _eine_ Methode gehen, kann man auch so Sachen wie ChangeManager zum Sammeln und Summieren von Events nicht so richtig implementieren. Ich werde mir den Java-Ansatz nochmal ansehen, vielleicht kommt mir noch mal die Idee für die Verheiratung beider Ideen.
--
Reden ist Schweigen und Silber ist Gold.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
021
30.08.2006, 22:26 Uhr
(un)wissender
Niveauwart


Wobei auch die Listener ein generisches Interface darstellen. Ich glaube mit den templates ist man im Prinzip flexibler, eben weil man überhaupt kein Interface vorgibt.
--
Wer früher stirbt ist länger tot.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
022
30.08.2006, 22:41 Uhr
Spacelord
Hoffnungsloser Fall


Also die Tatsache dass bei deiner Templateinstanzierung das Observable Objekt sich auf einen konkreten Typ (und dessen Subtypen) festlegt der sich als Observer anmelden darf gefällt mir persönlich garnicht.
Ich halte es für das Observerpattern für unerlässlich dass sich unterschiedliche Klassen ,die das Observerinterface implementieren(update Methode), an dem zu beobachtenden Objekt anmelden können.
Du ziehst dass Pferd aber von der anderen Seite auf.Du kannst zwar jede beliebige Klasse als Observer nehmen und dir ne Methode aussuchen mit der der Beobachter auf nen notify reagieren soll allerdings können sich dann aber auch nur Objekte dieser Klasse am Observable Objekt anmelden.Imho ist das nicht der Sinn der Sache.
Das ganze ist meiner Meinung nach eher nen MischMasch aus Observer und Command Pattern.
Ich möchte garnicht abstreiten dass der Code nen praktischen Nutzen hat ,aber das was ich unter nem klassischen Observer Pattern verstehe ist das nicht.

Gruss Spacelord
--
.....Ich mach jetzt nämlich mein Jodeldiplom.Dann hab ich endlich was Eigenes.
Dieser Post wurde am 30.08.2006 um 22:49 Uhr von Spacelord editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
023
31.08.2006, 08:57 Uhr
(un)wissender
Niveauwart


Hm, also so ganz stimmt das ja nicht. Normalerweise meldet man eh Pointer als "Objekte" an, die haben dann nur ein Interface, aber einen unterschiedlichen dynamischen Typ.
Ich kenne keine Observerimplementierung, die das anders macht.
Man könnte auch boost::any als Template-Typ verwenden, dann kannst du auch jedes Objekt anmelden.
Also ich sehe das Problem wirklich nicht.
--
Wer früher stirbt ist länger tot.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
024
31.08.2006, 11:43 Uhr
puppetMaster



 noch eine grundlegende sache zu patterns.
patterns sind praktisch musterlösungen für bestimmte problemstellungen.
das bedeutet man verwendet und implementiert sie genau da wo man sie auch braucht.
man sollte also nicht auf die idee zu kommen möglichst viele patterns auszu implementieren und sie dann hier und da mal zu verwenden.

deine observer implementierung ist ja generisch, d.h. du hast sozusagen ein framework oder bibiliotheks funktion entwickelt die man immer da verwenden kann wo man das observer pattern gerade braucht.
das verfolgt zwar den gedanken der wiederverwendbarkeit, ist nicht sinn und zweck der sache.

anscheinend scheint das ein oft vorkommendes missverständniss über patterns zu sein...

habe z.b. auch schon solche sachen gesehen (in PHP)

PHP 4:
class Singleton{
  var $cName;
  var $instance;
  function getInstance(){
   if(!$instance){
    $instance = new $cName();
   }
   return $instance;
  }
}

class Test extends Singleton{
   ...
  }
Test::$cName = "Test";
...
$in = Test::getInstance();
Dieser Post wurde am 31.08.2006 um 11:44 Uhr von puppetMaster editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
025
31.08.2006, 12:43 Uhr
Guybrush Threepwood
Gefürchteter Pirat
(Operator)


Ich würde DesignPatterns nicht unbedingt Musterlösungen nennen sondern eine Möglichkeit ein bestimmtes Problem anzugehen. Diese kann man dann übernehmen oder sich an ihr orientieren oder es komplett anders machen.

Aber trotzdem kann man ja über die Umsetzung eines bestimmten Patterns Diskutieren
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
026
31.08.2006, 12:51 Uhr
(un)wissender
Niveauwart


@puppetmaster
Gut, ich gebe dir Recht. Allerdings ist das doch eher akademischer Natur oder?

Also, es ist eine Bibliothek in C++ zur Implementierung des Observerpatterns.
--
Wer früher stirbt ist länger tot.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
027
31.08.2006, 12:52 Uhr
puppetMaster
Zitat von Guybrush Threepwood:
Ieine Möglichkeit ein bestimmtes Problem anzugehen. Diese kann man dann übernehmen oder sich an ihr orientieren oder es komplett anders machen.

das meinte ich ja auch... muster und musterlößung ist nicht das selbe und hat auch ausser dem wort muster nichts mit einander zu tun... mein fehler


Zitat von Guybrush Threepwood:
Aber trotzdem kann man ja über die Umsetzung eines bestimmten Patterns Diskutieren

wollte ich auch niemandem verbieten ...
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
028
31.08.2006, 13:07 Uhr
ao

(Operator)



Zitat von puppetMaster:
deine observer implementierung ist ja generisch, ... nicht sinn und zweck der sache. anscheinend scheint das ein oft vorkommendes missverständniss über patterns zu sein...

Wieso? Ein Pattern ist doch nur eine Beschreibung, wie ein bestimmtes Problem gelöst werden kann, ähnlich wie ein Algorithmus. Das *kann* man an Ort und Stelle und immer wieder implementieren, muss dann aber auch an Ort und Stelle pflegen -> auf Dauer lästig.

Wenn man es schafft, eine generische wiederverwendbare Implementierung zu finden - um so besser. Was ist daran missverstanden?

ao
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
029
31.08.2006, 22:03 Uhr
Spacelord
Hoffnungsloser Fall


@(un)wissender:
Ich glaube so langsam wir reden aneinander vorbei.
Um mal Bezug auf deine test Main vom Anfang zu nehmen.
An bs können sich nur Objekte vom Typ TestObserver,oder Subtypen von diesem Typ anmelden.
Somit müsstest du jede andere Klasse,die sich ebenfalls bei bs als Beobachter anmelden möchte von TestObserver ableiten(mal abgesehen davon dass observableChanges nicht virtual ist).
Also müsste TestObserver doch wieder ne reine Observer Schnittstelle bieten oder du nimmst eine beliebige Klasse und leitest alle anderen von dieser ab wobei natürlich ne absolut unnatürliche Klassenhierarchie entsteht.
Nehmen wir mal als Beispiel ne Dokumentklasse die von ner View,nem DB-Updater und einer Logfileklasse überwacht werden soll.
Klassischerweise würden dann View,DB-Updater und Logfile von Observer erben und in ihrer update Methode auf ihre spezielle Art auf Änderungen im Dokument reagieren.
Bei deiner Auslegung müsstet du dann entwerder auch ne Observerklasse schreiben,mit der du dann Observable instanzierst und von der View,DB.... dann erben oder du instanzierst Observable einfach mit z.B. der View.Dann müssten aber DB-Updater und Logfile von View erben was natürlich absoluter Mumpitz ist.
Und wenn du doch ohnehin ne Observerklasse schreiben musst um mehreren(eigentlich unterschiedlichen) Klassen die Möglichkeit zu geben sich beim Subjekt anzumelden dann kannst du dir den ganzen Templatekram auch sparen.

Gruss Spacelord
--
.....Ich mach jetzt nämlich mein Jodeldiplom.Dann hab ich endlich was Eigenes.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: [ 1 ] [ 2 ] > 3 < [ 4 ]     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: