Czy gry detaliczne używają „inwersji kontroli” i „zastrzyku zależności”?

Wielu bardziej uważnych programistów, których znam, przechodzi na odwrócenie kontroli i wstrzykiwanie zależności w celu obsługi odniesień do obiektów. Patrząc z perspektywy gier Flash, nie znam wszystkich tajników studiów AAA, więc: czy są one używane w świecie gier detalicznych?

Nazywacie to „starannym opracowywaniem oprogramowania”, ja nazywam „bolesną nadinżynierią”. Nie oznacza to, że inwersja kontroli jest zła - w rzeczywistości jej podstawowa definicja jest dobra - ale rozprzestrzenianie się całych ram i metod pracy nad osiągnięciem tego wszystkiego jest mało szalone, szczególnie w połączeniu ze sposobem, w jaki ludzie wyrzucają śmieci idealnie dobre i czyste interfejsy, aby móc wstrzykiwać wymienne komponenty, których 99% czasu nigdy nie wymienisz. Jest to coś, co może wywodzić się wyłącznie ze środowiska korporacyjnego Java i cieszę się, że nie ma tak dużego wsparcia w innych miejscach.

Często argumentem jest to, że nawet jeśli nie zamieniasz komponentów, chcesz móc je testować w izolacji z próbnymi obiektami i tym podobnymi. Obawiam się jednak, że nigdy nie kupię argumentu, że warto nadmuchać i skomplikować interfejs, aby móc go lepiej przetestować. Testowanie potwierdza tylko jedno - że testy działają. Z drugiej strony czyste i minimalne interfejsy mają długą drogę do udowodnienia, że Twój kod działa.

Krótka odpowiedź: tak, ale nie w sposób, w jaki myślisz. Czasami, gdy potrzebujesz zachowania wymiennego, przekazujesz obiekt do konstruktora, który dyktuje część zachowania nowego obiektu. O to chodzi.

Wzór strategii , kompozycja , wstrzykiwanie zależności są bardzo ściśle powiązane.

Ponieważ wzorzec strategii jest formą wstrzykiwania zależności, na przykład silniki takie jak Unity są całkowicie oparte na tej zasadzie. Ich użycie komponentów (wzorzec strategii) jest głęboko osadzone w całym silniku.

Jedną z głównych korzyści poza ponownym użyciem komponentów jest unikanie przerażających głębokich hierarchii klas.

Oto artykuł Micka Westa, który opowiada o tym, jak wprowadził ten system do serii gier Tony Hawk od Neversoft.

Rozwijaj swoją hierarchię

Do niedawna programiści gier konsekwentnie stosowali głęboką hierarchię klas do reprezentowania bytów gier. Fala zaczyna się przesuwać z tego zastosowania głębokich hierarchii do różnych metod, które składają się na obiekt jednostki gry jako agregacja składników ...

Wydaje się, że istnieje wiele zamieszania na temat wzoru Inversion of Control (IoC). Wiele osób utożsamiło go ze Wzorcem Strategii lub Modelem Składowym, ale te porównania nie oddają w rzeczywistości tego, o co chodzi w IoC. IoC naprawdę dotyczy sposobu uzyskania zależności. Dam ci przykład:

class Game {
    void Load() {
        this.Sprite.Load(); // loads resource for drawing later
    }
}

class Sprite {
    void Load() {
        FileReader reader = new FileReader("path/to/resource.gif");
        // load image from file
    }
}

W powyższym jasne jest, że Sprite.Loadma zależność od FileReader. Aby przetestować metodę, potrzebujesz:

1. System plików na miejscu
2. Plik testowy do załadowania z systemu plików
3. Możliwość wyzwalania typowych błędów systemu plików

Pierwsze dwa są oczywiste, ale jeśli chcesz mieć pewność, że obsługa błędów działa zgodnie z oczekiwaniami, naprawdę potrzebujesz również # 3. W obu przypadkach potencjalnie spowolniłeś swoje testy, ponieważ muszą teraz przejść na dysk i prawdopodobnie sprawiłeś, że środowisko testowe jest bardziej skomplikowane.

Celem IoC jest oddzielenie użycia zachowania od jego budowy. Zauważ, że różni się to od wzorca strategii. W przypadku wzorca strategii celem jest kapsułkowanie zachowania, które można ponownie wykorzystać, aby można go było łatwo przedłużyć w przyszłości; nie ma nic do powiedzenia na temat budowy strategii.

Gdybyśmy przepisali Sprite.Loadpowyższą metodę, prawdopodobnie otrzymalibyśmy:

class Sprite {
    void Load(IReader reader) {
        // load image through reader
    }
}

Teraz oddzieliliśmy konstrukcję czytnika od jego użycia. Dlatego podczas testowania można zamienić czytnik testowy. Oznacza to, że środowisko testowe nie potrzebuje już systemu plików, plików testowych i może łatwo symulować zdarzenia błędów.

Zauważ, że zrobiłem dwie rzeczy podczas mojego przepisywania. Stworzyłem interfejs, IReaderktóry zawierał pewne zachowania - tj. Wdrożyłem wzorzec strategii. Ponadto przeniosłem odpowiedzialność za stworzenie odpowiedniego czytelnika na inną klasę.

Może nie potrzebujemy nowej nazwy wzoru do opisania powyższego. Uderza mnie to jako połączenie strategii i wzorców fabrycznych (dla kontenerów IoC). Biorąc to pod uwagę, nie jestem pewien, z jakich powodów ludzie sprzeciwiają się temu wzorowi, ponieważ jest jasne, że rozwiązuje on prawdziwy problem, a na pewno nie jest dla mnie oczywiste, co to ma wspólnego z Javą.

Powiedziałbym, że jest to jedno z wielu narzędzi i jest używane od czasu do czasu. Jak powiedział tenpn, każda metoda, która wprowadza vtables (i ogólnie każdą dodatkową pośrednią) może mieć negatywny wpływ na wydajność, ale jest to coś, o co powinniśmy się martwić tylko w przypadku kodu niskiego poziomu. W przypadku kodu strukturalnego wysokiego poziomu, który tak naprawdę nie stanowi problemu, a IoC może mieć pozytywne korzyści. Wszystko, aby zmniejszyć zależności między klasami i uczynić kod bardziej elastycznym.

Muszę się zgodzić z Kylotanem w tej sprawie. „Wstrzykiwanie zależności” to brzydkie rozwiązanie Java dla brzydkiej wady koncepcyjnej Javy, a jedynym powodem, dla którego ktoś w ogóle patrzy na to w innych językach, jest fakt, że Java staje się pierwszym językiem dla wielu ludzi, a tak naprawdę nie powinno.

Z drugiej strony odwrócenie kontroli jest użytecznym pomysłem, który istnieje od dawna i jest bardzo pomocny, gdy jest właściwie wykonany. (Nie jest to metoda Java / Dependency Injection). Prawdopodobnie robisz to cały czas, jeśli pracujesz w rozsądnym języku programowania. Kiedy po raz pierwszy przeczytałem o całej tej „MKOlowej” sprawie, o której wszyscy bzykali, byłem całkowicie rozczarowany. Odwrócenie kontroli to nic innego jak przekazanie wskaźnika funkcji (lub wskaźnika metody) do procedury lub obiektu, aby pomóc dostosować jego zachowanie.

To pomysł, który istnieje od lat 50. XX wieku. Jest w standardowej bibliotece C (przychodzi na myśl qsort) i wszędzie w Delphi i .NET (programy obsługi / delegatów zdarzeń). Umożliwia staremu kodowi wywoływanie nowego kodu bez konieczności ponownej kompilacji starego kodu i cały czas jest wykorzystywany w silnikach gier.

Nie z mojego doświadczenia. Szkoda, bo kod gry musi być bardzo elastyczny, a takie podejście zdecydowanie by pomogło.

Jednak trzeba powiedzieć, że obie metody mogłyby, w C ++, wprowadzić wirtualne tabele tam, gdzie ich wcześniej nie było, przynosząc ze sobą odpowiedni spadek wydajności.

Nie jestem profesjonalnym twórcą gier i tylko raz próbowałem zaimplementować IoC w C ++, więc to tylko spekulacje.

Podejrzewam jednak, że twórcy gier byliby podejrzliwi wobec IoC, ponieważ oznacza to:

1 / projektowanie wielu interfejsów i wielu małych klas

2 / mając prawie każde ostatnio wywołane połączenie funkcji

Teraz może to być zbieg okoliczności, ale oba wydają się być nieco bardziej skomplikowane i / lub problematyczne dla wydajności w C ++ (który jest szeroko stosowany w grze, prawda?) Niż w Javie, gdzie Internet Rzeczy stał się powszechny (Prawdopodobnie ponieważ było to stosunkowo łatwe, pomóż ludziom zaprojektować bardziej rozsądne hierarchie obiektów, a ponieważ niektórzy wierzyli, że może zmienić pisanie aplikacji w Javie w pisanie aplikacji w XML, ale to kolejna debata: P)

Interesują mnie komentarze, jeśli to w ogóle nie ma sensu;)