Staticke metode losa ili dobra praksa?
 

Zdravo svima,

Zbunjuje me ova upotreba ovih statickih metoda, posebno u nekim framework-cima.

Npr uporedjivao sam CodeIgniter i FuelPHP framework. Nasao sam sledece:

http://ilikekillnerds.com/2011/04/co...er-vs-fuelphp/

Tamo pise sledece:

I kada pogledam FuelPHP u Doc pun primera, Clasa::metoda(arg)

Pa sam malo pogledao na googlu i nasao clanak , gde maksimalno treba izbegavati static metode i taj nacin pristupa.

http://r.je/static-methods-bad-practice.html


Na netu sam procitao da je FuelPHP bolji framework od CI, a onda kada pogledam ove silne static metode, ispada da je gori od CI.

Posto sam zbunjen, da li neko moze da mi objasni smisao silnih upotreba static metoda kao u FuelPHP (dovoljno je da bacite par pogleda na doc, tamo je sve kroz static)? Da li se static treba koristiti veoma retko? I sta je ovde istina? Da li je Fuel dobar framework na nekom solidnom putu ili ne ( ovde mislim na koriscenje php 5.3 mogucnosti) ?

Ne razumem se u PHP, ali iz iskustava sa drugim jezicima statičke metode nisu loše same po sebi. Ako je to neka utility funkcija koja ne zavisi od ostatka koda, nema svoje stanje, i nema potrebe da se nasleđuje, zašto ne bi bila statička? Bolje nego da instanciraš svaki put utility klasu samo da bi zadovoljio formu da se ne koriste statičke metode.

Sa druge strane statičke promenljive su već mnogo nezgodnije i mogu da dovedu do toga da ne znaš ko sve piše u tu promenljivu, u kom redosledu, kako se inicijalizuje, da li je uopšte bitan redosled, da li ima problema ako se modifikuje iz više niti, itd.

To da... Ovde u Fuel on pravi objekat preko staticke metode... Nije mi zato jasno zasto se to forsira a ne klasicno $db = new DB(); Verovatno ima neki poseban razlog, ali ne razumem bas kao sto sam i pitao:"Takes advantage of PHP static variables and functions". Nije mi jasna bas ova prednost.

Najčešći razlog za statičko pozivanje je zamena za GLOBAL instrukciju jer su nazivi klasa globalno dostupne svugde.
Ovo samo po sebi nije problem, naročito ako koristiš namespace.

Ono što je loše je što blokiraš sebe da kasnije napraviš nasleđenu klasu i nju upotrebiš umesto ove prve. Svugde u kodu si čvrsto vezan za ime klase a ne možeš napraviti nasleđenu klasu sa istim imenom.

Po meni, ako praviš veći projekat, treba izbegavati statičko pozivanje jer ne možeš biti siguran dali će ti kasnije zatrebati.
Za manji je svejedno.

Svi ozbiljni frejmwork-ci imaju neki sistem plugin-a u kojem je uobičajno da se nasleđuju originalne klase i smatram sputavanjem ako FW koristi mahom statičke pozive.

Ne znam za ovaj konkretan slucaju ali cesto je Singleton (pattern) razlog za instanciranje objekta preko jednog statickog metoda pri cemu je tom objektu konstruktor sakriven (private) i tako dolazi da imas samo jednu instancu tog objekta u citavoj aplikaciji.
To je recimo za rad sa bazom, bila ona light poput SQLite gdje ne mogu vishe procesa da zakljucaju isti fajl istovremeno ili poput pravih DB servera redukujes broj paralelnih konekcija na bazu (taj singleton brine o tome), vrlo korisno.

Pored Singleton koji je pomenuo Miško, imaš i Factory pattern http://en.wikipedia.org/wiki/Factory_method_pattern kojim dobijaš to da ne moraš da specificiraš klasu objekta koji se kreira, već to ostavljaš factory metodi (ili factory klasi). To je vrlo popularno u Javi (a očigledno i u Javinom vanbračnom detetu PHPu hehe).

Ne postoje statičke metode.

http://nikic.github.com/2011/12/27/D...ASP-SOLID.html

I uzeo si najlošiji code za primjer. Pogledaj: http://framework.zend.com/ ili http://symfony.com/

Ne kapiram:

A kad napišeš $foo = new Foo(); to onda nije tightly coupling to the Foo class?

Mislim, većina tog članka ima smisla (mada se meni lično povraća kad vidim akronime, jer me podseća na faks i bubanje stvari napamet), ali ne baš sve, posebno imajući u vidu da je PHP, ponavljam, dinamički jezik (ili je barem bio pre nego što vam je Java uvalila trojanca). BTW, taj nikic koji je dosta glasan u PHP communityju ima 18 godina...

Uzgred, nisu li svih koliko hiljada PHP builtin funkcija zapravo statičke metode u globalnom nejmspejsu? Jel se sad pravimo da ne postoje ili šta?

da li je obicna funkcija ili staticna metoda u nekoj klasi je isto sa tvoje tacke gledista, razlika je u tome da u CI moras da napises ono skrnavo $this->load(....), a kod fuela i ostalih koji su se potrudili da nameste autoload (CI NEMA AUTOLOAD) koriste se klase sa staticnim metodama (NekaKlasa::metoda()) koje medjusobno nisu povezane. Ono sto si nasao na netu je problem sa staticnim varijablama u nekoj klasi i kako se to odrazava na testiranje koda.

offtopic: CI menja licencu od verzije 3.0 u neku koja samo njima odgovara, FuelPHP je napuseten od onih koji su ga pravili, najnoviji buzz je Laravel ako vec ucis nesto onda kreni sa njime

Ci mijenja licencu, fuel napušten, kohana nema dokumentacije, Laravel dolazi,...

Ispada da pametni programeri naprave svoj FW i uživaju...

^ Generalno uvek su tu sf2 i zf2 koji su se odrzali zadnjih n godina za one koji zele pouzdan fw.

To da samo za neke manje projekte...

Fuel sprema verziju 2

https://github.com/fuelphp/fuelphp

Nije napusten samo oslabljen sastavom, ali nastavlja dalje, sa composerom i sa modernim primesama.

U verziji 2 nema statickih poziva.

Sto se tice stabilnosti Fuel je dosta stabilan jer se ne ponasa kao Kohana koja sa novim verzijama razbija srari kod. To je uradio i Laravel sa verzijom 4 (Moguc prelayak sa 3 ali uy dosta promena i truda).

Nisam procitao cijeli clanak, jer sam odustao kod njegovog objasnjavanja zasto je Singleton losh... Naivno je pokusavati rijesiti jedan problem sa Singletonom (ili bilo kojom drugom metodom) i ako ne uspijes - jer taj metod nije za to predvidjen proglasiti taj metod loshim...
Nema potrebe da objasnjavam, ko hoce moze procitati komentare pametnih i ljudima kojima se dalo da objasne guru-u zasto se sta koristi.

Ne kontam kakve veze ima Dependency Injection sa ovim? Odgovorim na sva pitanja i dodjem u tacku 'Procitaj sta je Depency Injection'...

ali najbolji je prvi post na onoj tamo temi 'Every programmer is a programming guru.'...

Kakve veze ima nečiji komentar? Podforum je PHP i spominješ Singleton. Možeš li navesti i jednu (opravdanu) primjenu tog patterna?

http://www.phparch.com/2010/03/stati...hoose-neither/
http://www.slideshare.net/go_oh/sing...r-applications

^ Oni imaju više od 18 godina ako nešto znači.

Precizan odgovor. A sto se tice off, mislim da ti ljudi koje si pomenuo nisu bitan faktor. Oni su prvo napustili CI (a CI nastavio da zivi i posle njih), sad im ne odovara Fuel (a on se i dalje razvija), pa nasli nesto trece (pitam se do kada). Ako se njima opterecujemo onda ni jedan fw necu uciti jer ni jedan ne valja.. Nisu ni oni najpametniji na svet pa moram da ih pratim. Ovde je bitno kolika je jaka podrska, community. Dzaba je nesto novo i dobro ako nema ni jedan dodatak (plugin). Onda cu radije da ostanem na CI (koji ima podrsku za mnogo stvari + dodaci)nego da se hvalim da radim full OOP, a ovamo se ubijam od posla. Na kraju krajeva svi rade za novac i to se jedino racuna.

Namena Singletona i DI se ne poklapaju i Di ne moze zameniti Sigleton.

Necu da pricam da je Singleton los, i ja ga izbegavam ali nemoj ga porediti sa DI.

Opravdana primena je kada zelim globalni pristup objektu, i zelim da osiguran da ce samo jedna isntanca biti kreirana.

U PHP jeziku nema problema sa Singletonom, kao sto je to slucaj u konkuretnim sistemima sa više niti gde može doći do problema kada više pozivaju u isto vreme Singleton, pa se bespotrebno kreira više objekata. Za ove slučajeve postoje drugi paterni koji se u ovim slučajevima koriste.

Koji je dobar razlog da bi izbegavali Singleton ?

• Globalne promenjive su loše
• Ne poštuje SRP princip

Koji je razlog izbegavanja statičkih ?

• Otežan ili nemoguć TDD

Jel imate nešto da dodate ali konkretno protiv SIngletona i statičkih ?

Webarto ovo sa DI je bilo potpuno nekonstruktivno, ako možeš navedi neki konstruktivan i valjan razlog osim ovih koje sam ja naveo. Čak se u ovoj prezentaciji koju si linkovao navodi da treba koristii Buldere i Factory za kreiranje objekata umesto SIngletona, ne DI.

Hteo bih samo da dodam jednu cinjenicu.
Trenutno radim na app koja ima oko 1200 klasa. Svaka klasa se nalazi u posebnom fajlu. Bice ih jos puno posto je projekat u ranoj fazi razvoja. Ni na jednom mestu nemam singleton klase, ali imam oko 50tak "single" instanci klase. Dakle samo jedna sme da se instancira tokom requesta - upravo sto radi i singleton. Sve ovo lepo radi samo zbog DI-a. I nemam potrebe za pristup globalnom objektu nigde, zato sto objekat koji ima potrebe za tako necim, dobija taj "globalni" objekat injectovan kroz DI mehanizam.

//EDIT
I nijednu rec static takodje nemamo u kodu.

Koji IoC/DI biblioteku koristiš ?

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

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

_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.

@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.

@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.

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.

@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.

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.