Öröklött osztály példányából szülő tulajdonságának elérése
Próbáltam rájönni, hogy az egyik objektumban beállított változó értékét hogyan lehet átvinni egy másikba, de nem sikerült, remélem tudsz segíteni. Példa:Tehát azt szeretném elérni, hogy ez így ahogy van, visszaadja nekem az IP címet - anélkül, hogy a "b" objektumban, vagy bárhol máshol újra meg kellene hívnom az "ip" függvényt.
■
<?php
class a {
function a () {
$this -> ip = $this -> ip();
}
function ip () {
return $_SERVER["REMOTE_ADDR"];
}
}
class b extends a {
function b () {
return $this -> ip;
}
}
$b = new b;
echo $b -> b();
?>
azt hiszem ilyesmi lesz a megoldás
Bele tenyereltél rendesen. :) PHP4-ben áthidalni tudnám. A probléma a következő. $a osztályod konstruktorának kéne lefutnia, amikor $b osztályod létrejön. Ez akkor törtenik, ha örökletes konstruktor van. Alapból nem. Tegyél egy echo-t $a osztály konstruktorába, és ha kííródik, amikor $b osztályt létrehozod, akkor jó. Ezekután el kéne érned a változóit. Ha C++ vagy valami szigorúbb nyelvet nézel meg, akkor a fordító nem is engedi elérni, csak egy osztály public változóit. Ha származtatsz belőle, akkor protected változóit. De a private-et soha. Tudomásom szerint PHP4-ben ezt nem tudod definiálni. Használhatsz úgynevezett static változókat is, akkor létre sem kell hoznod az osztály ahhoz, hogy elérd a változót, hiszen típusként foglalt már neki területet. De ez le van írva valahol nagyon szépen, most nem mennék bele. A lényeg, hogy kell $a osztályba egy lagalább protected változó, és azt eléred $b-ből. figyelj, hogy ne ugyan az legyen a függvények neve, hiszen akkor override-ról van szó. Nem tudom hogy mondja szépen a magyar. :) PHP5 ben valahogy így néz ki.
Remélem tudtam segíteni. Hajrá!
el van bonyolítva
Kicsit elbonyolítottad ezt a dolgot. A lényeg pont amit írtál is, hogy ha van konstruktorod egy osztályban, akkor a szülő konstruktora nem hívódik meg automatikusan, ezért neked kell meghívni.
Thx
Mégsem
parent::constructorneve();parancs kiadásával újra lefut a konstruktor (nem csak átadja a tartalmát). Ezzel persze a benne lévő összes függvény is újra lefut (épp ezt szeretném elkerülni). Igaz, hogy ha szó szerint vesszük a nyitó postot, akkor a megoldások tökéletesek, mert ugye konkrétan nincs újra meghívva az "ip" függvény, de természetesen úgy értettem, hogy ne kelljen újra lefutnia ahhoz, hogy megkapjam az értékét.ez így nem érthető
Kicsit pontosabban kéne fogalmaznod, mert amiket fentebb írtál, az nem igazán értehtő, plusz olyan foglamkata is használsz, amik szintén nem igazán definiálhatók ebben a kontextusban.
Mi az, hogy újra lefut? Csak egyszer fut le, amikor ezt a parancsot kiadod.
Ilyen nincs, hogy konstruktr tartalma, meg annak átadása.
Szóval kicsit pontosítanod kéne, hogy mit is szeretnél, lehet, hogy az általad vázolt bojektum struktúra nem igazán szerencsés.
Felhő
Sorry
Ha csak egyszer fut le, akkor ennek a kódnak miért az a kimenete, ami?
Lefutott az 'a' konstruktora
xXx.xXx.xXx.xXx
Azt most hirtelen nem tudom lecsekkolni, hogy PHP4 alatt ennek mi a kimenete, de PHP5 ezt dobja. És ebből ugye az derül ki, hogy lefut a szülő objektum konstruktora, amikor létrehozok egy példányt a "b" objektumból, és akkor is, amikor kiadom a
parentparancsot a "b" objektum konstruktorában (parent nélkül meg egyszer sem fut le, akkor egyáltalán nincs kimenete a példának).Nos meglehet, valahol itt kezdődik a probléma :) A tartalom átadásán meg azt értettem, hogy ha beállítok benne változókat, azokat ugyanúgy elérjem egy másik objektumban is (de ezt leírtam a nyitó postban is).
Meglehet az is, hogy nem túl szerencsés a programom felépítése (lévén kezdő vagyok az OOP-ban). Ez esetben némi útmutatást is elfogadnék, hogy hogyan kellene ezt megvalósítani.
Mit mást várnál?
Írd le leégyszi, hogy mit szeretnél pontosan elérni, és akkor tudunk tanácsot adni egy szerencsésebb osztály struktúra kialakításra. Így igazából csak egy helyben topogunk, mert nem igazán látszik, hogy a kódod milyen célt is szolgálna.
Felhő
Csak szivatsz, ugye?
Már nem tudom hanyadszor írom le, hogy éppen azt szeretném elkerülni, hogy újra meg legyenek hívva a függvények, de a beállított változók értékeit elérjem egy másik objektumban is. Még logikus is, mert minek futtassam le kétszer ugyanazt a függvényt, ha egyszer már lefutott és csak az értékeit akarom megkapni...?
Pontosan azt szeretném elérni, amit leírtam már ki tudja hányszor. De a kedvedért leírom újra; Beállítok egy változót az egyik objektumban, és annak az értékét meg szeretném kapni egy másik objektumban, anélkül, hogy újra meg kellene hívnom a függvényt, ami beállítja a változó értékét. Mert hát már van értéke a változónak, csak épp egy másik objektumon belül, tehát valahogy csak át kellene vinni egyik objektumból a másikba. Ha mondjuk van egy
$lecso = "kóbászos";változóm az "a" objektumban, akkor az kóbászos legyen a "b"-ben is (de ne úgy legyen kóbászos, hogy újra beállítom neki ezt az értéket egy függvény újrahívással). Kápísi?Ez a példa, mint a neve is mutatja, csak egy példa. Egy eszköz, amin keresztül be tudom mutatni, hogy mit is akarok konkrétan, ha esetleg a kérdés feltevéséből nem lenne egyértelmű. Tehát a célja csak szemléltetés, semmi egyéb.
A fentieket csak a kedvedért írtam le (sokadszorra), mivel idő közben próbáltam rájönni a megoldásra, és sikerült is. Ha lejjebb görgeted az oldalt, láthatod is az eredményt. PHP4 és PHP5 alatt is pontosan úgy működik, ahogy elképzeltem. Legalábbis úgy tűnik, aztán lehet, hogy tévedek. Ezesetben majd egy nálam okosabb ember kijavítja a tévedésem, ha arra érdemesnek találja, hogy egyáltalán foglalkozzon a témával. Feltételezem, ez nem te leszel, hisz még a kérdést sem sikerült feldolgoznod.
Mégegyszer elnézést a stílusért és a néhol éles szóhasználatért, de komolyan nem értem, hogy mit nem lehet ezen érteni...
sorry, de ez triviális
akonstruktora, arra válaszoltam.Amúgy meg attól hogy csak egy példáról van szó, még lehetne szemléletes, de ez másik kérdés.
Felhő
Na jólvan...
No Comment
Off... bocs
Hagyd csak
Felhő
Thx
Én kérek elnézést
Egy másik út
Jelen esetben is Te ismétlődő kérdésnek vetted a kérdésem, de érdemben nem válaszoltál rá, mert nem a problémád írtad le, hanem egy konkrét technikai kivitelezést kerestél, de könnyen lehet, hogy a problémád megoldására nem ez a helyes struktúra.
De ezt már neked kell eldönteni.
Felhő
Izé mizere
Izé...
PHP4-ben a konstruktor neve megegyezik az osztály nevével és ha van ilyen "osztálynév" nevű metódusod, akkor automatikusan meghívódik
PHP5-ben a "function b(){...}" csak egy szimpla metódus és nem konstruktor.
kompatibilitas
Azert erre csak olcsobb italokban fogadj. ;)
Kompatibilitasi okokbol ugyanugy hasznalhato az osztaly nevevel megegyezo nevu fuggveny konstruktorkent is.
Felho
Megvan
xXx.xXx.xXx.xXx
Valami ilyesmit szerettem volna elérni. Ez így használható, igaz? Vélemények?
PHP4 & PHP5
Re: 17
Kedves Gergő, ha van ötleted egy szerencsésebb struktra kialakítására, szívesen fogadom a javaslatokat.
észrevételek
Én személy szerint az adatbázis kezelésére ezt a megoldást ajánlom. A cikkben minden le van írva, ezért itt most nem mennék bele az előnyeibe.
Na ez szerintem tipikusan nem jó használata az öröklődésnek. Ha belegondolsz, akkor az
általánososztály nem egyfajtadbosztály, hanem szüksége van rá a működéséhez, használja azt. Jelen esetben az objektum kompozícióval jobban jársz.A következő öröklődésnél is érdemes lehet elgondolkodni, hogy szükséges-e. Igazából itt sem specializálod a szülő osztályt (konkrét kód nélkül ez az érzésem), hanem a korábbi funkcionalitásától eltérő tulajdonságokkal ruházod fel, itt is szerencsésebb lenne egy objektum helyett több kisebb, kevesebb felelőséggel bíró objektum használata.
Szintén érdemes lehet megismerkedned az MVC modellel, ötletet adhat arra, hogy egy kérés kiszolgálását milyen szempontok szerint lehet részekre bontani, és ezekre a részfeladatokra létrehozni különböző objektumokat.
Felhő
Re: 19
Bevallom, a db osztályomat nem nagam írtam meg, neten találtam rá egy kész megoldást. Itt-ott testreszabva azóta ezzel dolgozok. Használatba vétel előtt átnéztem, és szerintem egész jól megírt program, de azért kíváncsi lennék a véleményedre ezzel kapcsolatban is.
Az adatbázis osztály szerintem tipikusan egy olyan része a programnak, amit gyakorlatilag mindenhol használni kell, ill. valószínűleg szükség lehet a használatára. Amit mondtál, azt mind aláírom, de ha van olyan, hogy "a kivétel erősíti a szabályt" (nincs ilyen, mert mint tudjuk, csak egy félrefordítás eredménye ez a mondás), akkor ez pont a DB osztályra igaz. Persze meglehet, hogy tévedek, és/vagy csak nem látom még át teljesen ezt az egészet.
És bár a belinkelt cikket korábban nem olvastam, a 7. postban láthatod, hogy jómagam is hasonló eredményre jutottam, tehát a fenti néhány sor nem kötekedés, vagy egyet nem értés. Azt kizárólag a DB osztályra értettem.
Ezt a cikket szintén nem olvastam, de a programom felépítésének vázlatából azért szerintem nagyjából kivehető, hogy hasonló szempontok alapján hoztam létre az osztályaimat. Talán annyi különbséggel, hogy én a modelt és a controllert valamilyen szinten összekapcsoltam, egynek vettem ("model, controller" => "általános osztály", "view" => "html osztály").
rere
Ha elolvasod a cikket akkor látni fogod, hogy az ott kialakított DB használati mód, az nem feltétlenül kötődik egy adott adatbázis kezelő osztályhoz. Amúgy ajánlanán neked, hogy egy általánosabban elterjedt DB layert használj. Belenéztem egy kicsit a kódjába, hát messze nem az igazi. Pl. ezzel nem tudnál ténylegesen két kapcsolatot létrehozni egyazon DB felé. A hibakezelése az igazából eleve kizárja, hogy egy komolyabb rendszer része legyen. Az escepe függvényben lévő rekúrzió, meg még egy két megoldás benne is hát elég érdekes. Ráadásul rengeteg olyan funkció van benne, ami nem egy alap DB osztály része. Kár ezeket egy osztályba belezsúfolni.
Ettől függetlenül egyrészt nem az a megoldás, hogy a DB osztályból származtatod az oldaladat előállító osztályodat, hanem hogy az használja azt (kompozició), másrészt meg akkor is érdemes úgy kialakítani a programod, hogy csak akkor jöjjön létre adatbázis kapcsolat, ha ténylegesen szükség van rá.
Igazából én nem is elsősorban ennek helyességére utaltam volna, hanem hogy az biztosan nem egy jó/igazi megoldás, hogy ezek az osztályok egymásból származnak, hisz ahogy te is írod, teljesen eltérő funkciókat valósítanak meg. Tehát legyenek a különböző célokra megfelelő objektumaid, és ezek kombinálásval alakítsd ki a programod, ne egy monumentális osztályod legyen.
Felhő
DB osztály
És hogy közben haladni is tudjak, esetleg felrakhatnád valahová azt a DB osztályt, amit mostanság legszívesebben használsz. Vagy ha ajánlani tudnál egyet, azt is megköszönném. Ha valaki olyan szinten van, hogy megírjon magának egy ilyen osztály, az nyílván meg is teszi. Ha viszont ilyen-olyan okból nem tudja saját maga megírni, kénytelen keresni kész megoldást, ezesetben viszont egyáltalán nem biztos, hogy a megfelelőt választja - lásd az én példámat.
AdoDB
Hát az az igazság, hogy a DAO-s rész igazából csak egy kicsit változott, abból egy ciket nem igazán lehetne kihozni, ami szép lassan formálódik bennem, az egy lehetséges program szervezési mintának a leírása, aminek ez is része lenne. A cikkhez képest annyit változtattam rajta, hogy amikor elkérek egy DAO-t, akkor a Factory figyelembe veszi, hogy az általa használt DB kapcsolat az milyen RDBMS is, és az ennek megfelelő típusú DAO-t fogja példányosítani. Kis példa:
Egy biztosan jó választás lehet az AdoDB. Nekem ez kicsit jobban tetszett, mint a PEAR::DB, de ez lehet csak megszokás kérdése. Ezenkívül PHP 5.1-től kezdve (5-től is van kiegészítésként) ki lehet próbálni a PDO-t is, de annyira nem vagyok oda tőle, de nagyjából korrekt és egységes felületet ad a különböző adatbázis kezelőkhöz.
Ezenkívül még vannak ORM cuccok, ezek valamilyen formában azt támogatják, hogy a DB séma alapján automatikusan legenerálják a DB-t kezelő objektumokat. Ezekből a legleterjedtebbek a Propel és a EzPDO, de akad még más versenyző is (MetaStorge, PEAR::DB_DataObject), vagy pl. a nemrég emlegetett Qcodo is tartalmaz ilyen cuccot. De ezeket még nem ismerem igazán részletesen, így nem igazán tudnám bármelyiket is kiemelni. Valamiért a Propelhez az egyik legszimpatikusabb, de úgy tűnik, hogy az EzPDO-nál is mindent megtesznek, hogy tudják mindazt, amit a Propel, elég aktívan fejlesztik, ezért az is egy jó választás lehet.
Felhő
Ez nekem sok
Nekem bőven megtenné egy olyan szimpla kis osztály, mint amilyet linkeltem. Alapvető funkciókat ellátja (connect, select_db, query, fetch_row, fetch_array, stb., és az escape), átlátható és könnyen használható. Ha esetleg egy ilyet tudnál ajánlani...
Nincs szükséged az egészre
o adodb.inc.php
o drivers/adodb-mysql(t).inc.php
Amúgy pl. a mysql driver az biztosan annyira sok ember által használt, hogy nem igazán lehet benne hiba. Lényegesen jobban tesztelt, mint egy eldugott kis DB osztályocska.
Mindenféleképpen ajánlom a doksijának az átnézését. Plusz tuti elég sok tutoriált lehet találni hozzá a neten. Aztán ha megtetszik, akkor lehet nézegetni a többi részét is, plusz ha egy másik DB-t szeretnél használni, akkor nem kell egy tök másik API-t megtanulnod, használhatod a megszokott funkciókat.
A függvények többsége abszolút nem felesleges: GetOne, GetRow, tranzakció kezelés, prepared statement stb..
Létezik belőle amúgy egy AdoDB Light verzió is, amiben a fontos funkciók ugyanúgy léteznek, de a körítés nincs.
Felhő