W Javie Swing powszechnie stosuje się observery o nazwie listener w połaczeniu z obiektami event w celu połaczenia GUI z warstwą logiczną. Czy dobrą praktyką jest stosowanie czegoś analogicznego w C++. Czy tez może istnieje lepsza technika w celu modularyzacji programu. Chodzi mi o przypadek ogólny, niekoniecznie GUI<->logika. Moze jakis link do dobrej strony PL lub EN. Ostatecznie moge iść na skróty i zastosować wspólne obiekty globalne, ala musiały by być znane zarówno przez jedną jak i drugą warstwę i modularność została by zamazana.
Bardzo prosze o odpowiedź jeżeli ktoś jest w temacie.
0
0
dobroc to pojecie wzgledne. jesli uwazasz je za wygodne - uzywaj ich
zazwyczaj realizuje sie to za pomoca 'sygnalow' i 'slotow' (patrz np QT, ale w boost tez sa), w praktyce jest to to samo co handlery/listenery i eventy
tylko, zwroc uwage ze nie sa one wyrocznia w kwestii modularyzacji. to ze cos z czyms jest powiazane eventami/etc nie gwarantuje modularnosci :) dobre rozdzielenie mozna rownie dobrze uzyskac poprzez dobrze skonstruowane szablony/interfejsy/klasybazowe/etc
jesli chodzi o 'eventy', zachecam do uzycia gotowcow z boost'a, aczkolwiek samemu tez sobie mozna skrobnac, patrz np. bardzo podstawowa 'domowa' implementacja Events
0
Dzięki quetzalcoatl za zwrócenie uwagi na mój problem. Chyba zdecyduję się na uproszczoną wersję tego co podałeś w swoim artykule. Ostatecznie ma to być na potrzeby jednego projektu, a z drugiej strony łatwo będzie podpiąć coś innego w przypadku optymalizacji. Język C++ poznałem niedawno, a właściwie to dalej poznaję i chyba dobrze powiem, że wybór między różnymi równorzędnymi rozwiazaniami jakie oferuje ten język, to trudne zadanie. Np. efektywność kontra zasady obiektowości. Wiem, że kompilator za nas odwala czarną robotę z danymi, funkcjami i wskaźnikami rodem z C, ale tak naprawdę, to trzeba być twórcą kompilatora, zeby wiedzieć o nim wszystko. Wydaje mi się, że po prostu trzeba obrac swój styl i trzymac się jego konsekwentnie.
Sorry, za te wywody filozoficzne, ale to chyba nie tylko mój problem.