rafallauterbach Temat założony przez niniejszego użytkownika |
Problem z designem klas (parser) » 2019-10-08 20:35:36 Witam, robię parser dla plików json dla mojej gry.
Mam klasę client, która ma w sobie zasoby, którę chcę wypełnić z pliku json.
Chciałbym dostać wskazówkę, czy mój tok myślenia jest odpowiedni.
W klasie client mam mapy <Image> i <Scene> z nazwami i instancjami klasy. Chciałbym, aby parser wypełnił te mapy na podstawie plików json. Mam kilka pomysłów jak to zrobić, ale żaden mi się nie podoba/każdy wydaje mi się dziwny.
1. Zrbić klasę parser ze statycznymi metodami, i wrzucić w klasie client linijkę z friend parser.
2. Dziedziczyć klasą parser z klienta i przerzucić w kliencie te zasoby z private do protected
3. Namespace praser, i client który może "łyknie" te dane tylko przy stworzeniu/inicie.
4. W kliencie wysyłać do danej funkcji parsera pointer do zasobu, który chcę wypełnić.
5. Wsadzić funkcje parsowania do klasy client, tylko że zaśmieci mi to czytelność klasy.
Chciałbym uniknąć używania "friend", pomysły nr 2 i 4 podobają mi się chyba najbardziej, ale parser nie brzmi jak coś co powinno dziedziczyć z tego, co parsuje, ale może to dobry pomysł? A może jest jakiś prostszy sposób? |
|
DejaVu |
» 2019-10-08 20:59:18 Jeżeli ćwiczysz kodowanie przez robienie bibliotek to fajnie. Jeżeli chcesz mieć szybkie rezultaty i wartościowe doświadczenie dla firm - staraj używać się bibliotek, które są dostępne na rynku (np. rapidjson). Jeżeli zauważysz, że dostępne na rynku rozwiązania są słabe (z różnych względów) to wtedy również warto iść we własnym kierunku (albo wrapper albo własna implementacja). /edit: Trochę trudno zrozumieć o co Ci w zasadzie chodzi tj. jaki cel chcesz osiągnąć. Czy parsowanie pliku Json, czy to jest aspekt pomijalny i interesuje Ciebie jak zorganizować dane w klasach, które odczytasz z json-a. /edit: W każdym razie, jeżeli projektujesz jakieś funkcjonalności to staraj się unikać dziedziczenia, jeżeli się da. Lepiej projektuj 'czarne skrzynki', które mają wygodny interfejs np.: class Map final
{
public:
bool loadMap( const std::string & _jsonFileName );
std::vector < std::string > getImageFileNames() const;
std::pair < int, int > getMapSize() const;
Tile getMapTile( int _x, int _y ) const;
private:
};
Wówczas bardzo łatwo będziesz mógł zarówno sparsować dane jak i dostać się do interesujących danych na podstawie których np. będziesz renderował mapę. |
|
pekfos |
» 2019-10-08 21:02:44 Najsensowniej wygląda numer 5. | tylko że zaśmieci mi to czytelność klasy |
dodanie jednej metody na 10-20 linii? Nie wiem co Ty chcesz tam zrobić, ale to nie brzmi jak zadanie na więcej niż kilkanaście linii kodu. |
|
rafallauterbach Temat założony przez niniejszego użytkownika |
» 2019-10-08 22:35:58 Dzięki za odpowiedzi. Możliwe, że źle użyłem słów parsowanie/parser - chyba parsowanie to to co robi za mnie taka biblioteka, a to co robię, to jest raczej przepisywanie tych wczytanych danych do moich klas i działanie sobie na nich, żeby wczytać inne dane.
Chyba dziedziczenie w którąś stronę w tym wypadku byłoby faktycznie niewłaściwe i bez sensu, tak samo używanie osobnej klasy/namespace'a "parser", bo bez sensu jest wczytywanie tych danych w osobnej klasie. Każdą jedną klasę, którą będę chciał wczytać, musiał bym tej dziwnej specjalnej klasie "przedstawić" i dać pełen dostęp.
Ta funkcjonalność powinna być w klasie, która jej potrzebuje, więc jednak 5ka brzmi najlepiej...
Mam kilka plików json i będę miał kilka różnych metod, żeby móc np. przeładować same tylko obrazy, bez przeładowywania scen i innych rzeczy, więc to będzie kilka linijek na start, a może więcej w przyszłości, ale schowam sobie chyba te całe parsowanie w skomentowanych klamrach \\{ \\}
narazie mam jsony :
config zawierający m.in. (ścieżki do następnych jsonów), (globalne skróty klawiszowe)
images zawierający pary (nazwa obrazu) - (ścieżka do obrazu)
scenes zawierające (listę scen) <- pary (nazwa sceny) - (ścieżka)
i (narazie jedną) scenę - main_menu zawierającą dużo rożnych rzeczy, background image, listę obiektów (przyciski)- i ich obrazy, lokalizacje; skróty klawiszowe dla danej sceny, etc
Chwilowo miałem przestój w kreatywności, więc postanowiłem zadziałać trochę od tyłu i stworzyłem sobie taką strukturę i format plików. Staram się brać przykład z gier w których prawie wszystko jest wyrzucone do xmli/jsonów czy czego tam używają i każdy może to dzięki temu łatwo modować. Staram się wyrzucić wszystkie hard-coded dane i zostawić w programie tylko logikę.
W sumie nie widziałem w żadnej grze, żeby graficzny interface był modowalny z poziomu jakchś plików tego typu, ale i nie wiem co w tym szkodzi, jak ktoś chce to niech może mieć przycisk w innym miejscu albo nie mieć go wcale. |
|
| « 1 » |