» »

PHP in objektno programiranje

PHP in objektno programiranje

«
1
2

kivi113 ::

živjo

Pred časom sem prebral nekaj strani v neki fajn knjigi o javi, ki naj bi bil eden izmed najbolj objektno orientirano osnovanih programskih jezikov. Objektno programiranje naj bi bilo tudi v osnovi nekakšen drugačen način razmišljanja, kot pri klasičnem programiranju s funkcijami in procedurami. Sam sem pred nekaj meseci začel ponovno programirati v PHP, vendar objektnega programiranja ne obvladam. Vendar moram v prihodnosti narediti precej kompleksno aplikacijo, ki se bo delala in nadgrajevala verjetno še kako leto ali možno tudi dlje (dodajanje novih funkcionalnosti, delo z uporabniki, ..). Aplikacija bo brala iz mysql baze podatkov. Shranjevalo se bo več matematičnih podatkov, faktorjev, deležev in podobno, ki jih bo php (oz v dolocenih primerih tudi mysql) racunal. V bazi bo tudi več tabel. Od tabele uporabnikov, do tabel različnih "naročil" in tabel za shranjevanje podatkov, časov vnosa in podobno.

Do zdaj sem sicer že napisal nekaj kode, vendar še v ne-objektni obliki. Ali se mi splača kodo prevesti v "objektno kodo". Čez 10 dni naj bi imel že kar nekaj za pokazat.

Kako se je pametno lotiti takih projektov? Imeli smo že kar nekaj pogovorov in brainstorminga, kaj bo aplikacija ponujala, zdaj pa moram narediti nek načrt, kako se bodo stvari povezovale med sabo. Kodo bi rad na pisal tako, da bo kar se da logična in preprosta za spreminjanje in dodajanje tudi v prihodnosti. Čez 10 dni bo moralo biti narejeno toliko, da bo vsaj iz marketinškega stališča na videz lepo.

Zelo bi bil vesel, če bi lahko kakšen programer ali arhitekt programske opreme malo povedal lastne izkušnje, kaj najboljše deluje pri takih zadevah.

black ice ::

Objektno usmerjeni način programiranja je veliko boljši od strukturiranega. Primer: uporaba stare kode je možna že s samo nekaj vključitvenimi datotekami in že lahko pišeš nove funkcionalnosti (govorim za C++ OOP, verjetno obstaja kakšna podobnost s PHP).

Brez zamere, vendar močno dvomim, da boš v 10 dnevih naredil kaj bistvenega, ker je sam koncept OOP precej drugačen od strukturiranega načina programiranja.

kivi113 ::

Oki. Torej, če programiram po starem, kako naj se lotim oblikovanja procedur (popravek: funkcij), da jih bo kasneje čim lažje konvertirati v objekte (popravek: metode)? Ker projekt je precej širok, in ga bom prej ali slej konvertiral. Verjetno je res bolj pametno, da zdaj bolj razmišljam o tem, kaj in kako bom pokazal, konverzije se pa lotim kasneje, ko bo več časa.

Zgodovina sprememb…

  • spremenil: kivi113 ()

black ice ::

Metode so več ali manj funkcije. Hitra razlaga: razred je skupek metod ali funkcij, objekt pa je primerek razreda.

Kako se lotiti oblikovanja funkcij? hm... Tako, da se čimprej naučiš OOP in začneš pisati kodo v tem načinu. :)

kivi113 ::

Super.

Sem našel nek video tutorial, ki mi je všeč. http://www.killerphp.com/tutorials/obje... , če koga še zanima.

Zaenkrat kake velike razlike med objektnim in proceduralnim načinom ne opazim. U bistvu objekt deluje podobno, kot nek array, s tem, da vsebuje še funkcije. Pomoje bom nadaljeval kar objektno.

omnimint ::

Jaz sem imel v začetku precej težav z OOP. Teorija je v redu, vendar je objektno programiranje bolj preklop v glavi. Meni je pomagalo, ko sem začel razmišljati v smeri, kako preko OP ponovno uporabiti kodo. Drugi 'aksiom' bi bil, da se ista koda ne sme večkrat ponavljati (OK, to velja na splošno pri programiranju), razen če nimaš kakšnega zelooo dobrega razloga, npr. ugotoviš da ti kopija kode bistveno pohitri delovanje. Skratka, začneš z razredom, ki je splošen (vsebuje večkrat uporabljene lastnosti in metode), nadaljuješ z dedovanjem v vedno bolj specifične. Izkaže se, da tako strukturiranje lahko odraža tudi fizični svet, naravo, npr.: Živo bitje > žival > vretenčar > primat, vendar so to bolj neki šolski primeri, večinoma se ukvarjamo z bolj abstraktnimi zadevami.
Vendar POZOR! Iz lastnih izkušenj ti lahko povem, da je vrnitev na proceduralno programiranje (kar se tiče obsežnejših projektov) zelo težko.:)

kivi113 ::

Točno to je problem. Pri zadnjem projektu sem določeno kodo ponavljal in podobno. In ko se je pojavil čas za updatanje in popravke, je bilo treba na 100 koncih nekaj popravljat. Pri objektnem programiranju pa, kolikor sem opazil, že s samim definiranjem razredov naredimo precej robustno strukturo objektov in s tem programa samega.

Pomoje pri meni ne bo toliko težav s preklopom v glavi, ker sem nekaj malega tudi sicer že programiral v OO Visual Basicu, pa tudi sam CSS in še marsikaj drugega je objekten oz. spominja na objekte.

Kako deluje tole dedovanje? Če sem prav razumel, najprej ustvarimo class živo bitje, ki ima nekaj lastnosti. Potem naredimo class žival, ki ima malček več lastnosti. In v samem classu določimo, da class žival pripada classu živa bitja oz deduje lastnosti (spremenljivke / metode) classa živa bitja. Končni rezultat je, da ima class žival vse lastnosti classa živa bitja + specifične lastnosti clasa živali (in podobno naprej pri vretenčarjih in primatih).

Vsekakor pa verjamem, da se kmalu ne bom več vračal na proceduralno programiranje, ker z večanjem projekta proceduralno programiranje povzroča vedno več sivih las, ko je treba kaj updatati ali popraviti. ;)

black ice ::

Pravilno si razumel.

MrBrdo ::

kivi113 če hočeš mal bolj kvalitetno narest, vzami kakšen PHP framework. Razlogov je več, nebi vsega našteval če te posebej ne zanima, ampak npr. če ne drugega ti postavi neke smernice, in vsak ki bo te smernice poznal mu bo tvoja aplikacija hitreje razumljiva in lažja za spreminjat. Je pa res da boš moral potem vložit še nekaj časa v učenje frameworka. Nekaj PHP frameworkov je: CakePHP, CodeIgniter, Zend, Symfony...

Pa še priporočam v branje Don't repeat yourself @ Wikipedia
MrBrdo

kivi113 ::

Hvala MrBrdo. Morda je to napačno, vendar zaenkrat še vseeno bolj prisegam na lastno kodo. Vsaj za začetek moram osvojiti sintakso in sistem delovanja objektnega programiranja. Bo verjetno vseeno hitreje, če sam naredim nekaj objektov in se igram z njimi, kot da spoznavam framework specifike. Pred leti sem sicer nekaj gledal CakePHP, samo mi je bilo takrat preveč zakomplicirano, ker potrebe niso bile tako velike.

Za začetek sem se malo poigral, in naredil class user. V ta klas zelim dati razlicne metode, ki bodo vracale različne podatke, npr ime, priimek, starost in ostale relavantne podatke.

class user {
	
	public $id=4;

	//tu bi rad določil default vrednost. Ker pri klicu funkcije ime " $id = '$this->$id' " ne prime. Pravzaprav
       //ne prime nobena spremenljivka, ki jo dam v funkcijo kot default vrednost. Ali se to pač ne da? (to je verjetno bolj php vprašanje).
         
         // tole spodaj mi javi fatal. rad bi poklical funkcijo, ki je del trenutnega razreda. mogoče je težava v sintaksi
	//spodnje javi fatal error
	//public $ime = $this->ime(4);

	
	function ime($id = '$this->$id'){
	$query=mysql_query("SELECT first_name FROM uporabniki WHERE user_id='$id'");
	$data=mysql_fetch_row($query);
	return $data[0];
	}
	
	function priimek($id = '4'){
	$query=mysql_query("SELECT last_name FROM uporabniki WHERE user_id='$id'");
	$data=mysql_fetch_row($query);
	return $data[0];
	}

} 


Zgornje sem shranil v datoteko, imenovano "class_lib.php", spodaj je testna koda, s katero je poskrbljeno, da se ime osebe 3 in priimek osebe 4 dodeli spremenljivkama z imenom $title1 in $content1.

$random_user = new user;
$title1 = $random_user->ime(3); 
$content1 = $random_user->priimek(4);


Taka koda deluje brez težav, kadar kličem npr. z $random_user->ime(3);, ne uspe mi pa funkciji znotraj classa vstaviti default vrednost, ki bi jo prav tako kot spremenljivko dodal v class (definiral bi jo na zacetku classa z public $var = "primer";)

Hvala za pomoč in dobre napotke.

Aja, imate mogoče še kakšen dober predlog, kako imenovati spremenljivke. Ker pri meni je možnost, da bom včasih pisal username, včasih user_name, spet tretjič bom napisal ime, ... pa bi blo dobro, da se držim enega reda. Predlogi?

MrBrdo ::

Boljše je da namesto "funkciji znotraj classa" rečeš metoda, saj se tako imenuje.
Default parameter ne more bit dinamična vrednost. Lahko ga nastaviš na '' in potem narediš if stavek in ga prepišeš z $this->id (namreč, ne $this->$id, to ni vredu).

Zapriseganje na lastno kodo te ne bo daleč pripeljalo ker: 1) boš porabil full časa da boš stvari naredil 2) kot je evidentno že iz kode ki si jo prilimal ne boš niti približno tako dobro naredil ;) 3) tvoje kode ne bo noben testiral za varnostne težave 4) da bo nekdo lahko delal na projektu ki bazira na tvoji kodi, bo moral najprej vse preštudirat, dokumentacije pa verjetno nimaš. Trenutna praksa kolikor je meni znano je da se že napisani frameworki zelo preferirajo napram nekim home-made variantam.
Mogoče zdaj ne vidiš prednosti frameworkov, lahko ti pa povem iz lastnih izkušenj da ti bo še zelo žal, ko jih boš začel uporabljat in boš spoznal, koliko časa si stran vrgel, kako si vse bolj slabo naredil, in najbolj pomembno, ko ti bo glava eksplodirala ko boš moral popravljat kakšen star projekt.

V tvoji kodi je en kup težav in nepravilnosti, zato bi bilo boljše uporabljat framework, še posebej če si "novinec".

Za začetek podajaš id default vrednost kot string, kar nima nekega smisla, saj naj bi bila vrednost število. Veliko resnejši pa je problem ker vhodnih podatkov (v tem primeru id) ne sanitiziraš kar pomeni da je tvoja koda idealen primer za SQL injection @ Wikipedia
DRY principa tudi nisi osvojil, ker se ponavljaš (imaš dve funkcije ki sta praktično skoraj enake). Ker ne uporabljaš ORM je tvoja koda tudi neportabilna na druge podatkovne baze. Uporabljaš tudi slovensko ime za tabelo, ime fieldov pa je angleško (user_id). Verjetno sem še marsikaj spregledal. V glavnem nikoli, oz. zelo težko boš naredil vsaj približno tako dobro, kot bi ti omogočal kakšen od naštetih frameworkov. Z uporabo dobrega frameworka bi se izognil prav vsem tem težavam/napakam. Tako da ti pisanje lastne kode še enkrat odsvetujem.

Glede imena spremenljivk, mislim da je v PHPju convention underscore case (torej my_variable_name) tako za imenovanje spremenljivk kot tudi funkcij in metod. Načeloma imaš lahko imena spremenljivk v slovenščini, je pa bolj običajno imeti vse v angleščini. Najbolj pomembno je da se tega potem držiš, torej ne imet pol spremenljivk v slovenščini pol pa v angleščini, ker potem je to vse skupaj ena zmešnjava. Angleščina je boljša tudi zato, ker če uporabljaš 3rd party knjižnice imajo skoraj vedno imena funkcij v angleščini, tako da je konsistenca boljša če tudi sam uporabljaš angleščino. Prav tako šumnikov ne moreš uporabljat za imena spremenljivk in funkcij. Lahko pa komentarje komot pišeš v slovenščini, če veš da kode ne bo gledal nihče ki ne zna slovensko.
V primeru username bi jaz uporabil username, ker se mi v tem primeru ne zdi potrebno ločevati besed, saj je username neka standardna fraza, ki se jo lahko piše skupaj.
MrBrdo

Zgodovina sprememb…

  • spremenilo: MrBrdo ()

MrBrdo ::

Pa če imaš željo pisati teste se to ne dela tako kot si ti naredil. Več info. o tem kako se pravilno piše teste imaš v dokumentaciji poljubnega frameworka (npr. http://codeigniter.com/user_guide/libra..., http://symfony.com/doc/current/book/tes..., http://bakery.cakephp.org/articles/mari....
MrBrdo

kivi113 ::

Hvala za analizo. Sam sem želel class oblikovati tako, da bi lahko spremenljivki v "main" programu dolocil vrednost z

$facebook_id je id uporabnika, ki trenutno brska po appu.

$x = new user;
$id = $x->idFromFB($facebook_id);
$ime = $x->ime($id);
$priimek = $x->priimek($id);
$token = $x->token($id);

in tako dalje. Je tako početje sploh smiselno, oz. kako se dela pravilno?

Proti SQL Injectionu bi, če bi dobil od nekje id, uporabil $id = mysql_real_escape_string($_REQUEST['id']); Pomena besede sanitizirati še ne razumem - sem pa že zasledil ta ukaz.

Hmm, se pravi je čas, da se naučim nekega frameworka.

Zgodovina sprememb…

  • spremenil: kivi113 ()

Mesar ::

NEIN NEIN NEIN! Boš hitr ugotovil, da je večina FW za PHP polizdelkov, ki dobesedno kraddejo čas! Class je za silo ok, mysql injection lahko tak preveriš ja čeprav imaš eš potlej kup trikov kot je double urldecode itd... pa še večji problem pa je XSS injection tako da moreš pazit kaj ti uporabnik šopa noter in kaj daš dalje.

NAjprej se drugače kliče običajno konstruktor pa metode se smisleno poimenujejo like... getPriimek.
Your turn to burn!

Ziga Dolhar ::

Objektnega programiranja (in razmišljanja) se IMHO najbolje naučiš tako, da vzameš v roke kako O'Reillyevo knjigo o UML :).
https://dolhar.si/

urosz ::

Saj je 1001 razlogov zakaj je objektno programiranje vredu, ampak vseeno ni toliko tega objektnega programiranja v php kot morda v nekaterih drugih jezikih. V Javi, C# recimo je čisto vsaka zadeva v bistvu razred ;)

Za OOP koncept naštudirat priporočam Javo/C# oz. ASP.NET, če si spletni programer.

MrBrdo ::

Mesar: V PHP imaš pač te možnosti. Če primerjaš njegovo kodo s tistimi frameworki je to kot dan proti noči. Če človek ne pozna zadev (ORM, MVC, SQL injection, XSS), potem to kar bo sam naredil ne bo niti polizdelek. Se pa strinjam da bi te PHP frameworki lahko bili boljši, ampak tudi sam jezik bi lahko bil, pa ni... Takšno je pač stanje.
getPriimek je pa smiselno poimenovanje za kakšno Javo. V smislu ORMja bi bilo boljše clovek->priimek ali clovek->priimek().

kivi113: Ja tista funkcija bo vredu za sanatization. To kar Mesar pravi da je večji problem XSS "injection" se ne strinjam, SQL injection je veliko hujši problem kot XSS. XSS lahko naredi samo škodo uporabnikom (in tisto na kar imajo uporabniki vpliv), SQL injection pa ti lahko povzroči da boš izgubil vse podatke. Seveda se moraš pa ognit obema. Tisti primer ki si ga podal imaš spet code duplication ($id podajaš ves čas kot argument, namesto da bi naredil instanco razreda ki ima id za atribut).
Glede frameworkov pa očitno obstajajo različna mnenja (Mesar...) ampak jaz ti svetujem da enega uporabiš (po lastni izbiri), ker če ga ne boš, ne boš niti zvedel za take stvari kot so SQL injection, XSS... In če ne boš vedel za stvari pomeni da boš imel luknjasto in zanič spisano aplikacijo. Če pa slučajno ne boš upošteval nasveta potem si pa vsaj poglej MVC (manj pogosto se reče MTV) in ORM (google it). Sicer meni osebno PHP kot jezik pač ni, ampak ima določene prednosti, če ne drugega opcije gostovanja in razširjenost.
MrBrdo

MrBrdo ::

Pa urosz ima sicer dober point, PHP ni ravno idealen jezik za učenje OOP (ker ni bil v osnovi tako zasnovan + na netu imas veliko bullshita). Sam če nimaš časa oz. moraš nekaj spacat prav v PHP potem pač daj. Tudi v PHP se da lepo programirat, sam je treba malo zadeve poznat, zato je framework fajn ker te prisili delat stvari na nek način, ki je načeloma ok.
Sicer pa ni nujno lih Java/C#, tudi Python, Ruby sta oba vredu za ucenje OOP (ceprav vsaj Ruby ima nekaj svojih fint). Kar nebi priporočal je npr. Javascript ker ima ne preveč pogost objektni model.
MrBrdo

Mesar ::

V smislu ORMja bi bilo boljše clovek->priimek ali clovek->priimek().


Aja? Na clovek->priimek lahko samo drkaš, ker je to Private spremenljivka... clovek->priimek() pa se uporablja za kaj? Nastavljanje vrednosti ali vračanje vrednosti? Ali pa kr oboje? Sej lahko narediš oboje v eni funkciji... pol še mamo polizdelke.

Za OOP ti je JAVA TOP S#IT!
Your turn to burn!

Zgodovina sprememb…

  • spremenil: Mesar ()

MrBrdo ::

Mesar: Konkretno clovek->priimek() je primer kako je to narejeno v Railsih. Tvojega žaljenja tukaj pa ne mislim poslušat niti prenašat. Če ti misliš da je Java top shit potem uporabljaj Javo in se ne vtikaj v PHP ker PHP ni Java. In Java conventioni veljajo samo v Javi ne pa v OOP na splošno, če to misliš se pač motiš. V language flamewar se pa ne mislim spuščat, naj vsak uporablja tisto kar hoče.
MrBrdo

Zgodovina sprememb…

  • spremenilo: MrBrdo ()

kivi113 ::

Prvič, ko sem delal s CakePHP, nisem prišel prav daleč. Je pa res, da sem takrat delal to bolj iz firbca, zdaj gre pa za bolj resno aplikacijo. Zdaj imam na izbiro CodeIgniter, Zend, Cake in symfony.

Ker gre za facebook aplikacijo, ki naj bi imela tudi kar nekaj javascript/jquery/ajax kode, in ker sem imel s prejšno aplikacijo zelo veliko težav s samim updatanjem, sem nekako zašel v slepo ulico.Skrbi me predvsem konsistentnost podatkov. Torej, da bo tisto, kar bo računal php, enako računal tudi javascript. Pa da se bo enaka funkcija uporabila tako v javascriptu kot v phpju.

Bo treba zavihat rokave, obenem pa razložiti, da je 10 dnevni rok ekstremno optimističen datum v trenutni situaciji.
Če v 10 dneh naredim nekaj na četrt, bo treba popravljati, in bom kasneje zgubljal živce.

Aja, na strani bo tudi nekaj gumbov, ki bi po možnosti lahko delali preko ajaxa, da ni treba strani refreshat. Predvidevam, da imajo frameworki tudi kakšne pomočnike za ajax...

MrBrdo ::

Če boš imel zelo Ajax-heavy site, sploh pa če Javascript že dobro poznaš, potem imaš tudi opcijo da sploh ne uporabiš PHP ampak postaviš stvar na node.js (strežnik ki laufa javascript). Potem ni problem imet enake kode, ker jo enostavno skopiraš :) Samo če ne pričakuješ res ogromno obiska potem lahko komot imaš logiko samo v PHP in jo kličeš preko Ajaxa, da ti ni treba stvari prepisovat. Če pa imaš večino logike na client-side (v brskalniku) pa je zanimiv tudi Backbone.js http://documentcloud.github.com/backbon... Ampak kot sem že omenil se mi Javascript ne zdi najbolj primeren jezik za učenje OOP, ker ima malo hecen objektni model (ni napačen, samo drugačen pač od večine ostalih).

Čisto mimogrede kot zanimivost, v Rubyju lahko celo laufaš Javascript kodo preko V8 pogona, tako da tam bi šlo tudi na ta način, ne vem pa da bi obstajalo za PHP kaj takega.
Glede Ajax helperjev, nekateri imajo. Od teh sem jaz uporabljal samo CakePHP ampak se ne spomnim da bi kaj posebnega imel. Sicer pa v resnici jih tako ali tako ne rabiš, dovolj je da imaš kakšen jQuery, ker Ajax ni neka znanost.
Sicer pa na hitro glede teh frameworkov, kolikor jaz poznam:
CakePHP: Več ali manj klon Railsov.
CodeIgniter: Precej modularen in minimalističen (v dobrem smislu).
Symfony: Veliko se nastavlja stvari preko XML datotek.
Zend: Bolj corporate zadeva.
To je bil vsaj moj vtis ko sem si zadeve na hitro pogledal, izkušnje pa imam samo z CakePHPjem. Osebno sem se na koncu odločal med Cake in CodeIgniterjem.
MrBrdo

Looooooka ::

PHP in Javascript za ucenje OOP?...I think not.
To je tko kot, da bi te ena izmed ta grdih Pepelkinih sestricen ucila skrivnosti Pepelkine lepote.
Mogoce bos dobil cevelj...ampak slej kot prej bos ob palec ali peto. In do takrat, ko bos prisepal do dobre vile(Java...c#...) bos ze tako star in grd, da ti bo tudi ona znala pomagati samo se z vreco, ki ti jo bo dala okol glave in jo drzala dokler ne bos nehal dihati.Ko bo koncala bo rekla "tok hudga je dal ze cez, da sem se pretvarjala, da sem dobra vila"....zdej grem pa resit naslednjega trpecega pacienta.
The end.
V glavnem...skip this book.O'reilly c# ali java.
Ful boljsa pravljica. Mogoce ma not tud kaksne vilinke s smesno velkimi joskami.

MrBrdo ::

Ja sam če se človeku mudi in hoče na PHP, potem naj ane... Sej PHP je objektno orientiran od ne vem kere verzije, pa če smo pošteni podpira OOP čist vredu, problem je sam v tem kaj povprečni PHP programer uporablja (nekje na stopnji PHP verzije 3).
Ni mi pa jasno zakaj vsi omenjate samo Javo (in C# ki je kopija), kot da je to edini proper OOP jezik... Je pa O'Reilly cool :) Če ima človek čas potem itak, čene bo pa tudi s PHP za silo prišel skozi.
MrBrdo

Looooooka ::

Pri 4 so zacel...pr 5 so bli ponosni ampak so jih vsen nadiral, da se ne drzijo vseh principov :P
Sj men je vseen.Zame je bil PHP itak pred c#-jem :)

kivi113 ::

Gre za aplikacijo, ki bo tekla na PHP strežniku. Osnovni namen ni učenje objektno orientiranega programiranja na splošno. O tem že imam določene predstave, ker nekaj malega sem že delal z "objekti". Edini programski jezik, s katerim sem kaj zaslužil, je bil pač php, in ker je obetajoča se aplikacija precej obsežna in zahteva tako security, kot modularnost, preprostost dodajanja in spreminjanja modulov, rabi podpirat več jezikov, uporablja javascript, ... torej precej heavy zadeva, in pri zadnji aplikaciji sem imel dosti težav.

Sem pa začel programirati za denar pred desetimi leti, ko je bil v igri še PHP4, potem pa sem programiral bolj preproste aplikacije v proceduralnem načinu, in nekaj obsežnejših. Težava pri obsežnejših je bila ravno moja koda, ker je bila nepregledna in raztresena,tako da čez nekaj mesecel že nisem razumel za sabo. Čeprav sem sčasoma dobil določeno rutino, ampak vseeno to ni to.

Ker moja produktivnost ni bila na želenem nivoju, sem neko rešitev videl v objektnem načinu programiranja.

Poleg PHP sem nekaj programiral v Visual Basicu za faks ter pisal skripte v Warcraft 3 map editorju. :) Nikoli nisem programiral v kakem podjetju na način, da bi sodeloval še z drugim programerjem, saj sem ponavadi delal v kolektivih, kjer sem zadostoval.


Torej, če bi jaz kljub vsemu rad dostopal do neke vrednosti, ki jo objekt pridobi iz baze podatkov, z ukazom $var = $user->ime($id) ,
$priimek = $user->priimek($id) in podobno, kako rabim drugače potem oblikovati class (razred?) ? Ker vseeno so bili to moji prvi objekti, ročno napisani v PHPju, tako da nekaj rezerve imam gotovo še. Glede določanja default vrednosti spremenljivke pri metodah, če sem prav to razmislil, je pa treba okoli riti v varžat, in v sami metodi preveriti, če je bila določena vhodna spremenljivka, in če ni bila, pač uporabiti neko drugo, zapisano v metodi? To bi znalo delovat?

Še dodatek: naložil sem se codeigniter, in berem dokumentacijo. Plonk listek zgleda kul.

Zgodovina sprememb…

  • spremenil: kivi113 ()

kivi113 ::

V objekt user sem sicer dodal tudi metodo

	function userdataarray($id){
		$query=mysql_query("SELECT * FROM uporabniki WHERE user_id='$id'");
		$data=mysql_fetch_assoc($query);
		return $data;
	}


Ta metoda pa pač pobere vse podatke iz tabele in vrne array, ki ima indekse imenovane po imenu tabele. Do tega pol dostopam preko

$uporabnik = new user;
$uporabnik_id = 1;
$uporabnik_array = $uporabnik->userdataarray($uporabnik_id);
foreach ($uporabnik_array as $key => $value)
{
	$main_content .=  $key . " " . "value: " . $value . "<br>";
}


Tole recimo izpiše vse podatke o uporabniku. Do posameznih podatkov lahko dostopam direktno, npr. preko $uporabnik_array['first_name'];
Sam naziv spremenljivke sicer lahko skrajsam, recimo v $arr, in je potem še lažje za pisati kodo.

Intuitivno se mi zdi to dober nacin dostopanja. Tudi to kodo bi kasneje sicer prenesel v svoj objekt, ki skrbi za prikaz. Namrec naredil sem se razred display, ki ima podobne funkcije, za razliko od razreda user, ki vrne "raw data", vrne podatke zavite v < div > tage. No ja, mogoče kompliciram in so vse te stvari bolje narejene v frameworku.

Zgodovina sprememb…

  • spremenil: kivi113 ()

MrBrdo ::

kivi113 je izjavil:

Intuitivno se mi zdi to dober nacin dostopanja. Tudi to kodo bi kasneje sicer prenesel v svoj objekt, ki skrbi za prikaz. Namrec naredil sem se razred display, ki ima podobne funkcije, za razliko od razreda user, ki vrne "raw data", vrne podatke zavite v < div > tage.

Ja to je nekako tako kot naj bi se delalo.

kivi113 je izjavil:

te stvari bolje narejene v frameworku.

So ja :)
Če v tem trenutku nimaš časa, da bi se naučil kakšen framework (ma vzami si čas vsaj enkrat pozneje), ti bi priporočal da potem vsaj uporabiš samo ORM knjižnico ( http://stackoverflow.com/questions/1086... ) in se poskusiš čimbolj držati smernic Model%E2%80%93view%E2%80%93controller @ Wikipedia
Če boš to dvoje vsaj približno uspešno uporabljal bo že kar vredu. Morda si še poglej kakšen templating language za PHP, npr. Smarty je najbolj znan. To so samo knjižnice tako da si še vedno lahko po svoje organiziraš vse skupaj in ti bo mogoče tako lažje na hitro neki narest, s temi dvemi pokriješ Model in View, ostane ti potem še logika ki ni poslovna (ni direktno vezana na podatke iz SQL - to spada v Model), v frameworkih je določeno kako se to dela, ti pa lahko za zdaj po svoje narediš.
MrBrdo

technolog ::

tvoje kode ne bo noben testiral za varnostne težave


Security thru obscurity. Lahko bi rekli, da je lasten framework bolj varen, kot nekaj, kar je vsem na očeh. Sploh sedaj po tisti novici o VUPEN. Ni garancije, da je javna koda varna, je pa zato lastna vsaj skrita.

2. Ne podcenjevat lastnih frameworkov. Moj je rezultat 5 letnega dopolnjevanja, tehta celotnih 70Kb (10kb za7zipan) ima pa vse, kar rabim. Hello world sample se naloži v 0.7ms (apache bench). Implementira MVC in ima po novem zahtevo PHP 5.4.

Nočem, da mu gradnjo lastnega FW odsvetujete, tudi če ima kake zgrešene ideje, se bo že na napakah naučil.

Zgodovina sprememb…

MrBrdo ::

Security thru obscurity.

Seriously? A novic na slo-techu nič ne bereš?

Jaz gradnjo lastnega frameworka načeloma dopuščam, ampak samo za nekoga, ki res ve kaj dela, in ki ima že izkušnje z ostalimi frameworki (torej pozna razne prakse na tem področju). Ne pa da delaš nekaj na pamet brez zadostnega znanja.
Še vedno pa osebno tega ne bi počel skoraj v nobenem primeru, ker ne vidim niti potrebe niti zadostnih prednosti. Samo v primeru da bi rabil nekaj res custom.
MrBrdo

Zgodovina sprememb…

  • spremenilo: MrBrdo ()

Mesar ::

MrBrdo je izjavil:

Security thru obscurity.

Seriously? A novic na slo-techu nič ne bereš?

Jaz gradnjo lastnega frameworka načeloma dopuščam, ampak samo za nekoga, ki res ve kaj dela, in ki ima že izkušnje z ostalimi frameworki (torej pozna razne prakse na tem področju). Ne pa da delaš nekaj na pamet brez zadostnega znanja.
Še vedno pa osebno tega ne bi počel skoraj v nobenem primeru, ker ne vidim niti potrebe niti zadostnih prednosti. Samo v primeru da bi rabil nekaj res custom.


Razen prednosti, da ni vezan na določene stvari, ki so fiksne in jih ne moreš spremenit. Hitrost pa je v večini tudi obupna (v primerjavi s custom rešitvijo), ko se greš malo večje projekte.
Your turn to burn!

technolog ::

Mislim, da pri znanih projektih ni tolk problem hitrost - čeprav je.

Večji problem je bloat (po 30 mega RAMa na pageload), kar se ti hitro nabere, če imaš par aktivnih povezav in ti zraste čez glavo, še posebej pri VPS. Moj FW ma 0.8 MB (odšteta osnova: prazen index.php).

Mesar ::

0,8MB kode torej? Mene zanima koliko pomnilnika ta koda požre ko se izvaja...
Your turn to burn!

technolog ::

ne. 0.8 MB rama na pageload, s tem da sem odštel porabo rama praznega index.php skripta (in s tem vse PHP razširitve in jedro PHP).

Mesar ::

Ja fino, jaz imam 0.5768MB, prva stran, mysql in vse kar paše polek, s tem da se mi includa samo potreben dela mojega FW, tako kot na vseh mojih izdelkih.

Pa Če imaš 30MB na pageload na stran ne veš kaj delaš...
Your turn to burn!

Zgodovina sprememb…

  • spremenil: Mesar ()

MrBrdo ::

Mesar je izjavil:

Razen prednosti, da ni vezan na določene stvari, ki so fiksne in jih ne moreš spremenit. Hitrost pa je v večini tudi obupna (v primerjavi s custom rešitvijo), ko se greš malo večje projekte.

Ja se strinjam da je to prednost, je pa tudi slabost (če se projektu pridružijo/ga spreminjajo drugi programerji). Konec koncev če si zadovoljen s svojim FW in veš kaj delaš, potem imej tako. Največji problem je če delaš svoj FW pa ne poznaš zadev. Če poznaš potem je opensource vs. home-made vprašanje stvar osebnega mnenja in preferenc.

Hitrost... Vse kar je na PHPju je počasno (pa tudi Python, Ruby, četudi je malo hitreje kot PHP ni dosti razlike). Tako da o tem debatirat nima smisla. Zato poznamo caching in ostale prijeme. Prednost teh jezikov je hitrost razvoja ne pa hitrost delovanja.
Glede RAMa pri teh številkah ki jih navajata je tudi popolnoma brezveze karkoli govorit, ker so tako majhne da nima veze, če imaš 0.5 MB ali 5MB. Tudi če imaš 5MB in 100 povezav v istem trenutku je to 500MB, kar zmore še vsak malo boljši VPS, pa 100 povezav v danem trenutku je že v bistvu ogromno (če računaš da traja procesiranje par 10 milisekund). Mislim da se po defaultu spawna tam okoli 10 workerjev, tko da to res ni relevantno.
MrBrdo

Zgodovina sprememb…

  • spremenilo: MrBrdo ()

technolog ::

No, kak Zend FW ti brez problema nafila tud po 30 mega.

Pa če imaš kako aplikacijo, ki uporablja long polling in drži odprto povezavo je to problem.

MrBrdo ::

No za push server itak PHPja nima nekega smisla uporabljat, vsaj ne z naloženim celim frameworkom. Če maš pa veliko število takih userjev potem pa tudi tvojih 0.5 MB na povezavo ne pride v poštev.
Pa tudi na sploh 30 MB ni noben problem, ker če imaš toliko prometa da ti server več tega ne more shendlat, imaš veliko bolj preproste rešitve kot optimizirat nek custom made framework v nulo za memory footprint. Enostavno narediš caching ali postaviš reverse proxy ali load balancer in dokupiš hardware. V glavnem s temi zadevami se je skoraj nepotrebno obremenjevat. Bolj pomembno je da jaz naredim projekte hitro in da se lahko hitro prilagajam, da nimam polno lukenj, za tistega enega od X ki je tako uspešen da je potrebno do te mere optimizirat pa si vzamem potem extra čas. Zdaj ker jaz uporabim že narejeno rešitev že tukaj prišparam, potem imam še plugine in razne že napisane stvari ki jih lahko uporabim (nekatere od teh pošteno stestirane, če katera ni pa lahko sam napišem teste). Če mi stvar uspe do te mere da je potrebno več delat na projektu, lahko najamem ljudi ki že poznajo to kar jaz uporabljam, lahko začnejo delat praktično takoj, če hočem lahko vpeljem kolega, ki se lahko stvari nauči iz dokumentacije... Proti vsem tem performance ni toliko pomemben, ker pri veliki večini projektov razlike sploh opazil ne boš, pri tistih kjer pa to lahko postane problem pa imaš vedno veliko možnosti kako stvar rešit (in to možnosti ki se skalirajo veliko boljše kot lahko ti skaliraš footprint svojega frameworka).
Ni dvoma da imajo home-made rešitve svoje prednosti, ampak zame osebno je več prednosti v uporabi narejene rešitve, v večini primerov. Zdaj mogoče imaš ti druge prioritete, drugačne izkušnje, drugačne projekte... Važno je samo da poznaš obe plati zgodbe.

Pa še nekaj je, ti bom dal primer iz Ruby on Rails ker ne vem ali se to dela tudi pri PHP frameworkih (ker PHPja več ne uporabljam, sem pa ga dolgo časa). Npr. jaz imam pri vseh svojih Rails projektih na strežniku skonfigurirano tako, da se mi zboota en worker, ki se potem forka n-krat in se vklopi copy-on-write. Kar to pomeni je da čeprav ima prvi worker recimo 40 MB footprinta, v resnici se teh 40 MB zelo redko ali nikoli ne spreminja, če pa se pa zelo omejeni deli. In zato je v pomnilniku (preko virtualnega pomnilnika) samo 1x, če pa se slučajno zgodi da bi en od workerjev rabil kaj od tega spreminjat se skopira samo 1 memory page (velikost odvisna od arhitekture & OSja), kjer je potrebna sprememba, vse ostalo pa se še vedno "deli" med workerji. Računaj da je večina od teh 40 MB kode in statičnih podatkov. Tako da mi je potem res vseeno, ali ima moj framework footprint 0.5 MB ali 100 MB, ker je to zame "fiksen strošek".
MrBrdo

Zgodovina sprememb…

  • spremenilo: MrBrdo ()

technolog ::

Če imaš long poling, ponavadi nimaš statičnega contenta, tako da cache tukaj ni rešitev. Lahko celo tako dinamičen, da ti niti cache na nivoju baze ne pomaga. Dodaten HW seveda je, ampak to je vedno.

Glede napak imaš prav - zato sem proti lastnim fw, ki so večji od recimo 1-3 K vrstic kode. Razlog? Več je težko vzdrževat v bug-free stanju.

Eno zelo očitno prednost pa le ima lasten FW. Če bo jutri odkrit kak critical bug v recimo Zendu, bo ranljivih tisoče aplikacij in to še dolgo dolgo (ker je veliko projektov takih, da sprogramiraš in pustiš pri miru). Če hočeš imeti vse relativno varno, moraš skrbet, da so stvari kolikor toliko na najnovejših verzijah, ker če ne te bo pohekal kak bot. To meni pomeni kar veliko.

Zdi se mi, da PHP še ne shara skupnega spomina med procesi (Copy on write), nisem pa ziher. Ostajam na PHP zgolj zaradi navade, pa tudi sintaksa Ruby-a je ogabna - seveda je PHPjeva še bolj, ampak sem pa vsaj navajen nanjo.

Sicer se načeloma z vsem strinjam. Bila je dobra debata, vsaka stran ima svoje prednosti, definitivno in ni moj razlog da bi kogarkoli prisilil v tak način dela.

Glede aplikacij, ki zahtevajo server push komaj čakam HTML5 sockets.

Zgodovina sprememb…

MrBrdo ::

Ja cache nisem mislil za long polling. Samo jaz če rabim "push server" (za kar se večinoma long polling uporablja), potem (samo za ta del) ne uporabim Ruby (ali PHP), ampak node.js ali APE server. Npr. v kombinaciji ali s podatkovno bazo ali pa z Redis strežnikom. Potem tukaj nimaš problema. Tudi če želiš nujno to delat v PHP lahko komot ta del razviješ ločeno brez frameworka in podatke deliš preko pod. baze ali key-value store. Performanci long pollinga preko Rubyja ali PHPja so precej slabi pri večjih obremenitvah zato se tako ali tako ne splača.
Btw HTML5 sockets je možno uporabljat že zdaj, saj ima veliko ljudi brskalnike ki to že podpirajo. Če uporabljaš nek library, ki ti zadevo abstrahira, v smislu da ima tudi fallback na long polling, potem si zmagal (seveda mora podpirat tudi strežnik). Zato imaš rešitve kot so APE server in Socket.IO, ki imajo to rešeno tako za strežnik kot za client, in zato je fino delat ta del projekta s temi rešitvami, in povezovat preko baze/key-value storea. Pa btw PHP websocketa ne bo mogel podpirat, vsaj ne na Apache, saj Apache vsaj zaenkrat ne podpira te funkcionalnosti - še en razlog zakaj za to ne bi uporabljal PHPja.

Glede bugov imaš seveda prav, je pa druga plat to da pri teh frameworkih o katerih govorimo ni tako enostavno poiskat strani ki uporabljajo ta in ta framework. Druga stvar pa je da ta tvoja prednost v bistvu spet temelji na security through obscurity. Velika verjetnost je, da imaš v svojem FW več bugov kot neka razširjena opensource rešitev. Vprašanje je zdaj samo če se bo kdo spravil to iskat (sem že videl ravno na tem forumu primer, ko so enemu SLO našli in potem exploitali na vseh pageih ki jih je on delal). Če imaš ornk stran se lahko hitro zgodi, da ti bo kdo kaj našel, tudi če imaš svojo rešitev. Če pa imaš manjše strani pa ta "prednost" res pride bolj do izraza.

Copy on write (CoW) sicer ni funkcija jezika/interpreterja ampak OS (Linux). Tako da uporabit se da sigurno tudi za PHP, vprašanje je samo če je njegov garbage collector dovolj CoW-friendly. Namreč garbage collectorji so pogosto narejeni tako da pišejo vsepovprek in potem ti CoW ne pomaga nič več, ker se hitro ustvarijo kopije za vse. Ta problem je tudi v Rubyju, vendar je rešen v Ruby Enterprise Edition za verzijo 1.8.x, medtem ko v 1.9 trenutno ni dobre rešitve, je pa že pripravljena za 2.0. S tem sem hotel povedat, da poraba RAMa ni nujno tako pomembna. Tudi če take rešitve ne moreš uporabit, je treba upoštevat da pri manjših straneh to ni pomembno, ker ni dovolj prometa, pri večjih pa si načeloma lahko privoščiš tudi skaliranje HW in raznorazne optimizacije (primer Twitter ki so določen del aplikacije prepisali v compiled jezik, da so pridobili na hitrosti). Point je v tem da ni velika verjetnost (razen če delaš kako prenovo neke strani) da boš imel veliko količino prometa, na to lahko samo upaš, zato so ostale prednosti/slabosti večjega pomena kot performance. Zame osebno je najbolj pomembna prednost hitrost razvoja.

Glede sintakse Ruby pač osebna preferenca. Meni tudi v štartu ni bila preveč všeč, sem se pa navadil. Še najbolj me motijo zaviti oklepaji za blocke, ker se mi ne zdi čisto konsistentno, drugače mi je zdaj kar OK. Ampak sej ni pomembno ker tu govorimo o PHP :)
MrBrdo

Zgodovina sprememb…

  • spremenilo: MrBrdo ()

technolog ::

spet temelji na security through obscurity.


Ne nunjno slabo. MS se zanaša na to, pa mu nič ne manjka.

Ampak mam tukaj še ta argument: FW sem napisal po svojih najboljših močeh (najbolj varnega kot zmorem). Tudi aplikacije pišem kolikor zmorem varne. Če v resnici pišem nevarno kodo, potem bo aplikacija zanič, ne glede na to, če bom zraven uporabil še zelo varen FW. Povzetek: Če si slab programer, ti še tako dober FW ne bo pomagal, da bo aplikacija varna. FW je samo del projekta - in projekt je tako varen, kot je varen njegov najšibkejši člen.

Copy on write (CoW) sicer ni funkcija jezika/interpreterja ampak OS (Linux). Tako da uporabit se da sigurno tudi za PHP, vprašanje je samo če je njegov garbage collector dovolj CoW-friendly


To sem mislil, ko sem napisal, da ne vem če "podpira".

Sintaksa ruby-a me spominja na Pascal in na njegove grozne do..begin...end bloke:). Za nakazovanje blokov mi je C-like sintaksa najlepša, pogojno tudi pythonova.

Seveda vem da tale moja trma ni trajnostna, PHP programerji so namreč manj plačani in spoštovani, saj se phpja drži nek čuden sloves (iz lastnih izkušenj vem). Primer RL - pokažem frendom eno mojo aplikacijo, na zunaj ni izdajala nobenih informacij (strežnik in FW skonfiguriran da skrije vse lang-dependet stvari) in je bilo vse super kul - ko sem pa povedal, da teče na PHP je bil pa kakor bi jih stuširal z mrzlo vodo in projekt kar naekrat ni bil več tok kul. ;((
PHP so zajebal začetniki, da je dobil sloves, da so v njem napisane samo nekakovostne aplikacije. Žal.

Zgodovina sprememb…

kivi113 ::

Živjo

Mogoče so malce krive tudi nekvalitetne knjige. Sam sem se naprimer učil programirati iz Wroxove knjige PHP 4 for begginners. Mi je uspelo po principu te knjige narediti neko basic internet trgovino za maturitetno nalogo. In tak način sem ohranil do sedaj. Tudi, če gledam primere na php.net, je koda napisana v "proceduralni obliki".

Sam sem namreč moral poštudirat sintakso objektov, zdaj pa sem dobil še malo filinga. Moj prvi objekt je bil narejen brez konstruktorja. Zdaj sem stvari že malček popedenal.

// class_lib.php 

class usr {

	public $id = 1;
	// iz appa klicem kot
	// $u = new usr;
	// $var = $u->data['first_name'];
	// oz.
	// $var = $u->ime();
	public $data = array();
	public $db_name = "users";
 
	
	 private $config = array(
    'appId' => '***',
    'secret' => '***',
  );
	
	function __construct($id = 1) {           
		
		if (!is_int($id))
		{
			$this->id = int (1);
		}
		
		$query = mysql_query("SELECT user_id FROM $this->db_name WHERE user_id='$id'");
		$num = mysql_num_rows($query);
		if ($num == 0)
		{
			$this->id = int (1);
		}
		
		else
		{
			$this->id = $id;
		}
		
		$query=mysql_query("SELECT * FROM $this->db_name WHERE user_id='" . $this->id . "'");
		$data=mysql_fetch_assoc($query);
		$this->data = $data;
        } 
	
	function ime(){
		return $this->data['first_name'];
	}
	
	function priimek(){
		return $this->data['last_name'];
	}
..
+ nekaj drugih metod
..
}


Tale vrstica vem, da zgleda moronska, na php.net je zgolj napisana alternativa z SELECT *, ki je verjetno še slabša.
$query = mysql_query("SELECT user_id FROM $this->db_name WHERE user_id='$id'");
$num = mysql_num_rows($query);


V konstrukt sem napisal kodo, ki v primeru, da user id ne obstaja, ali pa je objekt ni instanticiran z integerjem,
(npr $u = new usr("string");), objektu da default id 1.

Sicer pa sem se zadnje dni malce poigraval s temi objekti. Aplikacija je imela napisanih že nekaj funkcij od prej za prikaz
posameznih delov appa, pa sem zdaj vse to spravil v model display.

V osnovi mi modeli tipa display vračajo vrednosti preko echo ukaza, ostali modeli pa vračajo preko vrednosti, ki jo določim v metodi preko return.

Se mi zdi, da bom na dolgi rok s tako strukturo pridobil na preprostosti dodajanja novih funkcionalnosti, ter olajšal preprostost editanja. Upam, da moji classi niso več tak polom, kot prvi ;d

Mesar ::

Tale zgleda kr vredu, nič ni treba spreminjajt samo dodajaj, ker konstrukcija je dobesedno fenomenalna.

Pa manjkajo ti get, set in toString methode. Aja get celo imaš... set pa ne rabiš, enkrat se nastavi spremenljivka pol pa če hočeš kaj spremenit celi class dropnit pa na novo ježa jehat...
Your turn to burn!

Zgodovina sprememb…

  • spremenil: Mesar ()

technolog ::

Wroxove knjige so kar v redu.

Mesar ::

Niti ne, OOP za PHP imaš NAJBOLJŠE razližen na php.net, sej to logično a ne?
Your turn to burn!

Gandalfar ::

Ne ni logicno in tudi ni nujno.

Mesar ::

Zakaj ne? Torej ustvarjatelji PHPja ne znajo napisat dobre dokumentacije za to kar so ustvarli? KDo pa potem zna?
Your turn to burn!

technolog ::

Dokumentacija je namenjena dokumentiranju jezika in kot referenca kaj je bug (neprikačkovano delovanje) in kaj ne.

Ni pa nujno dober vir za učenje, predvsem za začetnika. Ali nasploh za učenje splošnih OOP principov. Pazi, napisal sem "ni nujno".

Gandalfar ::

Mesar je izjavil:

Zakaj ne? Torej ustvarjatelji PHPja ne znajo napisat dobre dokumentacije za to kar so ustvarli? KDo pa potem zna?


Ker napisat dobro dokumentacijo, ki te skozi korake vodi do spoznanja necesa je preklemano tezko. Zato se ljudje usedejo po par mesecev in dobro razmislijo, ko pisejo knjigo. PHP dokumentacija mi ni ravno biser, ki bi me naucil dobrih praks in me posvaril pred tem, da se ustrelim v koleno (obcasno jim sicer rata).

kivi113 ::

V kodi, ki sem jo pisal zgoraj, sem naredil 2 napaki, zato je treba v 24. in 31. vrstici zamenjati
 $this->id = int (1);
        


z
$this->id = 1;


php namreč ne pozna konverzije na tak način, kot sem to želel predstaviti. Zadeve pa nisem takoj opazil, ker sem vedno do sedaj še pravilno kreiral objekt z integerjem. Če bi se dalo, bi poedital zgornji post, pa se pač ne da.
«
1
2


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

[UWP] [C#]

Oddelek: Programiranje
423957 (1987) BivšiUser2
»

[C#] Entity Framework

Oddelek: Programiranje
6880 (711) frudi
»

Izšel PHP 5.5

Oddelek: Novice / Ostala programska oprema
114862 (3552) technolog
»

PHP povezava z Mysql

Oddelek: Izdelava spletišč
16842 (687) snooze77
»

[php, mysql] sortiranje izpisa iz baze

Oddelek: Izdelava spletišč
262556 (2075) Binji

Več podobnih tem