ovako instant mi pada napamet da ili napravis CFG static posto pretpostavljam da uglavnom citas vrednosti iz tog objekta ili da ga prosledis konstruktoru, mozda kroz neki interfejs kolko da ih ne couplujes previse

To je i meni palo na pamet. Ali pogledaj kako sam ja to sada nekako smislio samo sto ovo moje resenje zahteva da svaka klasa mora da nasledi odredjenu klasu npr Application.

Evo primer Application klase:



Tako da sada mogu objektima da pristupam jedino ako nasledim klasu Application kao sto sada radim



Ali to je samo moguce ako nasledim trenutnu klasu koja mi ucitava ostale klase kao jedan ogroman super objekat.

Nisam radio sa referencama (&) sta mislis o tome? ako bih napravio jedan base file koji bi ucitavao i instancirao sve sto je nephodno dali pomocu referenci mogu ovo da odradim? Meni te reference uopste nisu jasne kada se radi sa funkcijama i klasama, jedno sto kapiram rad sa promenjivama.

Ovako na blic nisam siguran da vidim neki benefit (a vidim dosta ogranicenja i problema) zasto bas svaka klasa nasledjuje Application, al ok.
Ako mozes da ubacis cfg u application, onda ga svi ostali nasledjuju. A php valjda po "defaultu" objekte prosledjuje funkcijama kao reference, ako hoces da imas kopiju moras da uradis clone.

Sad iz znatizelje, gde si video taj pattern ili praksu da sve klase naslede jednu super klasu?

MA nisam nigde video nago sam nesto eksperimentisao i iskren da budem meni se to uopste nesvidja da mi svaka klasa nasledjuje App.
Mislim da cu na kraju da se opredelim za statiku.

I meni deluje kao prilicno los princip, skoro pa narusava sve za sta se OOP svet u php-u borio. Static pattern je ok, ali kao i svaki ima svoje prednosti i mane. Ja ga vidim kao idealni pattern za CNF koji si spomenuo malopre (bar ja obicno za config koristim static pattern) ali pre nego pocnes da koristis iskljucivo jedan pattern za sve zivo, prouci malo neke od popularnih i vec proverenih sablona/patterna, mozda vec ima resenja za to sto pokusavas da izvedes.

Kao i sve u programiranju, pokusavamo da ne izmislimo toplu vodu vec da resimo problem koji je ispred nas

To si skroz upravi. Razumem ja sve to koristim singleton i factory jedino kada moram. Eo npr u ovoj aplikaciji koju radim jedina stavka koja je singleton je BaseController. Ok hvala na utrosenom vremenu.

Singleton ili static CFG, isto s*anje, drugo pakovanje. Globalna promenljiva je globalna, ma kako je zvali.

Dakle, ako ti je lepse da koristis Singleton, sa privatnim konstruktorom poput: $cfg = CFG::getInstance(); echo $cfg->logPath; onda koristi Singleton. Ako ti je lepse da to bude CFG::get('log_path'), koristi static metod. Oba resenja su jednako dobra/losa.

A kad god stignes, izbegavaj globalne promenljive, kako god da ih zoves. Neka Dependency Injection bude s tobom. :)

Ma ok je to samo za ucitavanje za Konfiguracionih podataka ($cfg). Ja sam hteo nesto da izmajmunisem da napravim metodu koja sve klase koje ja definisem uraditi jednim objektom. Tako nesto sam video pre neki dan na Codeigniter. Covek je uradio slicno mom primeru predhodnom, ucitao je sve klase kao jedan super objekat i sada te instace su mu dostupne u bilo kojoj klasi > metodi bez ikakve potrebe ponovnog instanciranja u bilo kojoj klasi. Mada static radi posao nemogu da se zalim, samo pokusavam da skontam taj princip.

postavi link ka primeru ako ga jos imas, da vidimo kako je to uradio

Nemam link, jedino ti preostaje da downloadujes CI i da pogledas njegov Controller i Base Controller. Odatle sam ja uzeo primer sto sam stavio gore

Davno sam koristio CI, ali prilicno sam siguran da su tamo sve klase dostupne tako sto su pri inicijalizaciji CI kontrolera setovane istom kao property?
Znaci kad se inicializuje base kontroler, u loaderu se setuju sve setovane klase kao i neke defaultne. Tako da posle mozes da ih pozivas sa
$ci = get_instance();
$ci->db;
$ci->view;
$ci->....

Ako hoces da ovo imitiras, onda bi trebao da u tvojoj Application klasi uradis isto, prilikom inicializacije same klase setujes sve propertije i posle ih imas dostupne u svim klasama koje nasledjuju Application.

Evo ovako iz glave singleton pattern.


Nakon ovoga bilo gdje dobijaš istu instancu pozivom:

@Buntu nije meni problem u Singletonu razumem ja to jako dobro, skontao sam ja odma da ci radi singleton.

@dakipro da upravu si on sve poziva pomocu $CI->get_instance();

Ali vidis kako on isto ucitava klase kroz foreach koji sam ja gore naveo, i onda su mu u svakom kotroleru dostupne instance tipa ovoga.



On sve to ucitava u Base Controller a posle nasledjuje i setuje ga u konstruktoru __patern() . A da nema ono initializovanje on nebi mogao da
radi $this->load->view vec bi morao da setuje property $load i da initializuje $view = new View();

Mislim zapetljano je skroz ali opet kazem lepo izgleda taj nacin programiranja.... Sve u svemu resio sam sa static

Pa da, on ima $this->view zato sto u CI svi kontroleri nasledjuju BAse kontroler, isto kao i ti sto zelis da nasledis Aplication.
kao sto sam i u proslom postu napisao "Ako hoces da ovo imitiras, onda bi trebao da u tvojoj Application klasi uradis isto, prilikom inicializacije same klase setujes sve propertije i posle ih imas dostupne u svim klasama koje nasledjuju Application. " kao sto si i poceo sa tim foreachom

Ne znam da li je to možda već pomenuto u nekom odgovoru, ali mislim da se to što tebi treba postiže uvođenjem Service Container-a (dependency injection container). Preporučujem ti da progooglaš na tu temu, kako bi stekao uvid u to šta je uopšte Service Container i na koji način se on koristi. Service Container se inače zasniva na Dependency Injection konceptu, pa bi zapravo bilo dobro da se najpre pozabaviš proučavanjem tog aspekta.

Ja inače do sada nisam imao neku preteranu potrebu za korišćenjem Service Container-a, ali ako bi to bilo neophodno, moj favorit je Pimple. On spada u kategoriju tkz. micro-service container-a. Dosta je lagan, sastoji se od jedne jedine klase, a njegovo funkcionisanje se u velikoj meri oslanja na anonymous f-je (closures), tako da ga možeš koristiti samo u okviru PHP 5.3.

Naravno, kao i za mnoge druge stvari, i izbor Service Container-a zavisi od razmere projekta u kojeg želiš da ga integrišeš. Pimple će verovatno završavati posao u nekim manjim projektima, dok bi za veće trebalo razmisliti o rešenjima kao što je npr. Symfony-ev service container.

Evo par odličnih članaka na temu Dependency Injection dizajn pattern-a, sa PHP primerima, naravno , kako bi bolje razumeo celu tu priču:
http://www.slideshare.net/fabpot/dependency-injectionzendcon2010
http://fabien.potencier.org/ar...1/what-is-dependency-injection
http://phpmaster.com/managing-class-dependencies-1/
http://phpmaster.com/managing-class-dependencies-2/

A da jednostavno počnes koristiti jedan od framework-a... nije loša ideja? :)