Tak sie zastanawiam jak piszemy program co np. wyswietla jakies dane ktore uzytkownik moze modyfikowac to jak to zaprojektowac. Czy piszemy osobno klasy co trzymaja dane, mamy komponent co to wyswietla i jakas inna klasa co polaczy nasze dane z komponentem do wyswietlania, czy prosciej nadpisac takowy komponenet do wyswietlania co by jednoczesnie trzymal i wyswietlal dane ? No bo w 1 przypadku to robimy x2 to samo, w 2 przypadku np. stos co przechowuje zmienione elementy/dane komponentu (do operacji undo/redo) moze sie rozrosnac do sporych rozmiarow ( chociaz to raczej zalezy jak to bedziemy przechowywac - czy cale komponenty czy jakos zakodujemy dane obiektu np. w postaci stringa ). Czy to raczej zalezy od danej aplikacji? Np. w takim excelu - taka komorka tylko wyswietla czy tez trzyma te dane?
Jak dla mnie to jesli nie bedziesz smiecil w pamieci to kazda droga jest dobra. Teroetycznie operacje na kontrolkach sa wolniejsze niz na danych, ale biorac fakt ze najpierw wykonasz operacje na danych, potem wyczyscisz kontrolke( np. kasujac cala jej zawartosc ) i potem znowu dodasz jakies tam obiekty ktore wyswietlaja te dane to to juz raczej robi sie chyba wolniejsze.
Ale mając jakiś np. vector odpowiedzialny za trzymanie danych,
możesz do niego podpiąć dowolną ilość komponentów które będą mogły w dowolny sposób wyświetlić ( i ewentualnie zmodyfikować ) dane bazowe.
Np. masz baze pobranych temperatur z jakiegoś urządzenia...
teraz możesz ztworzyć sobie komponty np. WyswietlDaneTextowo, WyswietlDaneJakoWykres, WyswietlDanoJakoTabela, ZapiszDaneDoPliku......
Te komponenty w tym momencie nie muszą przechowywać za każdym razem tych samych danych ( musiały by je non stop odswierzać, albo otrzymywać sygnały o aktualizacji...)
I każdy może pracować w innym wątku...
W takim wypadku obsługa tych danych jest raczej szybsza...niż powyższy przykład (bo kwestia wyswietlania jest względna. naturalnym jest np. że na wykresie można odswierzać tylko te obszary gdzie doszło do aktualizacji, nie trzeba wszystkiego kasować i tworzyć od nowa....)
Pomijajac fakt, ze klasa powinna byc odpowiedzialna za jeden zakres obowiazkow. W innym wypadku dojdziesz do rozwiazania, gdzie klasa przechowuje dane, implementuje silnik bazy danych, generuje wykresy, tworzy raporty i jedyne czego nie robi (ale bedzie dostepne w nastepnej wersji) to kawa dla szefa ;)
...
Ja zawsze robie tak ze jezeli klasa trzyma jakies dane to Od razu udostepnia metody i GUI do edycji tych danycych oraz metody Load i Save. Np.
class Osoba
{
private:
AnsiString FImie;
AnsiString FNazwisko;
public:
int Setup(); // metoda wyswietla forme do edycji danych o osobie z pelna obsluga
int Load();
int Save(); // odczyt i zapis, ulatwia pozniejsza prace z obiektami
TForm* GetSetupGUI(); // dostarcza wskaznik na forme do edycji danych
};
Jak widac kazdy obiekt tej klasy potrafi sam siebie odczytac, zapisac, udostepnic edycje uzytkownikowi a takze udostepnic swoje GUI dla jakiegos obiektu "wazniejszego" (np. lista osob). Jezeli to jest dobrze zaimplementowane to na pozniejszym etapie (np. implementacja aplikacji zarzadzajacej tymi obiektami) nie trzeba juz nic wiecej robic z tym obiektem poniewaz wszystkie operacje na nim sa juz w niego wbudowane.
PS. prosze usunac poprzedni post, nie mam pojecia jak to sie wyslalo 8)