[ OOP ] Global vs. Not Global

Nadaljevanje razprave o globalih in kako se jih znebiti...

Kopernik, hvala za kodo. Moj 'problem' je takle, da se malo bolj podrobno opisem...

Imam nek plugin, ta plugin v svojem konstruktorju poskrbi, zato, da se nalozi tudi objekt, ki predstavlja GUI za ta plugin. No in sele ta gui potrebuje dejansko konekcijo na bazo. Obstaja tudi factory za ta plugin. Vse lepo in prav, da vidim, ce sem prav razumel tvojo kodo.

Naredim plugin za connect na DB, ta plugin se poveze na bazo, etc, etc... Ko naredim svoj plugin, ki kdaj pa kdaj nuca bazo enostavno 'poklicem' se factory in recem 'naj naredi eno instanco tega plugina'...

Hm, nevem, nevem...

Da se enkrat premeljem...

Naredi plugin, ki bo skrbel za dostop do baze.
Naredi klienta.
Povej klientu, da naj nalozi db plugin.
Ustvari se x clientov (drugih), ki vsak zase spet uporabijo db plugin.

Zanimiva ideja, priznam. Ampak ali je to res bolj pregledno in ucinkovito, kot en extern?

Kaj pa ce nimam nekih pluginov in nevem cesa se? Samo en program, razsut na 20 razlicnih filetkov in knjiznic?

Kako bo class jodel vedel, da sem jaz povezan na bazo? Mu bom ob tem, ko ga bom instanciral moral povedati kje je baza? As in:

jodel foo = new jodel("some param", dbpointer);
foo->get_bloody_data();

Ok, fair enough... Ampak od kje ti dbpointer?

al je blo to misljeno, da je dbpointer tisto kar ti vrne zadeva?

jodel foo("some param");
foo.get_bloody_data( DataBaseFactory::OpenMySpecialDataBaseWhichIsLocataedSomewhereSpecial( DataBasePath ) );

Zakaj bi moral to vsak client delati?

> Naredi plugin, ki bo skrbel za dostop do baze.
naredis objekt - database
> Naredi klienta.
naredis drug objekt - client
> Povej klientu, da naj nalozi db plugin.
client.load(database)
> Ustvari se x clientov (drugih), ki vsak zase spet uporabijo > db plugin.
clientN[x].load(database)

Po moje govoriva vsak o svoji stvari Meni se zdi da je vsa razlika med tvojo kodo in mojo predlagano, s katero bi se znebil globalnega s..... ta, da moras v mojem primeru vsem objektom podati se eno spremenljivko (pointer, referenco, whatever). Vsekakor clienti ne dobijo nobenega overheada zaradi tega. Baza ostane skrita in clienti se bolj neodvisni od nje.

Veliko lepse je, ce ima vsak objekt svojo spremenljivko kot pa da jo naredis globalno. Saj sem ze rekel, da je tu tudi moznost razsiritve, ki jo pri globalni spremenljivki nimas.

Je pa vsekakor lepse za koga, ki mora gledati v tvojo kodo. Globalne spremenljivke moras iskat po vsej kodi, po vseh fajlih, medtem ko lokalne spremenljivke so pa - lokalne

Ce pa vseeno pod nobenim pogojem noces lokalnih spremenljivk in imas vedno le 1 bazo (ali kaj drugega) potem si pa poglej singleton. Za pokusino bom tule napisal primer (drugace je to design pattern v recimo knjiznici Loki ali pa Boost in ga je se lazje napisati pa se veliko bolje je organiziran).

// only one instznce of SingletonDB class is ever required
class SingletonDB {
   static SingletonDB* theOne;

   // omejitev: konstruktor nima parametrov
   SingletonDB()  {}
public:
   static SingletonDB* instance() {
      if (theOne == 0)
         theOne = new SingletonDB;
      return theOne;
   }

   // ostalo pa skoraj identicno implementaciji baze
   // oz. pointerja (ali handlea) na bazo
};

// tole gre v .cpp fajl, zgornje pa lahko v header
SingletonDB* SingletonDB::theOne = 0;

Zdaj ti lahko vsak tvoj client dostopa do baze takole:

SingletonDB::instance()->

Znebis se globalnih spremenljivk, sploh pa extern (se posebno tecna sorta IMHO, ker za njih ne ves kje so definirane) spremenljivk, vsak objekt, ki hoce uporabljati bazo mora includati zgornji header, vse je bolj pregledno.

Sicer vem da bom s tem vprasanjem izdal totalno svoje nepoznavanje globalnih spremenljivk, ampak bm vseeno tvegal. Ali ni treba spremenljivke definirati v nekem .cpp fajlu? To sprasujem, ker pravis "Pri meni so vse deklaracije v globals.h"

V mojem primeru je tako, da imam cca 5 pluginov, ki so sami zase neodvisni in pa glavni program, ki nalaga te plugine.

Zdaj, ce bi jaz delal stvari 'tako kot treba' potem bi bili te plugini 100% neodvisni ampak niso. Se vedno imajo skupno bazo in nekaj malenkosti (user settings in tako naprej).

Vsak plugin je svoj .so library. Potem je tukaj se main, ki skrbi za nalaganje teh pluginov. Vsi skupaj pa uporabljajo en common library, ki vsebuje dolocene funkcije, ki so vsem skupni.

Jaz imam v globals.h deklarirano recimo

QSqlDatabase *defaultDB;

Ta header je includan samo v mainu, drugje pa nikjer, ker drugace pride do konfliktov pri linkanju, ko se common lib linka z ostalimi knjiznicami. Definicija defaultDB se prav tako naredi v mainu.

V tistih cpp-jih kjer potem potrebujem defaultDB potem samo extern deklaracijo naredim.

extern QSqlDatabase *defaultDB;

Tako je problem resen.

Najbrz ni idealna resiteva ampak je pa precej prirocna, ker ni treba tega pointerja vlacit naokrog po vseh objektih in pingpongat sem ter tja. Kode je precej manj, performance je IMO isti. Preglednost? Nevem, meni je stvar cisto pregledna :))

kako pa lahko lokalno lockaš globalne varibale(z CS), ako ne poznaš celotnega flowa aplikacije ne da bi stem zajebal druge??? mutexi pač niso odgovor ker degradirajo performance. kako potem hendlaš napake v db connectionu če pride le do tega??? implementiraš visitor pattern da obvestiš le vse komponente da je prišlo do neljubega dogodka?


v global sodijo enumi in konstante , razen ce ne delaš sam in imaš vse v glavi , v ostalem omejuješ scope. na to kar je relavantno in ga fillaš le z dato , katera spada tja. drugače se boš zaklal, čisto preprosto. če stvar ni prezahtevna kamot zdefiniraš scope classe in jih po potrebi inheritaš , c++ pozna multiple inheritance in jih namečeš pač po potrebi. še bolje je pa kopernikov pristop.