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 :/
0
0
A nie chodzi o globalny stan? Najpierw sprecyzuj pytanie, bo nie wiadomo z czym polemizować :P
0
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).
0
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.
0
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.
1
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.
0
@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.