Przekazanie sterowania wyżej

Witam.

Jestem już w dość zaawansowanej fazie projektu. Tworzę aplikację w Qt z wykorzystaniem MVC (własna implementacja). Mam klasę kontrolera, widoku i klasy pomocnicze (modele). Każdy kontroler jako pole trzyma wskaźnik na klasę widoku (-ów), które obsługuje. Kontroler może zawierać też subkontrolery, zarządzające jakąś mniejszą częścią aplikacji. I tak np. mam coś takiego

MainController
 -MainView 
 -GameController //subkontroler
   --GameView
   --ChessBoardController //subkontroler
     ---ChessBoardView
   --ChessPanelController //subkontroler
     ---ChessPanelView

Problem polega na tym, że np. ChessPanelView zawiera kontrolkę (dajmy na to button), który musi przekazać zdarzenie za pomocą sygnału lub slotu do MainControllera. Oczywiście nie jest to problemem, wystarczy w klasie MainController zrobić coś takiego

connect(gameController->getChessPanelController()->getChessPanelView()), SIGNAL(jakissygnal), this, SLOT(jakisslot));

Jak widać tworzy się brzydki wężyk (strach pomyśleć co by było gdyby tych subkontrolerów było więcej). Nie wiem czy to jest mój błąd projektowy (wydaje mi się jednak że z projektem jest OK, bo każdy kontroler ma świetnie przypisane zadania, wszystko jest przejrzyste i w ogóle cacy :P) czy może to jedyne wyjście? Oczywiście często będzie się zdarzało że muszę przekazać jakieś dane z któregoś subkontrolera wyżej i taka sytuacja będzie bardzo częsta.

chyba słusznie zauważyłeś, że coś jedt nietak

ja w swoich projektach stosuję​ "single resposibility principle"

gettery umożliwiają dostęp do elementów klasy z innych wątków, przez co może stać się to niebezpieczne

połączenie SIGNAL SIGNAL między klasami/managerami a SIGNAL SLOT pomiędzy manager -> managed object

connect(gameController->getChessPanelController()->getChessPanelView()), SIGNAL(jakissygnal), this, SLOT(jakisslot));

w klasie w której jesteś masz dostęp do gameControllera, który ma dostęp do chessPanelControllera...

nie lepiej zrobić:

QObject::connect(gameController, SIGNAL(s), this, SLOT(s), Qt::QueuedConnection);

w klasie gameControllera

QObject::connect(this, SIGNAL(s), chessPanelController, SIGNAL(s), Qt::QueuedConnection);

i w końcu w klasie checssPanelView()

QObject::connect(this, SIGNAL(s), chessPanelView, SIGNAL(s), Qt::QueuedConnection);

gwarantujesz przejrzystość przepływu informacji, i nie robisz bałaganu komunikacyjnego

Tez stosuja ta zasade. Twoj przyklad rozni sie tylko tym ze zamiast od razu przekazac dane te 2 pietra wyzej, przekazujesz najpierw jedno pietro wyzej a potem kolejne. Ale jezeli faktycznie jest to lepsze rozwiazanie...

MateuszS napisał(a):

Tez stosuja ta zasade. Twoj przyklad rozni sie tylko tym ze zamiast od razu przekazac dane te 2 pietra wyzej, przekazujesz najpierw jedno pietro wyzej a potem kolejne. Ale jezeli faktycznie jest to lepsze rozwiazanie...

no nie robisz ponieważ przez to, że masz tyle geterów, każdy obiekt w programie może sobie getować inny,

nie ma to nic wspólnego z tą zasadą

to tak jakbyś miał pointer do wszystkiego w każdej z klas

jeszcze tych getterow nie mam bo tak podejrzewalem ze moze da sie to lepiej rozwiazac. Ok teraz rozumiem. Czyli przyklad ktory zapodales to jest najlepsze rozwiazanie?

to wszystko zależy od tego co chcesz osiągnąć,

ogólnie projektowanie to najważniejszy etap, który zajmuje mnóstwo czasu;

projekt nad, którym teraz siedzę był wymyślany przez 4 osoby przez dobre 1.5 miesiąca zanim napisałem int main(), a i teraz nawet zdarzy się​ wymyśleć coś ​lepszego,

jedyne co jest pewne u Ciebie to to, że musisz oddzielić logikę​ gui od logiki samej gry -> muszą być dla siebie blackboxami, jedyne co to mogą mieć wspólne wiadomości (protokół), trzecim takim blackboxem byłaby klasa odpowiedzialna za połączenie tcp/ip lub z bazą danych do komunikacji z innymi aplikacjami, jeżeli takowe planujesz

wszystko jest w Twoich rękach, poczytaj o pluginowości w cpp, budowaniu interface'ów, wykorzystaniu managerów,

może ktoś inny ma lepszy pomysł

zadanie wydaje się dość trudne, ale nie niewykonalne

powodzenia