Słyszę sprzeczne opinie, takie jak:
- „Dedykowane klasy menedżerskie prawie nigdy nie są odpowiednim narzędziem inżynieryjnym”
- „Zajęcia dedykowanego menedżera są (obecnie) najlepszym sposobem na przetrwanie dużego projektu z tysiącami zasobów”
Weźmy klasyczną klasę ResourceManager, która ma następującą funkcjonalność:
- Ładuje zasoby (tekstury, audio, modele 3D itp.)
- Zapewnia, że zasoby są ładowane tylko raz, utrzymując pamięć podręczną
- Odnośnik zlicza zasoby, aby ustalić, czy można je zwolnić
- Ukrywa skąd pochodzą rzeczywiste zasoby (np. Może to być jeden plik na zasób lub wszystkie zasoby w jednym pliku pakietu, lub zasoby mogą być nawet ładowane przez sieć)
- Może przeładowywać zasoby bez ponownego uruchamiania programu, co jest niezwykle przydatne dla artystów pracujących nad grą.
Weźmy również argument „singletony są złe” ze stołu udając, że te obiekty ResourceManager nie są singletonami, a zamiast tego są przekazywane poprzez wstrzykiwanie zależności .
Następnie jest argument „użyj fabryki” lub „nazwij to fabryką”. Mój problem polega na tym, że tak, jest to fabryka, ale jest to również pamięć podręczna i przeładowujący (z powodu braku lepszego słowa). Nazwanie go fabryką nie opisuje go poprawnie, a jeśli sprawię, że będzie to właściwa fabryka, to gdzie zostanie wprowadzone buforowanie i ponowne ładowanie?
Zgadzam się, że klasy „Managera” często są objawem złej architektury, ale w tym konkretnym przypadku, w jaki sposób można je zrestrukturyzować i zachować całą funkcjonalność ? Czy jest to sytuacja, w której klasa „Manager” jest rzeczywiście odpowiednia?