Citat:
djoka_l: A da sve to staviš u C i ne razmišljaš o virtuelnim baznim klasama i njihovim nedefaultnim konstruktorima.
Hoćeš da kazes da C kod nema arhitekturu, već samo kreneš da krkaš linije koda i nadaš se da će to da skalira? Arhitektura aplikacije često ne zavisi od samog jezika, OOP možeš da pišeš i u C-u, sa sve virtuelnim metodama. Treba samo malo više boilerplate koda koji ti C++ napravi za tebe.
E sad, zašto miješati grafove u sve ovo? Pa zato što je to jedan od pristupa da napraviš fleksibilnu arhitekturu. Zamisli da imaš gomilu implementiranih čvorova, npr. jedan čvor uzima vrijednost i prosleđuje ju dalje samo ako dođe do promjene, drugi čvor uzima neku vrijednost i renderuje ju kao GUI komponentu, itd. Svaki čvor je jedna lego kockica sa dobro definisanim interfejsom (Data/Event Source ulaz i Data/Event Source izlaz). I to mogu da programiram već danas. Onda kako dobijam detaljnije zahtjeve šta aplikacija treba tačno da radi, samo uklapam kockice (koristeći XML fajl). Ako mi zafali kockica, napravim novu, ali to ne utiče na ostatak aplikacije.
Prednosti ovakvog pristupa su skalabilnost, lakše pisanje unit testova (možeš svaki čvor pojedinačno da pokriješ), garantovano je da promjene unutar čvora neće da procure dalje, itd. All the good stuff.
Citat:
djoka_l:Jasno je meni to, ali mi se čini da prrogrameri koji su počeli odmah sa OOP imaju naopako "zašrafljenu" glavu. Umesto da razmišljaju o rešenju problema, misle da će im egzotične konstrukcije jezika to rešiti.
Ne znam da li se ovo odnosi na mene, ali pisao sam ja i proceduralni kod, a radio i u (embedded) C-u i web-u i asembleru na kraju krajeva. I, opet ponavljam, OOP nije vezan za jezik, OOP je pristup dizajniranju i možeš ga pisati i u asembleru ako želiš, samo ima više kucanja i sve moraš pješke. :)
Citat:
djoka_l:I oupšte, ceo taj koncept, neko će da napravi XML, Python će da ga procesira i pretvori ga u C++, pa će neko da kompajlira taj C++. Srećno mu bilo sa debagovanjem!
Ne znam čemu taj nedobudni ton, ali ajde. Nije prvi put da radim nešto na ovaj princip. Prednost code gen faze je što XML fajl definiše samu aplikativnu logiku. Na osnovu ovog fajla možeš čak izgenerisati sliku samog grafa (trivijalno sa GraphWiz), što pomaže kod dokumentacije. Svaki pojedinačni čvor testiraš kao da je black box. Inače, XML fajl je 1-1 preslikavanje u odnosu na C++, može se taj C++ napisati i ručno, ali budući da imam novi sloj indirekcije, mogu čak i promjeniti arhitekturu aplikacije u pozadini, a da ne diram samu logiku, samo paralelno updejtujem python parser da prati C++.
E sad da se vratimo na temu, zezancija zbog koje imam diamond "problem" (pod navodnicima jer zapravo i nije problem, rješenje postoji, ovdje pričamo o elegenciji i diskutujemo da li sam možda potpuno promašio i zaista ima puno bolji i jednostavniji pristup) je sledeća:
EventSource prilikom broadcasta event-a treba da se identifikuje. On to radi tako što pošalje NodeId parametar, koji ima zato što nasleđuje Node klasu. Tako primalac eventa zna ko je podigao event. Isto tako, povlačenje podataka (konzumer DataSource interfejsa) zahtjeva da se čvor od kojeg vučemo podatke identifikuje preko njegovog NodeId-a, jer jedan čvor može da vuče podatke od više drugih čvorova.
Zbog toga mi i EventSource i DataSource nasleđuju Event.
Citat:
dejanet: Pa da, zasto ne list<EventSource > i list<DataSource> kao properties u Node klasi, plus getter i setters, plus odgovarajuci metodi u nastavku ?
Citat:
Branimir Maksimovic: samo list<Node> mislim. a sam node uz to ima i Event/Data Source pointere. Tako bih ja. Cisto da ne bi morao da se radi downcast.
Ovdje se vraćamo na kompoziciju, a nisam siguran da je to dobar pristup (ili možda ne razumijem dobro šta predlažete).
Na primjer, ako imam čvor sa dva pointera (Event i Data source objekti), ja svejedno moram tom čvoru da dam i interfejs da bi drugi čvorovi mogli da komuniciraju sa njim. Taj interfejs upravo i obezbjeđuju Event i Data source objekti, pa ako naslijedim Event i Data source, ja taj interfejs dobijam besplatno. Sasvim moguće da nešto propuštam u ovoj priči.