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!!

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.

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ń.