Staram się uczyć dobrych praktyk, pisać czytelny kod itd., dlatego chciałem zasięgnąć porady co do odpowiedniego podziału programu w JavaFX na klasy. Mam głównie na myśli ogólną zasadę działania, jeśli można to tak nazwać. Weźmy na przykład moją prostą grę kółko i krzyżyk. Cała logika gry zawarta jest w kontrolerze glownej sceny, klasa kontrolera zawiera wszystkie metody odpowiedzialne za AI, sprawdzanie stanu gry, rozpoczynanie nowej. Tak chyba nie powinno być. Do czego powinna ograniczać się rola kontrolera? Powinienem przenieść logikę gry do osobnej klasy, powołać jej instancję w kontrolerze i przekazać jej referencję do sceny żeby mieć dostęp do kontrolek w celu np. wpisania kółka/krzyżyka do przycisku?
Czasem sporo się zastanawiam jak zorganizować mój kod żeby był zgodny z ogólnoprzyjętymi zasadami, żebym mógł się pochwalić w CV itd. Gdzie najlepiej szukać dobrych praktyk?
Staram się uczyć dobrych praktyk, pisać czytelny kod itd., dlatego chciałem zasięgnąć porady co do odpowiedniego podziału programu w JavaFX na klasy. Mam głównie na myśli ogólną zasadę działania, jeśli można to tak nazwać. Weźmy na przykład moją prostą grę kółko i krzyżyk. Cała logika gry zawarta jest w kontrolerze glownej sceny, klasa kontrolera zawiera wszystkie metody odpowiedzialne za AI, sprawdzanie stanu gry, rozpoczynanie nowej. Tak chyba nie powinno być. Do czego powinna ograniczać się rola kontrolera? Powinienem przenieść logikę gry do osobnej klasy, powołać jej instancję w kontrolerze i przekazać jej referencję do sceny żeby mieć dostęp do kontrolek w celu np. wpisania kółka/krzyżyka do przycisku?
Rola kontrolera powinna się ograniczać do powiązania widoku z logiką aplikacji i strukturami danych. Mówiąc prościej, wszystko co jest związane z AI, stanem gry i wykonywaniem wszelkich innych akcji, powinno mieć swoje reprezentacje w oddzielnych klasach/interfejsach/enumach. W kontrolerze powinna zachodzić jedynie ewentualna inicjalizacja obiektu i zmiana jego stanu poprzez wywoływanie na nim jego metod. Mogą również w kontrolerze zachodzić relacje między obiektami, ale osobiście uważam, że mediatorem w tych relacjach powinna być funkcjonalność (np. metoda) NIE-zaimplementowana w kontrolerze. Kontroler ma służyć jako pomost między widokiem, a logiką i modelem.
Czasem sporo się zastanawiam jak zorganizować mój kod żeby był zgodny z ogólnoprzyjętymi zasadami, żebym mógł się pochwalić w CV itd. Gdzie najlepiej szukać dobrych praktyk?
Ogólnie rzecz biorąc, to jest dobra książka: http://helion.pl/ksiazki/czysty-kod-podrecznik-dobrego-programisty-robert-c-martin,czykov.htm. Nie odpowiada jednak chyba do końca na Twoje pytanie, które dotyczy raczej projektu aplikacji, a nie jakości kodu, jako takiego. Osobiście nie znam żadnych książek, które pozwoliłyby Ci "nauczyć się" tworzyć aplikacje w sposób "właściwy". Ogólnie rzecz biorąc, wyznaję zasadę LCDT, która mówi, że kod powinien być warstwowy (Layered), czysty (Clean), opisany (Documented) oraz przetestowany (Tested). Zasadę wymyśliłem sam - sprawdza się. Pewnie dlatego, że jest oczywista. Z tego co widzę trudniej przychodzi egzekwowanie każdego z jej pojedynczych założeń i połączenie wszystkich do kupy. No, ale cóż.