Cześć,
Mam pytanie o Wasze dobre praktyki w kontekście "sprzątania"/składowania funkcji.
W miarę rozrastania się projektu o dodatkowe formularze przychodzi potrzeba ogarnięcia jakoś funkcji.
Dla lepszego zobrazowania problemu podzielmy funkcje na te które są używane tylko w jednym formularzu i na takie które są na tyle uniwersalne, że możemy ich używać w całym projekcie.
Gdzie umieszczacie funkcje z poszczególnych grup? Jaki pliki dodajecie do projektu i gdzie je umieszczacie?
Nie rób funkcji, rób klasy, niech nawet z wyłącznie statycznymi metodami.
Kod formularza powinien robić bardzo mało. Całą logika aplikacji, powinna być w osobnej bibliotece, zwierające klasy potrzebne do obsługi problemu.
Temat jest bardzo szeroki skomplikowany i bardziej nadaje się na książkę niż na wątek na forum.
Poszukaj jakiś materiałów na temat, architektury aplikacji. MVC MVVM MVP itp (nie mam linków do niczego, co pasowałoby do twoich potrzeb).
Nawet jak znajdziesz jakiś dobry materiał, to jego zrozumienie, w stopniu takim, by faktycznie używać tej wiedzy, zajmie ci lata.
pytanie czy chodzi o funkcje zawierające logikę aplikacji czy o bajery do wyświetlania formularza?
logika to chyba raczej w głównym pliku cpp formularza.
OK to może posłużę się najprostszym przykładem jaki w tym momencie przychodzi mi do głowy
ma dwa formularze
Form1 i Form2 na obu są jakieś pola
chcę przejść z Form1 na Form2 i oczywiście chcę wyczyścić pola tego formularza
Do tej pory w głównym pliku cpp Form2 umieszczałem funkcję np. czyscPola np.
void _fastcall TForm2::czyscPola(void)
{
// i jedziemy po polach
Edit1->Text = "";
Edit2->Text = "";
// itd.
}
w miarę przyrostu funkcji w pliku cpp robi się tłoczno i duży bałagan i chciałem sobie te wszystkie funkcje powywalać gdzieś na zewnątrz a w pliku cpp odwoływać się tylko do nazw funkcji i stąd pytanie jak to robicie ? jakie są dobre praktyki. Nie oczekuję wykładu tylko jakieś praktyczne porady np. dodaj do projektu nowy Unit i dołącz go do Formularza który ma korzystać z funkcji a w tym nowym Unicie wrzucaj ciała funkcji.
Nie wiem czy dobrze wytłumaczyłem o co mi chodzi :)
KiK napisał(a):
logika to chyba raczej w głównym pliku cpp formularza.
Słyszałeś o czymś takim jak pisanie testów do kodu?
Jak logikę się ma osobno od UI to wtedy łatwo się pisze testy.
Tak samo w kodzie jest mniejszy bałagan, z którym próbujesz walczyć.
OK to może posłużę się najprostszym przykładem jaki w tym momencie przychodzi mi do głowy
ma dwa formularze
Form1 i Form2 na obu są jakieś pola
chcę przejść z Form1 na Form2 i oczywiście chcę wyczyścić pola tego formularza
Do tej pory w głównym pliku cpp Form2 umieszczałem funkcję np. czyscPola np.void _fastcall TForm2::czyscPola(void) { // i jedziemy po polach Edit1->Text = ""; Edit2->Text = ""; // itd. }
Tego jest za mało żeby nazwać to logiką aplikacji, więc przykład nie jest zbyt życiowy.
oczywiście bo przykład jest z sufitu i nie chodzi o to co ten kawałek kodu prezentuje tylko o jakieś wskazówki gdzie go umieści np.
utwórz nowy unit nazwij go tak samo jak formularz i tam wrzucaj wszystkie funkcje dotyczące danego formularza.
o takie praktyczne porady mi chodzi a nie o teorie co i dlaczego jest albo nie jest logiką albo czy słyszałem o pisaniu testów czy nie słyszałem.
KiK napisał(a):
oczywiście bo przykład jest z sufitu i nie chodzi o to co ten kawałek kodu prezentuje tylko o jakieś wskazówki gdzie go umieści np.
utwórz nowy unit nazwij go tak samo jak formularz i tam wrzucaj wszystkie funkcje dotyczące danego formularza.
no jeżeli byłby to spcyuficzny dla tylko tego formularza kod to w formularzu, jeżeli użyty w kilku to w unicie, poszukja se jak sie rtobi pętle po kontrolkach danego okna, zamiast pisać Form1.cośtam='';
Należy zauważyć, że C++ Builder oraz Delphi pomimo, że moim zdaniem jest całkiem fajnym środowiskiem bardzo źle uczy. Domyślnie kładziesz na formatce komponenty, klikasz button i IDE generuje Ci puste OnClick podpięte pod dany komponent. Następnie naturalną koleją jest pisanie w tym całej logiki aplikacji. To jest złe i trzeba się tego oduczyć jak najszybciej. Ja staram się pisać w ten sposób, że formatka po prostu wywołuje metody z innych obiektów które to już wykonują sensowne zadania.
No i kolejnym błędem jaki popełniają początkujący, jest trzymanie danych w komponentach typu TEdit, TListBox itp. Formatka ma za zadanie jedynie wyświetlić dane. Same dane powinny być trzymane w odpowiednich strukturach/obiektach. Wiem, że na początku to jest trudne. Jednak powoduje oddzielenie danych od interfejsu. Co za tym idzie jak ktoś wcześniej wspomniał umożliwia pisanie testów.
Niestety osobiście widziałem bardzo mało artykułów, tutków gdzie było pokazane jak w C++ Builderze osiągać rozdzielenie GUI od logiki czy też korzystać z MVC i innych wzorców. Większość projektów jakie widziałem w tym środowisku to jedna wielka kupa kodu spaghetti.
KiK napisał(a):
w miarę przyrostu funkcji w pliku cpp robi się tłoczno i duży bałagan i chciałem sobie te wszystkie funkcje powywalać gdzieś na zewnątrz a w pliku cpp odwoływać się tylko do nazw funkcji i stąd pytanie jak to robicie ? jakie są dobre praktyki. Nie oczekuję wykładu tylko jakieś praktyczne porady np. dodaj do projektu nowy Unit i dołącz go do Formularza który ma korzystać z funkcji a w tym nowym Unicie wrzucaj ciała funkcji.
Nie wiem czy dobrze wytłumaczyłem o co mi chodzi :)
W Twoim pytaniu nie ma nawet wzmianki o powoływaniu nowych klas (nie będących TFrom), adekwatnych do zagadnienia struktur danych (aka Model), właściwej separacji (Model/View) itd. masz tylko problem "ilościowy".
Myślę, że nawet nie masz przypuszczeń, gdzie/jak powstał problem i co go naprawdę leczy
Mr.YaHooo napisał(a):
Formatka ma za zadanie jedynie wyświetlić dane. Same dane powinny być trzymane w odpowiednich strukturach/obiektach.
Rzecz jest również w tym, że jedynym bytem, do jakiego potrafią się bindować widgety borlandowe, są bazy danych 1) (odmiennie niż np Java Swing, C# WinForms itd).
Myślę że ryba psuje się od głowy (mam na myśli, że w tym wątku niektórzy bronią produktu a obwiniają "złe kursy", czyli dobry car i źli bojarzy)
AnyKtokolwiek napisał(a):
Rzecz jest również w tym, że jedynym bytem, do jakiego potrafią się bindować widgety borlandowe, są bazy danych 1) (odmiennie niż np Java Swing, C# WinForms itd).
Niestety tego mi bardzo brakuje, sam chciałbym nie korzystać z obiektów bazodanowych i mogę powiedzieć, ze nie znam skutecznej metody bindowania kontrolek do normalnych obiektów. Najczęściej jednak piszę system który trzyma dane w bazie, więc wielkiego problemu nie ma, jednak chciałbym to rozwiązać jakoś bardziej elegancko aniżeli korzystanie z komponentów bazodanowych/
AnyKtokolwiek napisał(a):
Myślę że ryba psuje się od głowy (mam na myśli, że w tym wątku niektórzy bronią produktu a obwiniają "złe kursy", czyli dobry car i źli bojarzy)
Też mi się tak wydaje, co więcej mało widzę sensownych materiałów do C++ Buildera. Jednak w pracy muszę w nim pisać, bo kodu jest tyle, że nie ma za bardzo na co przejść w sensownym czasie.