![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 37 Pomógł: 0 Dołączył: 21.02.2004 Ostrzeżenie: (0%) ![]() ![]() |
Jestem w trakcie tworzenia systemu gier internetowych w php.
Założenia sa takie: -w serwisie jest kilka typów gier (Game1, Game2, ..) -gier kazdego typu moze byc wiele -kazda gra moze miec kilka róznych pluginów (Plugin1, Plugin2, Plugin3, ...) -nie kazdy plugin pasuje do wszystkich gier -nie kazdy plugin działa tak samo we wszystkich grach Problem -wywołanie metody np. Game1::play() dla gry ma uwzgledniac istnienie poszczegolnych pluginow i odpowiednio na to reagowac -jezeli plugin modyfikuje stan gry to wywolanie metody np. Game1::get_some_value() zwróci inna wartośc w przypadku istnienia w grze pluginu i inna jezeli go nie bedzie i trzeba to uwzglednic -jak najmniej instrukcji switch i if-ów -klasy pochodne nie moga sie zbytnio rozrastac Troche ostatnio zacząłem studiowac wzorce projektowe. I tu mam pytanie, czy do tego nadaje sie wzorzec mostu? Moze ktos zaproponuje rozwiazanie tego? Istniejace klasy w projekcie: class Game { ... var $plugins; ... } class Game1 extends Game {...} class Game2 extends Game {...} class Plugin extends {...} class Plugin1 extends Plugin {...} class Plugin2 extends Plugin {...} Kod jest pisany w PHP4 :/ Niestety nie PHP5!! Wiec rózne fajerwerki obiektowe odpadaja. Dzięki za pomoc!! -------------------- If I Cant.... Do It... Homieee Ite Cant Be Doooone
|
|
|
![]()
Post
#2
|
|
![]() Grupa: Zarejestrowani Postów: 521 Pomógł: 0 Dołączył: 3.11.2003 Skąd: 3city Ostrzeżenie: (0%) ![]() ![]() |
Problem polega na tym, że:
- każdy plugin może być dołączony do dowolnej liczby gier - każdy plugin może modyfikować każdą grę inaczej - nie ma ograniczenia liczby gier i pluginów Ciekawe zagadnienie, i niestety trudne. Jeżeli nie da się przewidzieć, jak dany plugin modyfikuje daną grę, to chyba nie pozostaje nic innego niż switch. Pytanie, gdzie ten switch umieścić. Nie widzę w twoim przypadku możliwości wrzucenia tego do plugina, bo jak gra miałaby wtedy odwoływać się do plugina np. przy wywołaniu get_some_value? Wrzucenie switcha do gry jest prostsze - mamy listę pluginów dołączonych do gry, sprawdzamy czy jest na niej plugin danego typu (np. instanceof) i jeżeli tak to robimy coś specjalnego. Wada - takie switche muszą obsługiwać wszystkie rodzaje pluginów we wszystkich grach, we wszystkich miejscach gdzie plugin może coś modyfikować. No i wychodzi z tego dupa a nie plugin. Taki zdegenerowany plugin byłby raczej kontenerem na ustawienia konfiguracyjne dla gier. Mój wniosek jest taki: jeżeli wychodzi z tego potworek, to coś jest nie tak. Pewnie że można to zakodować, ale mi się wydaje że twoja koncepcja pluginów jest zbyt ogólna. Za mało reguł rządzących pluginami -> nie da się stworzyć sensownego modelu klas. Chyba że ktoś to elegancko rozwiąże. |
|
|
![]()
Post
#3
|
|
![]() Grupa: Zarejestrowani Postów: 105 Pomógł: 0 Dołączył: 16.10.2004 Ostrzeżenie: (0%) ![]() ![]() |
Nie wiem dokładnie jak to planujesz, ale ja bym porozbijał to wszystko i podzielił pluginy ze względu na funkcjonalność, łatwiej wtedy nimi zarządzać.
Pluginy można dać w kolejkę, czyli klasa gry wywołuje metodę każdego pluginu danego typu jako argument dając rezultat poprzedniego. Innym sposobem jest wykorzystanie dekoratora, ale troszkę utrudnione wydaje mi się zarządzanie pluginami. Można też pomyśleć o jakimś systemie zdarzeń. -------------------- Com powiedział, powiedziałem.
|
|
|
![]() ![]() |
![]() |
Wersja Lo-Fi | Aktualny czas: 16.06.2025 - 20:46 |