🚀 go-pugleaf

Tomasz Bosak wrote:
> Witam.
> Czy ktoś próbował (czy jest możliwe) generowanie zdarzeń
> "pseudosystemowych". Juz wyjaśniam. Jedna klasa wyświetla pasek
> postępu i zmienia jego wartość pod wpływem zdarzenia. Zdarzenie może
> być generowane w kilku innych klasach. Czy koniecznie musze
> zdefiniować z jakich klas będę odbierał zdarzenie, czy tez istnieje
> sposob reagowania na zdarzenia pochodzace od "nieznajomych".

Witam!

Wydaje mi się, że najrozsądniejsze rozwiązanie to wykorzystanie trzeciego
elementu. Czyli zdefiniowanie interfejsu, za pomocą które gadają dwie klasy.
W tym sensie klasa odbiorca musi implementować z góry określony interfejs.
Obiekty powinny być zebrane w jakąś listę albo drzewo. Przechodzimy po
wszystkich węzłach drzewa albo pozycjach listy. Sprawdzamy czy klasa
implementuje interfejs i wywołujemy metodę. W przypadku drzewa trzeba
jeszcze rozwiązać problem rozsyłania zdarzenia w głąb drzewa. Odbiorach
zdarzenia musi je rozesłać dalej albo udostępnić jakiś interfejs to
umożliwiający.

Powstaje jeszcze problem komunikacje w górę. To znaczy odbiorca zdarzenia
chce coś wykonać na obiekcie rozsyłającym, pobrać jakieś ustawienia. Tu
można mnoży interfejsy albo użyć argumentów metody. Sam argument także może
być interfejsem. Także, klasy o sobie wiedzą tylko tyle, że implementują
konkretne interfejsy.

Generalnie to nie wiem czy jest sens szukać i uzależniać się od jakiś
mechanizmów systemowych. W razie bardziej skomplikowanych przypadków nawet
nie należy bezpośrednio działać na klasach systemowych. Np. gromadząc je w
listy albo stosują istniejące listy. W tym przypadku trzeba zastosować
agregacje, czyli wsadzić obiekt do obiektu. Dopiero ten zewnętrzny obiekt,
którym sterujemy będzie sterował klasami systemowymi. Jest to także rodzaj
interfejsu zrobionego własnym sumptem.

Oprócz problemu odbierania wiadomości jest jeszcze problem powstawia
wiadomością. Wiadomość czy zdarzenie nie musi powstać wcale w obiekcie
przechowującym listę obiektów, które muszą być powiadomione o zdarzeniu.
Taki obiekt dopiero musi odnaleźć obiekt odpowiedzialny za rozesłanie
zdarzenia. Jak go nazwałem dyspozytorem, Dispatcher.

-- 
Pozdrawiam,
Marek Janaszewski
[ j_m...@gazeta.pl ]

Tomasz Bosak wrote:
| Witam.
| Czy kto� pr�bowa� (czy jest mo�liwe) generowanie zdarze�
| "pseudosystemowych". Juz wyja�niam. Jedna klasa wy�wietla pasek
| post�pu i zmienia jego warto�� pod wp�ywem zdarzenia. Zdarzenie mo�e
| by� generowane w kilku innych klasach. Czy koniecznie musze
| zdefiniowa� z jakich klas b�d� odbiera� zdarzenie, czy tez istnieje
| sposob reagowania na zdarzenia pochodzace od "nieznajomych".

Witam,
Czytam grup� od pewnego czasu, pisz� tu po raz pierwszy. Ale do rzeczy.

W C# zdarzenia s� budowane na modelu Publisher <-> Subscriber. Ide� jest
zasada aby statycznej wi�zi mi�dzy klas� publikuj�c� zdarzenie, a
klas�-odbiorc�. Z tego wzgl�du implementacja interfejsu nie pasuje do tej
logiki, bo wymusza na klasie-odbiorcy implementacj� wszystkich metod
zdefiniowanych w owym interfejsie. A przecie� odbiorca mo�e nie by�
zainteresowany wszystkimi, mo�e te� w og�le nie by� zainteresowany
jakimikolwiek zdarzeniami generowanymi przez Publishera.
I tu zamiast interfejs�w idealnie pasuj� delegaci.
Publisher og�asza �wiatu swe zdarzenia i (w pewnym sensie) [nie dba]/[nie
musi dba�] o to, kto go s�ucha, cho� mo�e to zbada� je�li chce. Aktualn�
list� subskrybent�w konkretnego zdarzenia klasa Publisher mo�e otrzyma� za
pomoc� GetInvocationList() wykonanej na stosownym delegacie.
Musi by� jaki� mechanizm zale�no�ci pomi�dzy klasami, ale w trakcie
dzia�ania programu klasa mo�e si� swobodnie [dopisa� do]/[wypisa� z] listy
zdarza� innej klasy.

Ciekawy link:
http://www.sellsbrothers.com/writing/default.aspx?content=delegates.htm

BTW: ucz� si� C# od niedawna, wi�c co z�ego to nie ja ;O)

Poni�ej m�j ma�y przyk�adzik:
---
using System;
class ClassMain
{
 static void Main()
 {
  Sender sender = new Sender("File compressor");
  ProgressBar pbar = new ProgressBar();
  sender.OnDelegProgress += new delegProgress(pbar.ReceiveProgress);
  // klasa ProgressBar mo�e ale nie musi byc powiadomiona o ko�cu.
//sender.OnDelegCompleted += new delegCompleted(pbar.JobCompleted);
  sender.StartProcessing();

  Console.WriteLine("\n*** Main END ***");
  System.Threading.Thread.Sleep(5000);
 }
}

public delegate void delegProgress(object sender, int v);
public delegate void delegCompleted();

class Sender //Publisher
{
 public Sender(string name)
 {
  this.name = name;
 }
 public string Name
 {get{return this.name;}}
 public void StartProcessing()
 {
  Console.WriteLine("Sender '{0}' : Starting processing...", this.name);
  for(int i=0; i<11; i++)
  {
   System.Threading.Thread.Sleep(500);
   if (OnDelegProgress != null)
    this.OnDelegProgress(this, i);
  }
  Console.WriteLine("Sender '{0}' : Processing finished.", this.name);
  if (OnDelegCompleted !=null)
    this.OnDelegCompleted();
 }
 private string name;
 public event delegProgress  OnDelegProgress;
 public event delegCompleted OnDelegCompleted;
}
class ProgressBar //Subscriber
{
 public void ReceiveProgress(object theSender, int progress)
 {
  if (theSender is Sender)
  {
   this.name = ((Sender)theSender).Name;
   Console.WriteLine("|In ProgressBar| Message from object '{0}' : my
progress is {1}", this.name, progress);
  }
  else
  {
   Console.WriteLine("<<ProgressBar>> Message from object {0} : my progress
is {1}", theSender, progress);
  }
 }
 public void JobCompleted()
 {
  Console.WriteLine("<<ProgressBar>> Tak, widze ze to koniec.");
 }
 private string name;
}
---

---
pozdrawiam
KCiuba

[...]
| Ide� jest zasada aby NIE BY�O statycznej wi�zi mi�dzy klas� publikuj�c�
zdarzenie, a
| klas�-odbiorc�.
[...]