Globalne spremenljivke so zle

September 4th, 2005

Hecno je rečt “zle”, ampak gre za direkten prevod iz angleške fraze “Globals are evil”.

Kdo jih naredi?
Sistem, ki se zanaša na obstoj globalne spremenljivke, je nestabilen. Pade v trenutku, ko globalka ne obstaja, torej je potrebno imeti strog vrstni red izvajanja delov kode, kar je včasih nemogoče, vedno pa težko.

Kdo jih spreminja?
Dostop do globalne spremenljivke imajo vsi deli kode, lahko jo berejo in pišejo. Ko se v utečenem sistemu pojavi sprememba, ki vpliva na neko globalko, to vpliva na vso kodo, ki to globalko kakorkoli uporablja. Rezultat je največkrat nadležen hrošč, ker je sledenje sprememb v globalkah zelo težko. V hujših primerih je rezultat lahko celo sesutje dela sistema.

Kdo jih bere?
V kvalitetnem sistemu je več igralcev (igralec je lahko razred, paket razredov, funkcija, itd), vsak ima nek namen in s tem povezane vloge in odgovornosti. Z enkapsulacijo stremimo k temu, da noben igralec ne ve več, kot je potrebno, ker lahko le na ta način pišemo bolj ortogonalno kodo. V bolj konkretnem smislu gre za to, da noben igralec nima dostopa do spremenljivk, ki jih ne potrebuje, tiste pa, ki jih potrebuje, mu jih podamo eksplicitno (preko konstruktorja ali preko parametrov).

Kakšen kontekst rabim, da moj razred deluje?
Razred, ki za svoje delovanje uporabi globalko, je vezan v kontekst. Če hočeš uporabiti ta razred nekje drugje, moraš prenesti tudi kontekst. Če v razredu uporabim globalno spremenljivo $x in hočem uporabiti razred še nekje drugje, moram vedeti, da moram v novem projektu zagotoviti $x. Kaj če v tem novem projektu spremenljivko $x že uporabljam? Zanašanje v stilu “v $db imam itak vedno bazo” je slaba naložba v pregledno in stabilno strukturo.

Kaj pa naj?
Pristopi reševanja so različni. Največkrat se vrednosti prenašajo eksplicitno (direktno podajanje metodi ali funkciji). Delna rešitev sta lahko vzorca Singleton in Registry, vendar predstavita nove težave.

Več branja:



4 Responses to “Globalne spremenljivke so zle”

  1. noraguta Says:

    jah eifel ma Design by contract mehanizem za lovlenje nullov. ta pomaga. sam sem singeltone polišpal na raven class atributa v jeziku z primerno mocnim makro sistemom (http://n0raguta.blogspot.com/2004/12/singelton-pattern-in-nemerle-using.html) .
    Je pa ja problem , da so globali “god like” v smislu konteksta in dilanje z nimi zahteva ze pravzaprav ornk meta jezik ako jih hočeš v kompajl tajmu vsaj približn ovrednotit(večni kreh je al bog obstaja al je null in programerji glodajo to kost še bolj veselo kot ostali).

    so pa ja v vecini primerov posledica prototipa pravlenga v produkcijo brez enega konkretnega code revisiona v vecini primerov.

  2. noraguta Says:

    ups sorry nism porajtu da gre za php

  3. dbev fat Says:

    globalne spremenljivke majo povsod iste probleme, neodvisno od jezika. Za začetek zelo otežkočajo (če ne celo onemogočajo) testiranje.

  4. noraguta Says:

    ja no sj , sam udelk je biu php pa mej slaba vbest zagrabva(ga niti dobr ne puznam , vem daj to neki dinamično tipizeranga toj pa bl al mejn tut use).
    drgač pa nism glih pristaš junajtinga. če češ met verificerano kodo greš u funkcjonalne jezike , pa probaš problem modelerat u smislu indukcije , tm pol veš quat je kontest pa kje se kej dugaja , sam toj eksotika bl.