Jaki to wzór i czy powinienem to zrobić?

Robię grę w as3 przy użyciu Flash Develop i Flash CS5. Wszystko jest zorientowane obiektowo. Zastanawiałem się, czy powinienem mieć jedną klasę „bramy”, która ma odwołanie do właściwości do wszystkich instancji innych klas, i po prostu przekazuję tę klasę bramy do nowych obiektów, aby miały dostęp do każdej klasy. Tak jak:

 var block:Block = new Block(gateway);

 //In the block class:
 this.gateway.player.setHealth(100);
 //Or:
 this.gateway.input.lock();

Czy to jest jak singleton czy coś takiego? Powinienem to zrobić?

Jest to tak zwany wzorzec projektowania obiektów kontekstowych i jest lepszy niż wzorzec singletonu.

• Obiekty kontekstowe pomagają w testowaniu, ponieważ można przekazać fałszywe konteksty do funkcji, które chcesz przetestować. Singletony przeszkadzają, ponieważ aby wyśmiewać singletony, musisz sprawić, by nie były singletonami.
• Obiekty kontekstowe wyraźnie określają „stan globalny” i dlatego łatwiej jest je uzasadnić. Jeśli funkcja nie przyjmuje obiektu kontekstu, wiesz, że nie używa żadnego globalnego stanu kontekstu. Nie masz takiej gwarancji w przypadku singletonów lub zmiennych globalnych.
• Obiekty kontekstowe są bardzo nieznacznie wolniejsze, jeśli ich nie używasz, ponieważ dodajesz kolejny parametr do wszystkich wywołań funkcji. Mogą być szybsze niż globale, jeśli ich użyjesz, i prawie zawsze są szybsze niż singletony.
• Obiekty kontekstowe są łatwiejsze do wdrożenia; zwykle żyją na stosie lub stosie w normalny sposób. Singletony mają skomplikowane problemy z wątkami w wielu językach.

Więc nie, to nie jest singleton, jest o wiele lepszy niż singleton.

Jednak nadal jesteś przechodząc wokół się crapload stanu - fakt jesteś utrzymując wszystko w jednej zmiennej lokalnej czyni go bardziej wyraźne, ale wciąż stwarza poważne conflation obaw . Pamiętaj o jednej zasadzie odpowiedzialności . To ma sens, aby istniał kontekst, który jest właścicielem odtwarzacza i bieżący poziom - są powiązane - ale dlaczego ten sam kontekst posiada klawiaturę?

Rozważ różne poziomy kontekstów, na przykład:

• GameplayContext - jest właścicielem gracza, wrogów, geometrii poziomu itp.
• InputContext - posiada uchwyty klawiatury i myszy, zdarzenia wejściowe itp.
• GraphicsContext - posiada tekstury, uchwyt okna itp.
• GlobalContext - jest właścicielem GameplayContext, GraphicsContext i InputContext. W tym miejscu chcesz zastosować wzorzec lokalizatora usług , aby w razie potrzeby móc zamienić niektóre konteksty na inne. Być może, w celu szybkiej iteracji i testów, powinna to być prawdziwa zmienna globalna - po prostu zdaj sobie sprawę, że za każdym razem, gdy z niej korzystasz, narastasz dług technologiczny .

Konteksty te nadal w pewnym stopniu łączą obawy - być może jakiś organizator wydarzeń bierze kontekst rozgrywki i naprawdę potrzebuje tylko gracza - ale obowiązki są jasno określone. Wiesz, że coś, co wymaga GameplayContext, nie załaduje tekstury; coś biorąc InputContext nie może zabić gracza.

To nie wygląda na wzór Singletona. W moim rozumieniu przekazujesz obiekt z odniesieniami do ważnych obiektów gry do wszystkich swoich instancji.

Jeśli byłby to wzór Singleton, miałbyś:

AudioManager.getInstance().playSound(XY);

Podczas gdy w twoim przypadku możesz mieć:

this.gateway.getAudioManager().playSound(XY);

Wygląda zasadniczo tak samo, ale tak naprawdę nie jest. Jeśli chcesz zastąpić AudioManagernową (rozszerzoną klasą) ExtendedAudioManager, uderzyłbyś w ścianę za pomocą wzoru Singleton. Twoje podejście do bramki poradzi sobie z tym dobrze.

Wadą tego podejścia jest to, że będziesz musiał omijać gatewaywszędzie. Wzór lokalizatora usług (zaproponowany przez Joe Wreschnig w tym wątku), wygląda jak wymiana dobre dla „wzór bramy”.

Czasami lepiej jest po prostu uruchomić prostą i bezpośrednią metodę, niż przeprojektowywać rzeczy. Zwłaszcza, gdy jest to mały projekt lub prototyp. Może mógłbyś stworzyć gatewayjakąś zmienną globalną… np. Game.gatewayi biegnij z tym.

Większość rozwiązań tego problemu, w tym wzorzec Singletona, wymaga użycia zmiennych statycznych. Jeśli kiedykolwiek będziesz mieć tylko jednego gracza, możesz po prostu sprawić, by Player był klasą singleton, co oznacza, że ​​możesz uzyskać dostęp do instancji Player poprzez coś takiego jak Player.currentPlayer. Jednak wiele osób szaleje przeciwko Singletonom. Możesz również mieć ResourceManager lub podobną klasę, która zawiera statyczne odniesienia do różnych przydatnych zmiennych globalnych lub całkiem-zmiennych-globalnych. W twoim kodzie równie dobrze możesz uczynić statycznie dostępnymi zmiennymi „Gatewaya” zamiast pompować kod, rozprowadzając go wszędzie.