io-2009-4d team mailing list archive

[Adrian Panasiuk <adek336@xxxxxxxxx>]

W dniu 22 marca 2009 21:05 użytkownik  <projects.gg.aaron@xxxxxxxxx> napisał:
> Mi się chyba bardziej podoba diagram Mikołaja - jakoś nie widzę do końca
> rozbicia na trzy moduły obsługi u Adriana. Na tyle na ile rozumiem ten
> diagram, to model by tylko robił redirect do odpowiedniego modułu obsługi -
> nie lepiej wtedy włożyć te moduły do modelu?

No diagram Mikołaja jest dobry. Chyba faktycznie Model można pominąć.


> Mikołaj - u Ciebie co właściwie się przemieszcza między kontrolerem a gui - te
> okazjonalne callbacki? Też nie jestem pewien co do umiejscowienia parsera
> odpowiedzi - jak monitor stanu programu ma zmieniać coś w gui jak dostaje nie
> sparsowany tekst i nie łączy się z parserem?

Ja myślę że GUI powinno mieć bardzo dużo callbacków - oddzielny na
dodanie wartości śledzonej, na śmierć wątku, na narodziny wątku, itd.
Być może nawet na zmianę wartości śledzonej inny niż na pierwsze
pokazanie wartości śledzonej - chyba że w interfejsie graficznym,
widok wartości śledzonej pojawia się natychmiast, zanim GUI ma szansę
się dowiedzieć, czy takie wyrażenie jest poprawne i jaką ma wartość.

Jeśli Monitor miałby umieć na przykład robić jakieś analizy złożonych
typów, na przykład obliczenie średniej wartości na instancji
std::list<int>, to wówczas Monitor sam by generował komunikaty "daj
kolejną wartość" ... a więc potrzebuje albo mieć dostęp do obu
generatora i parsera, albo lepiej - nie dawać Monitorowi dostępu do
Pośrednika a tylko do Kontrolera.




-- 
Czy ty orzeł, czy ty kawka? -wkrótce zdłabi kaszel, czkawka.
Śmierć szyję zaszyje.