OOP PHP-ben
Sziasztok!
Nem konkrét a kérdés, inkább elvi. Nem igazán értem, mi történik pontosan egy interpreteres nyelven írt objektum orientált programban. Sőt azt sem teljesen, hogy mi történik egy webalkalmazásban. Ha jól tudom, a CGI esetén a webszerver annyi példányban indítja az interpretert, ahány kérés fordul az adott programhoz. Viszont ha modulként fordítjuk a PHP-t (vagy a Perlt ill. Pythont), akkor (úgy tudom) egy példányban fut az interpreter, ekkor az egyes kérések szálak, vagy mik? Szóval már ezek sem tiszták a számomra. Az objektum orientáltság csak rátesz egy lapáttal. Mondanátok egy konkrét példát arra, hogy miért jó az, hogy az egyszer megírt kód objektumpéldányonként újrafelhasználható, illetve mikor jó ez és mire? És mi történik akkor, amikor egyszerre több felhasználó áll kapcsolatban egy webalkalmazással és az egyik beállítja egy változó értékét (nem a merevlemezen, vagy adatbázisban, hanem a memóriában), a másikat ez nem befolyásolja? (Persze, biztos nem, csak nem látom át az egészet). Remélem nem tűnik (tűnnek) zagyvaságnak a kérdés(ek).
Köszönettel PiPi (itt foxmulder)
■ Nem konkrét a kérdés, inkább elvi. Nem igazán értem, mi történik pontosan egy interpreteres nyelven írt objektum orientált programban. Sőt azt sem teljesen, hogy mi történik egy webalkalmazásban. Ha jól tudom, a CGI esetén a webszerver annyi példányban indítja az interpretert, ahány kérés fordul az adott programhoz. Viszont ha modulként fordítjuk a PHP-t (vagy a Perlt ill. Pythont), akkor (úgy tudom) egy példányban fut az interpreter, ekkor az egyes kérések szálak, vagy mik? Szóval már ezek sem tiszták a számomra. Az objektum orientáltság csak rátesz egy lapáttal. Mondanátok egy konkrét példát arra, hogy miért jó az, hogy az egyszer megírt kód objektumpéldányonként újrafelhasználható, illetve mikor jó ez és mire? És mi történik akkor, amikor egyszerre több felhasználó áll kapcsolatban egy webalkalmazással és az egyik beállítja egy változó értékét (nem a merevlemezen, vagy adatbázisban, hanem a memóriában), a másikat ez nem befolyásolja? (Persze, biztos nem, csak nem látom át az egészet). Remélem nem tűnik (tűnnek) zagyvaságnak a kérdés(ek).
Köszönettel PiPi (itt foxmulder)
Miért számít az, hogy interpretált?
Üdv,
Felhő
PHP, Multithread és OOP
Multithread-esnek szokás hívni azt a webszervert, ami több kérést szolgál ki egyszerre. Ilyenkor a szervernek van egy vezérlő része, ami egy példányban fut, és kontrollálja a kiszolgálást végző szálakat. (A szál és a process nem ugyanaz. Ezek a webszerverek nevük ellenére több processből és nem szálból állnak, de ennyire ne menjünk a részletebe.) A lényeg, hogy eredendően több szálon fut a webszerver. Ezek a szálak egymással nem kommunikálnak. Ha több PHP szkripted fut egyszerre, akkor azok külön futási környezetben vannak. Lézetik a PHPhez "shared memory" kiterjesztés, csak ezzel lehet két futó php szkript között adatot cserélni, tehát hiába globális egy változó, minden csak az aktuális futási környezeten belül értendő.
Az OOP copy-paste újrahasznosíthatóságot jelent. Tehát ha jól írtad meg a kódot, akkor változtatás nélkül használhatod egy másik projektben is, és nem kell mégegyszer megírnod, például egy bevásárlókosár funkcionalitást egy webáruházba. Kb úgy, mintha saját függvényeket írnál, amiket aztán több projektben használsz.
Az objektum orientáltság egy magasabb logikai szintet valósít meg, ez az egységbe zárás. Ha a beásárlókosár példánál maradunk: a kosárnak több funkciója van, pl lehet betenni terméket, lehet kivenni és lehet megrendelni a kosár tartlmát. Ez 3 funció, viszont könnyen belátható, hogy használnak közös változókat. Ezeket a függvényket tarthatod egy PHP fájlban, hogy könnyen mozgatható legyen, de akkor is szennyezed a globális névteret. Például mi van, ha egy másik kivesz() függvényt is akarsz írni, de ez a név már foglalt, vagy egy másik $ár változót stb...
Ha az összes kosár-funkció és kosár-változó egy objektumban van, akkor minimalizáltad az összeütközés veszélyét. (Azzal, hogy bevezettél egy újabb logikai szintet, egy csomagot. Ez az objektum.) Ez a helyzet az újrafelhasználhatóság szempontjából. De programtervezés szempontjából ennél sokkal több előnye van a dolognak. (Például az objektumba zárt változók - ezek az adattagok vagy mezők - többszöröződnek az objektummal együtt. Futtathatsz két kosarat úgy, hogy ezek semmit sem tudnak egymásról, és nem ütköznek össze. - Kosárnál nem sok értelme van, de el tudsz képzelni olyan esetet, amikor igen. :)
B
thread, process
Üdv,
Felhő
Köszönet
PiPi
Két könyv a témában
ObjektumOrientált Szoftverfejlesztés (ComputerBooks kiadó)