Mam nadzieję, że te kłótnie wyjaśnią moje pytanie - jednak całkowicie zrozumiem, jeśli nie, więc daj mi znać, jeśli tak jest, a ja postaram się wyjaśnić.
Poznaj BoxPong , bardzo prostą grę, którą stworzyłem, aby zapoznać się z tworzeniem gier obiektowych. Przeciągnij pole, aby kontrolować piłkę i zbierać żółte rzeczy.
Tworzenie BoxPong pomogło mi sformułować między innymi podstawowe pytanie: w jaki sposób mogę mieć obiekty, które współdziałają ze sobą bez konieczności „przynależenia” do siebie? Innymi słowy, czy istnieje sposób, aby obiekty nie były hierarchiczne, ale współistniały? (Przejdę do dalszych szczegółów poniżej.)
Podejrzewam, że problem współistnienia obiektów jest powszechny, więc mam nadzieję, że istnieje ustalony sposób jego rozwiązania. Nie chcę wymyślać kwadratowego koła, więc wydaje mi się, że idealną odpowiedzią, której szukam, jest „oto wzór projektowy, który jest często używany do rozwiązania twojego rodzaju problemu”.
Zwłaszcza w prostych grach, takich jak BoxPong, jasne jest, że istnieje lub powinna istnieć garść przedmiotów współistniejących na tym samym poziomie. Jest pudełko, piłka, jest przedmiot kolekcjonerski. Wszystko, co mogę wyrazić w językach obiektowych, chociaż - a przynajmniej tak się wydaje - to ścisłe relacje HAS-A . Odbywa się to poprzez zmienne składowe. Nie mogę tak po prostu zacząć balli pozwolić, by zrobiła to samo, potrzebuję, aby na stałe przynależeć do innego obiektu. Mam go skonfigurować tak, że głównym celem gry jest okno, a okno z kolei ma piłkę, a ma licznik wynik. Każdy obiekt ma równieżupdate()metoda, która oblicza pozycję, kierunek itp., i idę tam podobną drogą: wywołuję metodę aktualizacji głównego obiektu gry, która wywołuje metody aktualizacji wszystkich jej dzieci, a one z kolei wywołują metody aktualizacji wszystkich swoich dzieci. To jedyny sposób, w jaki mogę stworzyć grę obiektową, ale uważam, że nie jest to idealny sposób. W końcu nie uważałbym piłki za należącą do pudełka, ale raczej za bycie na tym samym poziomie i interakcję z nią. Przypuszczam, że można to osiągnąć, zamieniając wszystkie obiekty gry w zmienne składowe głównego obiektu gry, ale nie widzę, żeby to rozwiązywało. Mam na myśli ... pomijając oczywisty bałagan, w jaki sposób piłka i pudełko mogłyby się poznać , to znaczy wchodzić w interakcje?
Istnieje również problem obiektów, które muszą przekazywać między sobą informacje. Mam spore doświadczenie w pisaniu kodu do SNES, gdzie masz dostęp do praktycznie całej pamięci RAM przez cały czas. Załóżmy, że tworzysz niestandardowego wroga dla Super Mario World , i chcesz, aby usunął wszystkie monety Mario, a następnie po prostu zapisz zero, aby rozwiązać problem 0 USD bez problemu. Nie ma żadnych ograniczeń, że wrogowie nie mogą uzyskać dostępu do statusu gracza. Wydaje mi się, że ta wolność mnie rozpieszcza, ponieważ w C ++ i podobnych często zastanawiam się, jak udostępnić wartość innym obiektom (a nawet globalnym).
Na przykładzie BoxPong, co jeśli chciałbym, aby piłka odbiła się od krawędzi ekranu? widthi heightsą właściwościami Gameklasy,ballmieć do nich dostęp. Mógłbym przekazywać tego rodzaju wartości (za pomocą konstruktorów lub metod, w których są potrzebne), ale to po prostu krzyczy mi złe praktyki.
Wydaje mi się, że moim głównym problemem jest to, że potrzebuję przedmiotów, aby się poznać, ale jedynym sposobem, w jaki to widzę, jest ścisła hierarchia, która jest brzydka i niepraktyczna.
Słyszałem o „klasach przyjaciół” w C ++ i trochę wiem, jak one działają, ale jeśli są one rozwiązaniem całościowym, to dlaczego nie widzę friendsłów kluczowych wylanych w każdym projekcie C ++ i dlaczego koncepcja nie istnieje w każdym języku OOP? (To samo dotyczy wskaźników funkcji, o których niedawno się dowiedziałem.)
Z góry dziękuję za odpowiedzi dowolnego rodzaju - i ponownie, jeśli jest jakaś część, która nie ma dla ciebie sensu, daj mi znać.