Staticke metode losa ili dobra praksa?

[Djuki]

Originalno napisao _korso_

Hteo bih samo da dodam jednu cinjenicu.
Trenutno radim na app koja ima oko 1200 klasa.....

Koji IoC/DI biblioteku koristiš ?

[_korso_]

Custom pravljena. Bazirana je na prvoj verziji sf DI komponente.

[webarto]

@_korso_ Svaka čast. O tome pričam.

[Djuki]

_korso_ i webarto Hvala na odgovoru.

Jel može mali snipet koda u kojem IoC isporučuje objekat koji je uvek jedna te ista instanca ?

Mislim na klijentski deo, ne sama IoC implemenacija.

[webarto]

@Djuki ne želim da ispadne da sam ja zapeo za nešto, ali za svaki "zašto koristiti singleton" mogu naći (možda) bolju alternativu. Static ima svoju svrhu koja se često zloupotrebi.

@jablan nije se dobro izrazio, Foo:: je uvijek Foo, a kada je $foo-> onda onda može biti i Bar
https://gist.github.com/nikic/5213689 obrati pažnju na "me", i da, ima 18 godina, dobio je respekt radi ovakvih stvari a ne zato što je glasan.
To su funkcije, a PHP takođe ima i builtin klase.. daleko da je sve od savršenog. PHP > Java said by C++ guys

@mangia tako se i radi u većini slučajeva.

[_korso_]

@Djuki Naravno.

Primer je timer klasa koja meri vremena u requestu, od toga koliko se izvrsavaju upiti (svaki pojedinacno jer postoje dve baze Postgres i Mongo koje se istovremeno koriste), do toga koliko se izvrsavaju odredjene metode koje imaju zahtevan posao da odrade (opet u Domain delu appa), te i sam request. Idealan primer za upotrebu singleton klase.

PHP kôd:

//sys.timer servis - konfiguracija
1. $serviceContainer
    ->register('sys.timer', 'OP\Library\Utilities\SysTimer')
    ->setArguments(['request_time', $kernel->getRequestStartTime()])
    ->setShared(true);// I

//negde u kodu koji kreira druge servis objekte koji koriste servis konfigurisan u 1.
2. $serviceContainer->getService('sys.timer'/*, II */);

3.
class PgPdoAdapter {
    public function __construct(SysTimer $timer) {}
}

class MongoAdapter {
    public function __construct(SysTimer $timer) {}
}

class ShutdownHandler {
    public function __construct(SysTimer $timer) {}
}

class ContactsRepository {
    public function setSysTimer(SysTimer $timer) {}
} 


Dakle, svaki "service" kako nazivamo ove objekte konfigurisane kroz ServiceContainer, je po defaultu ne deljen. Zato u 1. imamo liniju I. Svaki poziv za tim objektom kao u 2. ce vratiti istu instancu SysTimer objekta. Ukoliko zelimo da nam uvek poziv 2. vraca razlicit novo kreirani objekat, onda mozemo da izostavimo u 1. liniju I.

Ono sto sam stavio u 2. kao II je - prvobitno je bilo moguce da u samom pozivu prosledimo da li je instanca deljena (da li je singleton-like ili ne). I ovakva konfiguracija prilikom poziva `getService` metode ima prednost u odnosu na konfiguraciju 1. u liniji I. Medjutim, ispostavilo se je da ovakva fleksibilnost koja je na prvi pogled primamljiva, za kasnije odrzavanje je nocna mora - jer moramo da pratimo `getService` pozive (mada uglavnom ih ima po 1 za odredjeni servis). Posle nekog vremena je ta funkcionalnost izbacena, gde je zakljucak bio - ako nam ovako nesto treba, ili nesto ne radimo kako treba ili jednostavno sam objekat nije singleton-like.

U 3. mozes videti da je servis opcionalan za ContactsRepository klasu pa se injectuje kroz setter.

Bilo kako bilo, ovo je samo vrh ledenog brega oko koriscenja DI prakse za kreiranje grafa objekata.

I za kraj bih rekao svoje iskustvo povodom koriscenja DI prakse u zadnje 2 godine. Iskreno, prvo sam bio skeptik. Java mi se smucila (licno i subjektivno misljenje), a ovo je dosta slicno sto sam tamo radio. Medjutim, pokazalo se u praksi kao odlicno resenje, ali... Nije bas lako za objasniti svima, trazi dosta discipline, izgleda komplikovano. Sto "tezi" objekat, veca konfiguracija. Ovaj primer koji sam dao je najprostiji moguci. Sama konfiguracija je dosta komplikovana za nekog ko prvi put gleda u sam kod. Sa klijent strane se uvek svodi na `getService`. Planirao sam da pogledam kako to rade u nekim drugim jezicima koji imaju totalno drugu viziju. I oni imaju iste probleme.

Interesantan je pristup u javascript svetu AngularJs-a. Oni "skeniraju" i parsuju kod pre izvrsavanja. Kako svi dependency se deklarisu u konstruktoru po nekom kvazi tipu, sam Angular na osnovu toga radi magiju i ne treba ti konfiguracija. On sam zakljucuje sta treba da radi i koji servis treba da kreira prvo. Mada i Angular ima Javu za uzor (tj. sam Misko - http://misko.hevery.com - je glavni autor). Nije ovo tesko izvesti, probao sam sa DI komponentom - gore pomenutom. Ali su pitanje, performanse - gde mora neko kesiranje, kao i to da konstruktori mogu biti sa *mnogo* objekata - sto mi se ne svidja. Slican fora je i sa requireJs-om.

Sve u svemu, ovo radi odlican posao, ali ono sto mu nedostaje je malo manja kompleksnost i eventualno malo manje konfiguracije.

[_korso_]

@webarto
100% se slazem sa tobom sto se tice Nikite Popova. Momak koji samo cuti i radi. Mozda i najmanje eksponiran u PHP zajednici. Salje RFC za RFC-om. Ostali mnogo iskusniji i stariji samo s*** po mailing listama i sta god neko kasvetno predlozi, tu su da ga svojim negativnim glasom zakopaju, kao bi ocuvali j*** BC verzije koja je stara 10 godina kao i "cuvene" PHP native f-je radi vizije koju PHP ima po njima. Zalosno je sto su oni nekako slozni kada najbolje stvari mogu da pokvare svojim glasovima.

Koliko pratim, mnogima se smucio taj "prizvuk" u core PHP zajednici - dok ovaj decko, ne preza. Odmah stigne neki drugi RFC, patch ili nesto trece. Zbog tog pros*** mnogih, pitanje je i PHP dokle ce stici.

Da trenutno nismo u firmi vezani za PHP i skoro pa je nemoguce promeniti platformu barem u narednih godinu dana, iz ovih stopa bih uzeo nesto drugo.

[svlada]

Originalno napisao Djuki

_korso_ i webarto Hvala na odgovoru.

Jel može mali snipet koda u kojem IoC isporučuje objekat koji je uvek jedna te ista instanca ?

Mislim na klijentski deo, ne sama IoC implemenacija.

U Springu je default ponašanje da container vraća uvek istu istancu objekta (singleton scope), što je i logično jer kontroleri, servisi, dao sloj obično nemaju neko stanje.