tupacko kérésére megnyitva.
Az objektumorientált programozás (angolul Object Oriented Programming, röviden OOP) egy programozási módszer. Olyan programnyelv, amely lehetővé teszi különböző bonyolult változók (objektumok) létrehozását és kezelését. Amikor a programozók már kinőtték a klasszikus programozás kereteit, ki kellett gondolni egy új módszert a megnövekedett információtömeg kezelésére. Ezek lettek az objektumok.
Akit bővebben érdekel: Wikipédia
Full Version: Objektumorientált programozás
Köszönöm a témát! Hamarosan jönnek a kérdések, csak megnézem az eddig kapott linkek alatt rejlő információt!
Azt hiszem, hogy az eslő OOPHP programom egy XML kezelő lesz, egyelőre arra gondoltam, hogy:
TUD:
olvasni
írni képernyőre
írni állományba
úgy részeket, mint teljes XML állományokat.
Jó ötletnek tartjátok ezen tanulni?
TUD:
olvasni
írni képernyőre
írni állományba
úgy részeket, mint teljes XML állományokat.
Jó ötletnek tartjátok ezen tanulni?
XML parser már van pár millió (phpClasses-on keress rá az XML kifejezésre 
), szvsz. keress másik feladatot magadnak...
Ini parser?
Betöltés - módosítgatás - mentés - kimenetre küldés - mentés előtt back-up készítés ilyenek...
És szvsz. mindenképp úgy csináld, hogy mind PHP 4 mind 5 alá megírod, hogy lásd az OOP különbségeket a két nyelv között. A teljesség igénye nélkül:
- final, static, abstract kulcsszavak
- láthatóság (public - protected - private)
- mágikus methodok
- interface-k
BlackY
), szvsz. keress másik feladatot magadnak...Ini parser?
Betöltés - módosítgatás - mentés - kimenetre küldés - mentés előtt back-up készítés ilyenek...
És szvsz. mindenképp úgy csináld, hogy mind PHP 4 mind 5 alá megírod, hogy lásd az OOP különbségeket a két nyelv között. A teljesség igénye nélkül:
- final, static, abstract kulcsszavak
- láthatóság (public - protected - private)
- mágikus methodok
- interface-k
BlackY
szerintem kezd a js-el
http://htmlinfo.polyhistor.hu/js13guide/obj.htm
jobb ezen túlesni
bár szvsz fölösleges mire megvagy kijön a prototype 2.0 a http://dean.edwards.name/weblog/2006/03/base/ ill. http://dean.edwards.name/weblog/2006/05/prototype-and-base/ alapú class mechanizmussal ami már egész pofás lesz, mondjuk js alapokat így is érdemes megkukkantani 
http://htmlinfo.polyhistor.hu/js13guide/obj.htm
jobb ezen túlesni
bár szvsz fölösleges mire megvagy kijön a prototype 2.0 a http://dean.edwards.name/weblog/2006/03/base/ ill. http://dean.edwards.name/weblog/2006/05/prototype-and-base/ alapú class mechanizmussal ami már egész pofás lesz, mondjuk js alapokat így is érdemes megkukkantani
BlackY:
nem számít, hogy van-e vagy sincs XML kezelő, a lényeg az, hogy gyakoroljam , próbáljam stb. Sajna csak PHP5öm van telepítva, szal arra írom ... úgyis el fog avulni a 4es (hamarabb mint az ötös).
Toxin:
az igazság az, hogy C++al kezdtem, JSel is készítettem már ezt azt, pl:
itt megtekinthetitek
de én a phpt akarom vágni
Most még egyelőre csak a file kezelő classal vagyok el ... abból akarom az egyéb kezelőket származtatni.
nem számít, hogy van-e vagy sincs XML kezelő, a lényeg az, hogy gyakoroljam , próbáljam stb. Sajna csak PHP5öm van telepítva, szal arra írom ... úgyis el fog avulni a 4es (hamarabb mint az ötös).
Toxin:
az igazság az, hogy C++al kezdtem, JSel is készítettem már ezt azt, pl:
itt megtekinthetitek
de én a phpt akarom vágni
Most még egyelőre csak a file kezelő classal vagyok el ... abból akarom az egyéb kezelőket származtatni.
Pedig a JS OOP lehetőségei baromi jók, érdemes azokat is jól átnézegetni
Lehet, hogy csak PHP 5-öd van telepítve, de egyelőre a 4-es ág lehetőségeivel is tisztában kell lenni, ha figyelembe veszed a PHP 5-ös host-ok elég alacsony arányát
BlackY
Lehet, hogy csak PHP 5-öd van telepítve, de egyelőre a 4-es ág lehetőségeivel is tisztában kell lenni, ha figyelembe veszed a PHP 5-ös host-ok elég alacsony arányát
BlackY
Egyébként nem hinném hogy olyan hamar elavulna a PHP 4, ugyanis a napokban jött ki a 4.4.3-as verzió. Illetve az is igaz, amit BlackY mond, a PHP 5-ös hostok száma elég kevés.
Még frissítgetik a 4-es ágat, már kopogtat az ajtón a hatos, de ez nem változtat azon a tényen, hogy a PHP 4 OOP lehetőségei harmatgyengék. De azt is tudni kell...
[off]
A száma nem kevés, egész pontosan 1 Ami lehet alacsony, átlagos, magas, satöbbi, de csak egy van belőle. Tudom-tudom, hülyeség ilyenen fennakadni, meg eleve öngyilkos akció belekötni egy modi postját , de akkoris...
[/off]
BlackY
[off]
A száma nem kevés, egész pontosan 1
Ami lehet alacsony, átlagos, magas, satöbbi, de csak egy van belőle. Tudom-tudom, hülyeség ilyenen fennakadni, meg eleve öngyilkos akció belekötni egy modi postját , de akkoris...[/off]
BlackY
Elképzelhető, hogy igazatok van, de egyszerre csak egyet akarok tanulni: OOPHP. El is készűlt az első állomány kezelő osztályom, szóval szeretném ha vélemnényt nyílvánítanátok felőle.
http://tupacko.uw.hu/dev/file.phps
http://tupacko.uw.hu/dev/file.phps
elsőnek kommentezés
kukk
http://pear.php.net/manual/hu/standards.sample.php
http://pear.php.net/manual/hu/standards.header.php
nézem tovább
ui: persze nem muszály követni , de ha autodoksi generáló cuccot használsz (phpdocumenor), fogsz, akkor de
kukk
http://pear.php.net/manual/hu/standards.sample.php
http://pear.php.net/manual/hu/standards.header.php
nézem tovább
ui: persze nem muszály követni , de ha autodoksi generáló cuccot használsz (phpdocumenor), fogsz, akkor de
QUOTE(tupacko @ 2006. Aug 5., 19:49)
BlackY:
nem számít, hogy van-e vagy sincs XML kezelő, a lényeg az, hogy gyakoroljam , próbáljam stb. Sajna csak PHP5öm van telepítva, szal arra írom ... úgyis el fog avulni a 4es (hamarabb mint az ötös).
Toxin:
az igazság az, hogy C++al kezdtem, JSel is készítettem már ezt azt, pl:
itt megtekinthetitek
de én a phpt akarom vágni
Most még egyelőre csak a file kezelő classal vagyok el ... abból akarom az egyéb kezelőket származtatni.
nem számít, hogy van-e vagy sincs XML kezelő, a lényeg az, hogy gyakoroljam , próbáljam stb. Sajna csak PHP5öm van telepítva, szal arra írom ... úgyis el fog avulni a 4es (hamarabb mint az ötös).
Toxin:
az igazság az, hogy C++al kezdtem, JSel is készítettem már ezt azt, pl:
itt megtekinthetitek
de én a phpt akarom vágni
Most még egyelőre csak a file kezelő classal vagyok el ... abból akarom az egyéb kezelőket származtatni.
A C++ meg a C OOP-ra optimalizált változata...
Na akkor beszélgessünk a kódról is picit ne csak a külalakról... Tudod Toxin, nem csak a külcsín
Szval.:
private $name;
private $mode;
private $handler;
Ha jól látom feltételezhetjük a PHP 5 környezetet
function file_handler
Csúnya, buta, felejtős.
__Construct() használata ajánlott. Néztem már órákon át kódot, hogy mi a tökért nem működött. Lecseréltem az osztály nevét...
[A rosszalló megjegyzések előtt: valamikor kora hajnalban volt!]
if ( $this->handler == false )
Én itt inkább a resource típusba tartozását ellenőrizném...
Első nekifutásra ennyi, amúgy
...
[Bár ha így benne vagy ebben az OOP és fájl-kezelés témában nézz rá a stream wrapper-ekre (itt mondjuk) )
BlackY
Szval.:
CODE
private $name;
private $mode;
private $handler;
Ha jól látom feltételezhetjük a PHP 5 környezetet
CODE
function file_handler
Csúnya, buta, felejtős.
__Construct() használata ajánlott. Néztem már órákon át kódot, hogy mi a tökért nem működött. Lecseréltem az osztály nevét...
[A rosszalló megjegyzések előtt: valamikor kora hajnalban volt!
]CODE
if ( $this->handler == false )
Én itt inkább a resource típusba tartozását ellenőrizném...
Első nekifutásra ennyi, amúgy
...[Bár ha így benne vagy ebben az OOP és fájl-kezelés témában nézz rá a stream wrapper-ekre (itt mondjuk)
)BlackY
sry, én js-t + prototype oop-t vettem fel mint inkább praktikus tudományt, nem a php5-ös oop-t, majd ha gyakorlatban is tudom használni 
Mindenkinek nagyon szépen köszönöm a megjegyzéseket! BlackY: nem tudom mi az a resource típus 
Amúgy, még nem vagyok úgy benne, mert tegnap előtt kezdtem el, tegnap is csak este foglalkoztam vele vagy 2 orát, sajnos nem volt több időm
Amúgy, még nem vagyok úgy benne, mert tegnap előtt kezdtem el, tegnap is csak este foglalkoztam vele vagy 2 orát, sajnos nem volt több időm
Változó-típusok a PHP-ben:
Bool, Integer, Float, String, Array, Object és a resource.
Nagyjából és egész pontosan erőforrásnak kéne fordítani, de ezt hagyjuk, részletkérdés
Ilyet nem lehet generálni, csak a megfelelő bővítmények/PHP mag csinálhat.
Resource típust baromi gyakran használtál már, max nem jöttél rá Néhány példa
fopen -> File resource
opendir -> directory resource
mysql_connect -> mysql connection resource
...
Ami ebből fontos:
A resource adattípus
Is_resource fgv.
Get_resource_type fgv.
]url=http://hu.php.net/manual/hu/resource.php]Resource-k listája a létrehozó- és használó függvényekkel együtt[/url]
BlackY
Bool, Integer, Float, String, Array, Object és a resource.
Nagyjából és egész pontosan erőforrásnak kéne fordítani, de ezt hagyjuk, részletkérdés
Ilyet nem lehet generálni, csak a megfelelő bővítmények/PHP mag csinálhat.
Resource típust baromi gyakran használtál már, max nem jöttél rá
Néhány példafopen -> File resource
opendir -> directory resource
mysql_connect -> mysql connection resource
...
Ami ebből fontos:
A resource adattípus
Is_resource fgv.
Get_resource_type fgv.
]url=http://hu.php.net/manual/hu/resource.php]Resource-k listája a létrehozó- és használó függvényekkel együtt[/url]
BlackY
Köszi, átnézem. Amúgy valóban használtam, csak én olyan néven ismertem, hogy handler ... köszi az infót!
justin: a hozzászólásod áthelyezve.
Vegulis a OO PHP ága teljesen megszakadt, mivel a web visszallat a hobbi szintre. Most Javat es C#ot tanulok. (Java suli, C# otthon).
Hy!
Az lenne a kérdésem, hogy van-e kulonbség abban, hogy pl. a kov. funkcióban $valtozó-t, vagy $this->változót használok?
Pl. itt a $tmp és a $num változókat nem-e kellene $this->tmp-s alakra cserélni. Egyébként mukodik a script, csak felmerult bennem ez a kérdés.
Az lenne a kérdésem, hogy van-e kulonbség abban, hogy pl. a kov. funkcióban $valtozó-t, vagy $this->változót használok?
CODE
class SQL {
function printDatabases()
{
$result=array();
$tmp=@mysql_query("show databases",$this->conn);
$this->SQLerror();
$num=@mysql_num_rows($tmp);
$this->SQLerror();
for($i=0;$i<$num;$i++)
{
$fetch=@mysql_fetch_row($tmp);
$this->SQLerror();
$result[$i]=$fetch[0];
}
return $result;
}
}
function printDatabases()
{
$result=array();
$tmp=@mysql_query("show databases",$this->conn);
$this->SQLerror();
$num=@mysql_num_rows($tmp);
$this->SQLerror();
for($i=0;$i<$num;$i++)
{
$fetch=@mysql_fetch_row($tmp);
$this->SQLerror();
$result[$i]=$fetch[0];
}
return $result;
}
}
Pl. itt a $tmp és a $num változókat nem-e kellene $this->tmp-s alakra cserélni. Egyébként mukodik a script, csak felmerult bennem ez a kérdés.
A $this-> formával mindig az adott objektum ($this) egy metódusára / tulajdonságára mutatunk.
Ha ezt a mondatot végiggondolod, akkor optimális esetben a kérdésed meg van válaszolva, ti. az ideiglenes változó (tmp) és a num (amely egy lokális változó) nem tulajdonsága az objektumnak. Hogy egy kicsit világosabb legyen: ha írsz egy queryObject osztályt, ami EGY lekérést reprezántál, ott már jogos lenne, hogy a num-ot "előlépteted" tulajdonsággá.
Amúgy egy kicsit általánosabb képlet, amit az egyetem magyaráznak, de vitatható: ha olyan adatot tárolsz, amit az adott objektumon belül több metódus is használ, akkor legyen tulajdonság (így $this-> forma). Ha azt akarod, hogy ez kívülről lekérdezhető legyen, akkor ugye az implementáció elrejtése miatt a változót protected-re (csak az adott osztályból és a gyermekosztályokból érhető el) vagy még inkább private-ra (csak az adott osztályból érhető el) állítod, és set/get függvényt írsz hozzá. (pl.: private $num; public function getNum($num) { } protected function setNum($num) { })
BlackY
Ha ezt a mondatot végiggondolod, akkor optimális esetben a kérdésed meg van válaszolva, ti. az ideiglenes változó (tmp) és a num (amely egy lokális változó) nem tulajdonsága az objektumnak. Hogy egy kicsit világosabb legyen: ha írsz egy queryObject osztályt, ami EGY lekérést reprezántál, ott már jogos lenne, hogy a num-ot "előlépteted" tulajdonsággá.
Amúgy egy kicsit általánosabb képlet, amit az egyetem magyaráznak, de vitatható: ha olyan adatot tárolsz, amit az adott objektumon belül több metódus is használ, akkor legyen tulajdonság (így $this-> forma). Ha azt akarod, hogy ez kívülről lekérdezhető legyen, akkor ugye az implementáció elrejtése miatt a változót protected-re (csak az adott osztályból és a gyermekosztályokból érhető el) vagy még inkább private-ra (csak az adott osztályból érhető el) állítod, és set/get függvényt írsz hozzá. (pl.: private $num; public function getNum($num) { } protected function setNum($num) { })
BlackY
Hozzáfűzném azt, hogyha az adott függvényben akarsz használni egy változót, ami egy tulajdonsága az osztálynak, ha az, legyen x, az x változó nem paramétere a függvénynek, vagy nem lokális változója, akkor nem szükséges a this előrész, mivel implicit módon az osztály jelenlegi példányának az x tulajdnoságát fogja használni.
CODE
<?php
error_reporting(E_ALL);
class Ize {
public $ize = 'foobar';
public function kiir() {
print $ize;
$ize .= 'foobar';
}
public function kiirthis() {
print $this->ize . PHP_EOL;
$this->ize .= 'foobar';
}
}
$i = new Ize();
$i->kiir();
$i->kiir();
print 'this-sel' . PHP_EOL;
$i->kiirthis();
$i->kiirthis();
?>
QUOTE
Notice: Undefined variable: ize in C:\Documents and Settings\test.php on line 7
Notice: Undefined variable: ize in C:\Documents and Settings\test.php on line 8
Notice: Undefined variable: ize in C:\Documents and Settings\test.php on line 7
Notice: Undefined variable: ize in C:\Documents and Settings\test.php on line 8
this-sel
foobar
foobarfoobar
Notice: Undefined variable: ize in C:\Documents and Settings\test.php on line 8
Notice: Undefined variable: ize in C:\Documents and Settings\test.php on line 7
Notice: Undefined variable: ize in C:\Documents and Settings\test.php on line 8
this-sel
foobar
foobarfoobar
BlackY
sajnos nem egyseges az OO sem, nem mukodik minden nyelvben. Javaban 100% mukodik, de meg a C++ot es a C#ot is meg mernem kockaztatni.
Na igen, Java-ban is hülye tulajdonságnak tartom... Az x-es mondjuk egy kicsit túlságosan valótlan példa, de pl. egy length tulajdonságnál előfordul, hogy egy hatalmas kódtömeg közepére beszúrsz még három-négy sor kódot, ahol deklarálsz egy lokális változót length néven (amiben ideiglenes tárolod egy tömb méretét, vagy akármi), és utána továbbra is fordul a kód, de hibásan fog futni.
(PHP-nél, ahol ugye még deklarálni sem kell(/lehet) a lokális változókat, mégnagyobb bug-forrás lenne egy ilyen "feature")
BlackY
(PHP-nél, ahol ugye még deklarálni sem kell(/lehet) a lokális változókat, mégnagyobb bug-forrás lenne egy ilyen "feature")
BlackY
És még az érdekelne, hogy az objektumoknak mekkora elonyuk van a sima funkciókkal szemben? Pl. mi a jobb? Egy kulon file-ba irni a classokat, majd ahol kell beincludeolni, vagy egy kulon file-ba irni kulonbozo funkciokat (lenyegeben ugyanezt teszem, ha classot irok, mert a classon belul ugye funkciók vannak) és beincludeolni ahol kell?
Classon belül metódusok/operációk vannak, de ez csak elnevezés.
A legfontosabb (egyetlen?) előnye az újrafelhasználhatóság: egy jól megtervezett objektum-modellel / osztály-hierarchiával a kód későbbi újrahasználatánál azt csak specializálnod kell az aktuális problémára, vagyis származtatsz egy gyermekosztályt és megírod azt a funkcionalitást, ami még pluszban kell.
Hogy függvényekkel vagy osztályokkal csinálsz-e valamit. Ha a problémát tudod általánosítani, és olyan keresni benne olyan elemeket, amelyeknek azonosak a tulajdonságai, akkor naná (pl. egy absztraktabb webáruháznál ez lesz a Termek osztályod, később ha nyitsz egy autókereskedést, akkor csak simán származtatsz ebből).
Viszont ha ilyeneket nem találsz, akkor az oo felesleges (bár "névtérnek" használhatóak az osztályok, és akkor statikus metódus-hívásokat használsz, pl.: DB::query()).
Igazából minden modellezhető objektumokkal ugyanúgy, mint objektumok nélkül (akár függvények nélkül is, de akkor sokat fogsz copy-pastelni), megszokás és szemléletmód kérdése.
BlackY
A legfontosabb (egyetlen?) előnye az újrafelhasználhatóság: egy jól megtervezett objektum-modellel / osztály-hierarchiával a kód későbbi újrahasználatánál azt csak specializálnod kell az aktuális problémára, vagyis származtatsz egy gyermekosztályt és megírod azt a funkcionalitást, ami még pluszban kell.
Hogy függvényekkel vagy osztályokkal csinálsz-e valamit. Ha a problémát tudod általánosítani, és olyan keresni benne olyan elemeket, amelyeknek azonosak a tulajdonságai, akkor naná (pl. egy absztraktabb webáruháznál ez lesz a Termek osztályod, később ha nyitsz egy autókereskedést, akkor csak simán származtatsz ebből).
Viszont ha ilyeneket nem találsz, akkor az oo felesleges (bár "névtérnek" használhatóak az osztályok, és akkor statikus metódus-hívásokat használsz, pl.: DB::query()).
Igazából minden modellezhető objektumokkal ugyanúgy, mint objektumok nélkül (akár függvények nélkül is, de akkor sokat fogsz copy-pastelni), megszokás és szemléletmód kérdése.
BlackY
Van azert meg, amit az elony listara kell irni. Legyen egy olyan helyzet, amikor van egy APId es annak vannak kulonbozo funkcioi, amiket el tudsz erni. Viszont lehetnek olyan tulajdonsagai es/vagy metodusai, amelyeket kintrol nem latsz. No mar most, sima imperativ programozasnal ezt nem tudod megoldani.
Miert akarsz letiltani valamit? Tobb ok lehet a leggyakoribb magyarazat (nem feltetlenul a leg helyesebb, de jol szemlelteti a lenyeget): a felhasznalot ne erdekelje mi van az objektumban, a felhasznalot erdekelje, hogy a kello bemenetre a kell kimenetet adja. Masneven feketedoboznak ismeretes (black box). Ez sok mindennel igy van, legyen az software vagy hardware programozas.
Miert akarsz letiltani valamit? Tobb ok lehet a leggyakoribb magyarazat (nem feltetlenul a leg helyesebb, de jol szemlelteti a lenyeget): a felhasznalot ne erdekelje mi van az objektumban, a felhasznalot erdekelje, hogy a kello bemenetre a kell kimenetet adja. Masneven feketedoboznak ismeretes (black box). Ez sok mindennel igy van, legyen az software vagy hardware programozas.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.