Cześć,
pracuję obecnie nad silnikiem graficzno-fizycznym w C++/OpenGL (informacja ta w zasadzie zbędna wiem). Zamierzam zastosować menadżerów, np menadżer zasobów byłby odpowiedzialny za przechowywanie wszelkich assetów, mapowanie assetów z ich nazwami, przesyłanie ich do innych części programu itd... . Zastanawiam się nad użyciem wzorca projektowego Singleton, ponieważ zapewnia on istnienie tylko jednej instancji tej klasy, zezwala na łatwy dostęp do menadżera z innych poziomów programu. Z drugiej strony w internecie łatwo spotkać się z opinią że Singleton to zło wcielone, ponieważ jest specyficzną implementacją zmiennej globalnej, utrudnia jednostkowe testowanie kodu itd... . Z drugiej strony myślałem zastosować klasę o składowych statycznych, ale nie wiem czy jest to dobre rozwiązanie. Słyszałem też o pojęciu "wstrzykiwania zależności", ale nie zbyt wiem jak się za to zabrać, a nie chciałbym porywać się z motyką na słońce. Jak sądzicie czy któreś z tych rozwiązań jest opłacalne, macie może jakieś inne propozycje?
Pozdrawiam,
Dominik.
A czy Twój silnik graficzny będzie uwzględniał pracę równoległą? Wątki i te sprawy? Jeśli tak to singleton narobi Ci więcej kłopotu. Z motyką (a raczej plastikową łopatką) na słońce porwiesz się właśnie używając singletona. Dependency injection i tyle - poczytaj, doucz się i więcej zyskasz na tym, niż byś miał tracić czas na robienie tego na singletonie, a potem przepisywanie na coś lepszego.
Zakładałem oddelegowanie oddzielnych aspektów silnika np. Audio, Fizyka, Grafika, AI do oddzielnych wątków. Dzięki za radę, postaram się douczyć. Jesteś w stanie polecić jakieś merytoryczne źródło (polskie, angielskie, nie ma znaczenia)? Ponieważ przy natłoku wyników wyszukiwaniu trudno mi trochę to jakoś ugryźć.
Polecam książki - papierowe/ebooki - nawet te starsze, bo w świecie wzorców nie zmieniło się zbyt wiele na przestrzeni ostatnich lat. Potem obadaj jak działają frameworki - bo one bardzo często wykorzystują różne wzorce, wtedy zobaczysz gdzie są stosowane i jak wyglądają na żywo.
Swoją drogą zadaj sobie pytanie - co mi da ograniczenie do jednej instancji obiektu?
Jeśli odpowiesz najpierw ponieważ zapewnia on istnienie tylko jednej instancji tej klasy, zezwala na łatwy dostęp do menadżera z innych poziomów programu
to zastanów się jeszcze czy przypadkiem tego samego efektu nie można osiągnąć używając po prostu jednej instancji klasy w projekcie - po prostu raz zrobisz new Object()
i będziesz pilnował, aby nie utworzyć go ponownie.
Singleton to samo zło.
To jest po prostu zmienna globalna, tylko schowana za szpanerskim hasłem.
Każdy początkujący się na to rzuca, bo jest łatwe w zrozumieniu, w stosowaniu i można powiedzieć "mamo używam wzorców projektowych" (parafraza hasła z PHP).
A jakie negatywne konsekwencje niesie? Po pierwsze wszystko co zależy od singletona jest trudne w testowaniu. To jest jego główne ograniczenie.
Po drugie singleton może sprzęgać ze sobą niepowiązane fragmenty kodu, co jest irytujące.
Po trzecie jeśli się ich nadużywa i jest ich wiele, to pojawi się problem kolejności ich inicjalizacji.
Jak chcesz pisać silnik do gry, to zacznij raczej od zaznajomienia się z innymi wzorcami projektowymi, zwłaszcza:
- fabryka - najszczęśniejszej używany wzorzec
- wizytator
- obserwator
- budowniczy
- RAII
axelbest napisał(a):
Polecam książki - papierowe/ebooki - nawet te starsze, bo w świecie wzorców nie zmieniło się zbyt wiele na przestrzeni ostatnich lat.
Absolutnie się z tym nie zgadzam:
A to tylko jeden z wielu wykładów. Część wzorców, z perspektywy czasu, to łata na bieda OOP i bieda języki.