Kiedy można użyć zmiennej globalnej?

Ok, więc to naprawdę jest trochę diabelskie pytanie.

Kiedy zmienne globalne są w porządku, a jeśli nigdy, to czego byś użył jako alternatywy?

Ciekawym przypadkiem pobocznym tego pytania, w jaki sposób publiczne pole klasy statycznej różni się od globalnego?

O ile mi wiadomo, publiczne pole statyczne jest zasadniczo globalne, biorąc pod uwagę, że można je wywoływać z dowolnego miejsca, z tym wyjątkiem, że nie zatyka przestrzeni nazw.

Jedyny raz, kiedy osobiście używam zmiennych „globalnych” w moim kodzie, mają postać publicznych pól statycznych, które są niezmienne. W tym przypadku nie trzeba się martwić, że wartość zostanie przekręcona przez inne części programu i oczywiście jest o wiele ładniejsza niż posiadanie tuzina zmiennych o takich samych stałych wartościach w każdej klasie.

Osobiście używam globałów do konfiguracji środowiska wykonawczego - jeśli właściwość konfiguracji jest ładowana przy uruchamianiu aplikacji i zmienia się rzadko (i tylko wtedy z jednego miejsca), przekazanie jej do każdej metody, która może wymagać użycia, jest okropne i podatne na błędy. w pewnym momencie. Lepiej jest użyć czegoś, co można wprowadzić z dowolnego miejsca, które tego potrzebuje, ponieważ nie zaśmieca to i nie zasłania podpisów metod i stron wywołujących.

Wyłączając systemy czasu rzeczywistego / wbudowane, naprawdę powinieneś używać globałów tylko do stałych wartości. Jeśli uważasz, że nie możesz rozwiązać problemu bez nich, prawdopodobnie robisz coś złego.

Spójrz również na wzór Singleton , zimno zapewnia lepsze rozwiązanie dla globali w sytuacjach, gdy potrzebujesz czegoś, aby mieć globalny punkt dostępu.

Problem ze zmiennymi globalnymi polega na tym, że musisz być ich świadomym wszędzie w kodzie. Jednak gdy już zdecydujesz, że musisz wiedzieć o konkretnej globalnej kulturze, nie będziesz już więcej tracić z jej intensywnego korzystania. Dlatego uważam, że powinieneś mieć bardzo niewiele zmiennych globalnych, ale tych, które masz, powinieneś uzyskać maksymalny przebieg.

Innym przykładem czegoś, co tak myślę, jest użycie mixin w Ruby.

Chodzi o przestrzenie nazw.

Wyobraź sobie przez chwilę, że wszyscy na świecie mają to samo nazwisko. Co za bałagan.

(W Indiach sikhowie mają to samo nazwisko: Singh - spójrz)

Wersja skrócona: gdy ułatwia zrozumienie programu. Zazwyczaj przypadki to jakiś rodzaj globalnego stanu lub zasobu statycznego, który jest szeroko stosowany.

Długa wersja: Tom Hawtin powiedział „z upiorną akcją na odległość” ... to jest dokładnie problem z globalsami - musisz wiedzieć, gdzie jest używany i jak, lub możesz dostać naprawdę dziwne i trudne do wyśledzenia robaki. Miejscowi to nic innego jak strategia zmniejszania zakresu tego, co programiści muszą zrozumieć, aby rozumować o programie.

Inną stroną problemu związanego z wiedzą, gdzie są używane, jest to, że możesz skończyć z duplikatami globali - w takim przypadku rzeczy mogą stać się naprawdę dziwne, ponieważ większość programów dostaje i ustawia var1, podczas gdy w kilku miejscach var2 służy do przechowywania te same informacje. Szczególnie, gdy wiele osób pracuje nad tym samym kodem. IDE mogą być pomocne w znalezieniu użycia zmniejszającego koszt globałów, ale nie robią nic dla duplikatów.

Im więcej globali, tym trudniej jest śledzić, co się z nimi dzieje. Powinny być nieliczne i dalekie.

Dwie gotcha z globalsami i singletonami to testowalność i możliwość wdrożenia.

Do testowania widziałem zbyt wiele zbyt skomplikowanych uprzęży testowych, aby poradzić sobie ze źle zaplanowanymi globalnymi i singletonowymi cyklami życia. Upewnij się, że każdy taki obiekt ma jasne i proste zasady uruchamiania i burzenia.

Jeśli chodzi o możliwość wdrożenia, należy rozważyć dwa przypadki. Po pierwsze, jak będzie żył Twój obiekt globalny? Czy jest to biblioteka statyczna czy dynamiczna? Jeśli ten obiekt globalny zostanie ponownie wykorzystany do wtyczki, czy dostaniesz dodatkowe kopie? Po drugie, co się stanie, gdy ten obiekt globalny zostanie upuszczony do aplikacji równoległej? Czy to jest bezpieczne dla wątków?

Ogólnie rzecz biorąc, uważam, że te przyczyny oznaczają, że globały i singletony są używane tylko wyjątkowo.

Rozwój krytycznych systemów wbudowanych zwykle wymaga użycia zmiennych globalnych.

Rozmiary stosów są niewielkie, wszystko jest przydzielane statycznie ( malloc()jest zabronione), zmienne globalne są ukryte poza biblioteką, do której należą.

W okropnej bazie kodu VB6, która nadużywa globałów, tak jakby nie było jutra, jestem winna wprowadzenia nowej:

Global CsExt As New TheAppBeingRewrittenInCSharpWhileVb6CodeIsStillBeingMaintained

Myślę, że jest to jeden z niewielu poprawnych przypadków użycia dla obiektu globalnego.