PHP in objektno programiranje

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.

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. :)

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.

Pravilno si razumel.

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?

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

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.

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.

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.

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.

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

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.

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.

kivi113 je 23. mar 2012 ob 04:03 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 23. mar 2012 ob 04:03 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š.

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.

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

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 je 23. mar 2012 ob 18:39 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.

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

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

Ž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

Wroxove knjige so kar v redu.

Ne ni logicno in tudi ni nujno.

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

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.