C++, obiekt klasy widoczny w wielu plikach

[dragranis]

Witam, mam takie pytanie. Otóż nigdy dotąd tego nie potrzebowałem ale przymierzam się do robienia gry w sfml i według tego co zaplanowałem, wyjdzie sporo linijek kodu. Nigdy nie potrafiłem za bardzo dzielić sensownie kodu na pliki bo i nie było mi to potrzebne. W teorii wiem że w .h daje się deklaracje a w .cpp definicje ale mam inny problem. Powiedzmy że chcę napisać dosyć sporą klasę przechowującą wszystkie dane o graczu. Gdzie powinienem utworzyć obiekt, aby był widoczny w wielu plikach? Czy ktoś mógłby mi to łopatologicznie wytłumaczyć? Z góry dzięki za pomoc

[Pancake]

Jesli nigdy nie dzieliles kodu ani nie pisales wiekszych projektow to taki ogromny skok moze byc... nienajlatwiejszy

Nie dzieliles kodu to znaczy, nie miales takiej potrzeby wiec nie uzywales klas a co za tym idzie wzorcow projektowych?

Rozrysuj zaleznosci miedzy klasami, to bardzo pomaga.

 

Globalne instancje klas nie sa dobrym rozwiazaniem, moze da sie stworzyc ja w mainie i przekazac przez referencje do innych komponentow ktore z niej korzystaja?

Ewentualnie good ol' Singleton

[Sopelek997]

Gdzie powinienem utworzyć obiekt, aby był widoczny w wielu plikach?

 

To pytanie świadczy o tym, że powinieneś zacząć od czegoś prostszego. Plik to nie jest element języka, nie ma czegoś takiego jak `zmienna widoczna w pliku`. Podział na pliki jest tylko po to aby programista miał łatwiej, mógł uporządkować kod.

Widoczność obiektów jest określana po poziomie jednostek translacji (and. translation unit) i bloków kodu (ang. scope).

 

Ciężko jednoznacznie stwierdzić gdzie obiekt Gracza powinien się znaleźć. Zależy to od tego jak zaprojektujesz aplikację i czym ma w ogóle być (tak jak @Pancake mówi, rozrysuj sobie zależności). Problem dostępności to nie taki prosty temat jak się wydaje, jest wiele sposobów na osiągnięcie tego, to jaki będzie najlepszy zależy od konkretnego przypadku.

 

Powiedzmy jednak, że masz jakąś klasę Game, która odpowiada za ogół gry. Zarządza ona powiedzmy obiektem Level, który określa konkretny poziom. Można tutaj pomyśleć nad rozłożeniem gracza na dwie klasy, jedna, która przechowuje jego statystyki i będzie należeć do Game (powiedzmy Player), a druga, która będzie odpowiadała za jego reprezentację w świecie interakcję z nim i interakcję z użytkownikiem (powiedzmy PlayerEntity), która będzie tworzona dla każdego poziomu na podstawie obiektu klasy Player i będzie z nim w ścisłym związku. Żeby PlayerEntity wiedział jaki Player jest jego rodzicem to można przy tworzeniu PlayerEntity przekazać referencję (lub wskaźnik) do Player w konstruktorze i sobie zapisać w polu. Podobnie, przez parametr (do funkcji (czyli też konstruktora)) można przekazywać go dalej tam gdzie jest to potrzebne. Dla przykładu jeszcze powiedzmy, że jest klasa Spike, która reprezentuje kolce, które ranią byty, które z nimi kolidują. Nie ma potrzeby, żeby obiekty klasy Spike (które znajdowały by się pewnie w obiekcie Level) wiedziały o graczu. Dopiero podczas kolizji wywołałbyś odpowiednią metodę i przekazał jako parametr obiekt PlayerEntity, który wpadł w kolce, a kolce zadały by obrażenia. (Tutaj warto też pomyśleć o tym, ze nie byłoby dobrym pomysłem stworzyć klasę bazową dla wszystkich bytów, np. Entity. Wtedy taki kolec przyjmował by Entity zamiast PlayerEntity)

 

Jest to tylko jeden ze sposobów rozwiązywania problemu dostępności. Różne z nich są dobre dla konkretnych sytuacji. Powyższy jednak jest najbardziej podstawowy i razem ze swoimi wariacjami jest całkiem wystarczający (czasem jest niewygodny i nielogiczny, wtedy korzysta się np z Singleton'ów i pochodnych, ale to w przypadku bardzo ogólnych klas, jak np. Logger, który odpowiada za logowanie do pliku informacji o przebiegu programu).

[Pancake]

A tak polzartem - ale z oficjalnej strony isocpp!

 

https://isocpp.org/wiki/faq/coding-standards#global-vars

 

"The names of global variables should start with //."