Gdzieś przeczytałem coś w stylu "w tym etapie pozbyliśmy się globalnych klas" czy coś takiego (nie pamiętam ale chyba chodziło o statyczne klasy). Moje pytanie, dlaczego się tego nie używa? Żeby zapewnić 'upakowanie' klasy w jednym namespacie? Czy co? I honestly don't know :/
A nie chodzi o globalny stan? Najpierw sprecyzuj pytanie, bo nie wiadomo z czym polemizować :P
Chodzi mi o statyczne klasy do których jest dostęp z każdego miejsca programu (i które coś robią, np łączą się z bazą albo coś takiego, a nie trzymają stałe).
Klasa "globalna" to antywzorzec singleton, w skrócie robi problem bo:
- trzyma jeden stan
- ciężko (nie da się?) zmockować
- tworzy zależność w obiekcie, której niesposób "nadpisać"
Aby pozbyć się klas "globalnych" / singletnów, można wykorzystać Dependency Injection, czyli "wstrzykujesz" zależności (inne obiekty) do obiektu, którego używasz, ewentualnie Service Locator, ale też wiele osób twierdzi, że to anty wzorzec.
Globalne statyczne klasy, które realizują jakąś logikę są częstym źródłem problemów, zwłaszcza jeśli są używane przez wiele innych klas.
Najprostsza odpowiedz to dlatego, ze zalozenie ze cos moze istniec tylko w jednej instancji jest prawie zawsze bledne.
Drugi powod to ze prawie zawsze zle to dziala na wielu watkach (data race) i zawsze spedzisz minimum godzine na ogarniecie o co chodzi i co sie dzieje i czemu nie dziala.
Trzeci powod ze ciezko sie analizuje logike, bo nie wiadomo kto jest wlascicielem danych i kto moze je zmieniac (bo kazdy moze).
Czwarty powod to jak zaczniesz dzielic swoj kod na niezalezne moduly to z kazda zmienna globalna bedziesz cierpial.
@TomRiddle chodzi tu raczej o obiekty trzymające stan. Gdybyś miał bezstanowe serwisy realizujące pewne usługi to nie ma większego problemu. Ale jeśli musisz się bawić w jakieś synchronizacje to pojawiają się kłopoty.