Téma: Procedurális vagy OOP

Luxi eredeti hozzászólása

Az ilyen jellegű osztályokkal az a baj, hogy elveszíted az SQL szerver által nyújtott előnyök nagy részét.
Ha ilyen entitás jellegű objektumokkal dolgozol, akkor például olyan adatokat is betöltesz az adatbázisból, amiket az adott oldalon nem jelenítesz meg.
Rosszabb esetben minden ingatlanoz (= adatbázis sor) példányosítasz egy objektumot, és onnantól azt használod, mintha az sql szerver nem is lenne alattad.
Én elég sokat dolgoztam mindkét metodológiával, és mostanra már biztosan mondhatom, hogy a webes fejlestések döntő többségénél érdemesebb az entitások kezelését az SQL szerverre bízni, különösen ha MSSQL-ről van szó.

A folyamatos, egyedi lekérdezésekkel, tárolt eljárásokkal végzett db olvasás kombinálva page output cache-el, meg legfeljebb pár helper objektum cache-ben történő tárolásával, hatékonyabb, mint saját objektumokkal újrafejleszteni a fél SQL szervert.

felrertettel. en is kihasznalom az sql lehetosegit.nem peldanyositok minden ingatlanhoz egy objektumot. az objektum csak eloallitja a lekerdezes alapjan az output-ot. es azt kihagytam hogy a kodon kivul termeszetesen az adatbazist is modositani kell ha uj jellemzoket veszel fel.

[off]
igen volt már dolgom objectekkel, de sosem irtam még. és azért valljuk be erős különbségek vannak egy szimpla osztály és egy ojjektum között.
[/off]

felrertettel. en is kihasznalom az sql lehetosegit.nem peldanyositok minden ingatlanhoz egy objektumot. az objektum csak eloallitja a lekerdezes alapjan az output-ot. es azt kihagytam hogy a kodon kivul termeszetesen az adatbazist is modositani kell ha uj jellemzoket veszel fel.

Nincs egy kicsit ... hmm túlspilázva az egész?
Mondjuk érdekes lenne, ha összehasonlitanánk egy object-es sql lekérést, egy class-osat és egy function-soat ugyanazon serveren, ugyanazzal a frémmel, ugyanazokkal az adatokkal. kiváncsi vagyok a futási időre és az erőforrás igényre.

Igazából az OOp -t több féle képpen lehet értelmezni.
Az én értelmezésemben az OOp egy tárolási elmélet, meg egy nem ennek a metódusnak / class-nak a problémja szemlélet tökéletes kivitelezésére alkalmas.

Konstruktor.
Hmm.. Erre vegyünk egy példát.
Adott egy lakás ami tök sötét. Amikor belépsz az ajtón ezt a rendszer érzékeli és a belépés tényére lefoglal egy szobányi helyet a térben, felépiti az alap szobát, bekapcsolja a világitást, elindit egy halk zenét, elindul a klima, és kibont egy sört, és oda teszi neked a hütő mellé.

És itt rögtön látszik is a túl bonyolult konstruktorok használatának a hátránya. A sört akkor is oda teszi amikor belépsz hogyha matt részeg vagy és nincs rá szükséged, és akkor is amikor a szomszéd gyerek llép be.

és ugyebár 5.2 -es php-tól kezdve vannak destruktorok is.
Az kb ugyan ez pepitában amikor kimész a lakásból akkor a rendszer kikapcsolja a zenét, leoltja a villanyt, feltakarit, kidobja a sörös üveget, kikapcsolja a klimát, lebontja a szobát, és felszabaditja a teret.

Természtesen ebből a rendszer csak a terület foglalást, és az alap szoba felépitést csinálja automatikusan az összes többit neked kell egyszer leprogramozni.

Ez abban az esetben müködik jól és hatékonyan, ha az esetek legaláb 80%-ban a konstruktor által elvégzett dolgokra van szükséged. De az OOp magában nem sokat ér. Egészitsd ki egy MVC szemlélettel, és egy használható router / template osztályal, és akkor egy nagyon gyors fejlesztői környezetet kapsz.