Panel użytkownika
Nazwa użytkownika:
Hasło:
Nie masz jeszcze konta?

Metody i pola statyczne w kodzie gry

Ostatnio zmodyfikowano 2015-07-16 20:27
Autor Wiadomość
Patrycjerz
Temat założony przez niniejszego użytkownika
Metody i pola statyczne w kodzie gry
» 2015-07-16 17:53:38
Witam,
jak to jest, czy powinno się tworzyć statyczne metody i pola, np. klasy głównej gry lub silnika i wywoływać je bez tworzenia obiektu, czy raczej stworzyć ten jeden obiekt, którego elementy będą używane przez cały czas programu? Jeśli weźmiemy pierwszy sposób, to de facto mamy pseudo zmienne globalne i nie musimy przesyłać tych zmiennych przez argumenty metodom z innych klas (gdy obce klasy mają do nich dostęp). Słyszałem, że w miarę możliwości powinno się przesyłać zmienne funkcją za pomocą argumentów, niż tworzyć litanie zmiennych globalnych. Ale i tak, i tak zmienne będą przechowywane przez cały czas gry, więc czy to jest tylko kwestia mojego upodobania?
P-134767
michal11
» 2015-07-16 20:01:14
Prawdopodobnie chodzi ci o Singleton'a. Aczkolwiek gdzieś czytałem, że nie powinno się go nadużywać (a taka jest tendencja właśnie do nadużywania).
P-134785
jankowalski25
» 2015-07-16 20:02:56
Zmienne globalne to zło, ale zmienne pseudoglobalne właściwie używane mogą być przydatne. Na tej zasadzie działa na przykład zmienna
std::cout
. Możesz utworzyć zmienne pseudoglobalne zamknięte we własnej przestrzeni nazw, klasę ze statycznymi zmiennymi publicznymi lub cokolwiek sensownego, co będzie działało.
P-134787
Patrycjerz
Temat założony przez niniejszego użytkownika
» 2015-07-16 20:15:07
A czy ktoś mi wytłumaczy, jaką ma racje bytu ta zasada, żeby wszystko, w miarę możliwości, przesyłać do funkcji (metod) za pomocą argumentów oraz dlaczego zmienne globalne to zło?
P-134788
jankowalski25
» 2015-07-16 20:27:09
1. Przekazujesz wszystko przez argumenty.
2. Lista argumentów funkcji robi się bardzo długa.
3. Część zmiennych zaczynasz pakować w struktury (lista argumentów się skraca).
4. Część kodu z takiej funkcji przenosisz do struktur jako ich metody (kod jest prostszy).
5. Dalsza ewolucja kodu...

W ten sposób unikasz zmiennych globalnych i problemów z ich używaniem. Jeśli trafisz na coś bardziej nietypowego, to możesz użyć zmiennych pseudoglobalnych.
P-134791
« 1 »
  Strona 1 z 1