Veszélyes az objektumközpontú programozás?
Sziasztok!
Már egy jó ideje programozok PHP-ben, de eddig még soha sem használtam objektumokat. Tőletek hallottam, hogy milyen jó, ezért úgy gondoltam kipróbálom. Elővettem a könyvemet (Tanuljuk meg a PHP4 használatát 24 óra alatt), odalapoztam az Objektumok fejezethez és teljesen meglepődtem!
„Az objektumközpontú programozás veszélyes. Megváltoztatja a programozásról való gondolkodásmódunkat és ha egyszer hatalmába kerít, nem tudunk tőle szabadulni.”
Húha! Ez most jó vagy rossz? A számítógépek 5. generációjába vezették be az Objektum orientált programozást, most a 6. generációban vagyunk.
- Tehát ez az alapja a modern programozásnak? vagy
- Egy régi túlhaladott, elavult technika?
Ahogy elolvastam nem tűnik, olyan ördöngösségnek. (pl.: a var változó definíció nagyon sok helyen van Pascal, Javascript...)
A végén ismét: ~ az objektumközpontú programozás megértése nélkül is jó PHP programozó válhat az emberből.
Előnyök: könnyű átlátható, újrahasznosítható és rugalmas forráskód.
Hátrányok: több erőforrás használat, más gondolkodásmód, amelytől nem szabadulhatunk. :-)
- A PHP5 is ezt az ágat erősíti. (Nem tudom miben több.) Tehát ez a világ legszuperebb dolga? vagy
- Állandóan nagy harc folyik az erőforrások használatának a lecsökkentésében érdekében. Erre pazaroljuk a drága időt?
Szóval az lenne a kérdésem: Tényleg veszélyes az objektumközpontú programozás? Vagy csak a könyv visel egy régebbi álláspontot?
Mivel csak egy könyvem van, ezért nem tudom összehasonlítani, hogy mennyire vegyem figyelembe a leírtakat. Szeretném a véleményeteket kérni ez ügyben. Előre is köszönöm a válaszotokat.
■ Már egy jó ideje programozok PHP-ben, de eddig még soha sem használtam objektumokat. Tőletek hallottam, hogy milyen jó, ezért úgy gondoltam kipróbálom. Elővettem a könyvemet (Tanuljuk meg a PHP4 használatát 24 óra alatt), odalapoztam az Objektumok fejezethez és teljesen meglepődtem!
„Az objektumközpontú programozás veszélyes. Megváltoztatja a programozásról való gondolkodásmódunkat és ha egyszer hatalmába kerít, nem tudunk tőle szabadulni.”
Húha! Ez most jó vagy rossz? A számítógépek 5. generációjába vezették be az Objektum orientált programozást, most a 6. generációban vagyunk.
- Tehát ez az alapja a modern programozásnak? vagy
- Egy régi túlhaladott, elavult technika?
Ahogy elolvastam nem tűnik, olyan ördöngösségnek. (pl.: a var változó definíció nagyon sok helyen van Pascal, Javascript...)
A végén ismét: ~ az objektumközpontú programozás megértése nélkül is jó PHP programozó válhat az emberből.
Előnyök: könnyű átlátható, újrahasznosítható és rugalmas forráskód.
Hátrányok: több erőforrás használat, más gondolkodásmód, amelytől nem szabadulhatunk. :-)
- A PHP5 is ezt az ágat erősíti. (Nem tudom miben több.) Tehát ez a világ legszuperebb dolga? vagy
- Állandóan nagy harc folyik az erőforrások használatának a lecsökkentésében érdekében. Erre pazaroljuk a drága időt?
Szóval az lenne a kérdésem: Tényleg veszélyes az objektumközpontú programozás? Vagy csak a könyv visel egy régebbi álláspontot?
Mivel csak egy könyvem van, ezért nem tudom összehasonlítani, hogy mennyire vegyem figyelembe a leírtakat. Szeretném a véleményeteket kérni ez ügyben. Előre is köszönöm a válaszotokat.
Nem
Béna mondat
kifejti a szerző
Erőforrások
Egyébként meg keres rá a google-n, rengeteg jobbnál jobb leírás van. Én ezt a 24 órásat nem ajánlom annyira, mert ahogy tudom, ez a php4-hez készült, de a php5-ben jobban ki van domborítva.
Ez egész jónak tünik: http://hu.wikipedia.org/wiki/Objektumorient%C3%A1lt
Ne hagyd ki
Sokat fejlődtek a PHP objektumorientált képességei az utóbbi időben, ezeket érdemes kihasználni. Szkript nyelv lévén viszont nagyon gyerekcióben jár az OOP támogatás. Szerintem ne hazsnál PHP4hez írt oktatóanyagot azok a dolgok nagyon túlhaladottak.
Az első fázisban amikor rájössz, hogy mennyire jó dolog, mindenre objektumokat fogsz majd írni, ami erőforrásigényessé teszi a kódodat, ne küzdj ellene ez egy fejlődési szakasz, át kell esni rajta, mint a bárányhimlőn... Később, (ha már néhányezer objektumot megírtál :) érezni fogod, mi az, ami objektumba kívánkozik, és mi az, ami nem.
A "generációk" szöveget felejtsd el. Aki eléggé el van telve magától, és könyveket ír, az hajlamos számítógépek 6. generációjáról, 3. szoftverkrízisről meg hasonlókról papolni. Ez boszorkányság, tűzre vele... Ha megfelelő fordítót írsz, akkor Neumann ENIAC-ját is lehet OO-ban programozni.
urban legend(?)
Ezt tudnád indokolni?
Felhő
hirtelen példa
Inkább egy szervezet részeiként fognak működni a dolgok, megszűnik a klasszikus modularitás.
Egy példa:
A mostani rendszeremben a user (session) kezelést 3 modullal csinálom:
session_minimal
session_handle
session_maintain
Mindegyik modul az előzőekre épül. Az első a user id-t kérdezi le. Ez minden alkalommal lefut (kell-e login form az oldalra stb). A másodikban lehet a user paramétereit elérni, változtatni (gyakran kell, de távolról se minden oldalon). A harmadikban pedig regisztráció, belépés, kilépés stb. Ezeket ugyebár csak egy-egy php hívja meg.
Ha az OOP-t erőltetném, lenne egy vagy több objektumom amik viszont nem elválaszthatók. (Ilyen módon semmiképpen). Az OO egyszerűen nem alkalmas erre, nem is feladata.
Azt, hogy sebességben a sorrend: Asm, C, referencia alapú nyelvek, nem legenda, hanem tény. Ez pedig nem azért van, mert jobb, vagy rosszabb fordítót készítettek az egyes nyelvekhez, hanem azért, mert minél magasabb szinten gondolkodsz a kód annál idgenebb a gépnek, annál bonyolultabb gépi kód lesz az eredménye. Másik velejárója, hogy optimalizálni is egyre kevésbé tudod a programot, hiszen kicsúsznak a kezedből az erre való eszközök. (Objektum klónozása: milyen copy-konstruktor very a memcpy-t? - és nem dobálózom olyanokkal, hogy "repnz movsw" - de azért megelítem ;)
De miért iratsz le velem ilyen dolgokat?
elhamarkodott allításnak érzem
Nem teljesen tiszta, hogy mit értesz "integrációs fok" alatt. Nem kötekedés képpen írom, csak amire elsőre gondolnék, hogy mi lehet, az az absztrakciós szint, de szerintem nem erre gondolsz.
Miért kell ezeket összekeverni?
Ha rosszul tervezed meg/alakítod ki az osztályaidat, akkor igen...
...de ha jól, akkor nem lesz semmi gondod, És ezért tartom pl. a fenti kijelentést is hibásnak.
Egyrészt mi az, hogy referencia alapú nyelv, hogy jön ide? Másrészt a kijelentésed, amire reagáltam, az nem ASM vs PHP-ről szólt, hanem az volt benne, hogy az OOP programozás erőforrásigényesebb lesz, ami szerintem szintén nem állja meg a helyét. Többször volt szerencsém procedurális kódok refaktorizációjára (ez általában nálam némi "OOP-sítéssel" járt), és jószerivel mindig csökkent a kód mérete, lazy loading megoldásokkal a feleslegesen behúzott kódok mérete, és mindemellett egy könnyebben olvasható és karbantartható/módosítható kódot eredményezett.
Ez utóbbit hol használod PHP esetén? ;)
Csak mert az idézett állítással nem értek egyet, és kíváncsi lettem volna az érveidre.
Felhő
ez bizony kötekedés.. :)
Egy objektumnak van konstruktora, destruktora, VMTje, meg még ezer "haszntalan" dolog, amit megspórolsz nélküle.
A memcpy-t azért hoztam fel, hogy egy alacsonyabb szintű eszközzel jobban kézbentartod az erőforrásokat. Elveszíted a referenciákat, de kapsz helyette sebességet. És így tovább. Ha magabb szinten dolgozol a gondolataid szárnyalhatnak, de a proci nyög alatta :)
Meggőződésem, hogy egy rendszeren (a php-n) belül is igaz ez. Erre hoztam a user és session kezelést (erről tényleg nem írok most). Egy objektum metódusait (és a hozzá tartozó adattagokat) nem dobálhatod pl használati gyakoriság szerint. Az nem hiszem, hogy logikailag épkézláb objektumokat adna.
A függvényket oda pakolod, ahova szeretnéd, tekintsük ezt az optimalizálás egy formájának. Ahhoz, hogy ezt megtedd oo-ban, ahhoz meg kéne bontanod az objektumokat. Ugyanezt a traumát, ha procedúrákban dolgozol csak akkor szenveded el, ha függvényeket bontasz meg.
Azt próbálom összehordani, hogy a "szemlélettel" változnak az eszközök is, amiket kapsz. Az objektumok egy nagyobb fokú integrációt jelentenek, hiszen egy újabb szerveződési szintet vezetsz be. Ami addig (változók, függvények) a levesben úsztak, azt most csoportosítod, és nevet adsz nekik. Ez egyel több szint, amiben egyszerre kell gondolkodni. Itt már nem copyzunk, hanem copy construkort hazsnálunk, ami az esetek nagyrészében pazarlás, viszont ha abban kezdenél gondolkodni, hogy "most ez az objektum símán másolható, vagy van benne valami valahol, amit újra kell inicializáni"... én biztos nem tudnék.
Egyszerre X szintben tudsz (megbízhatóan, kényelmesen) gondolkodni. Ha bevezetsz egy újat felül, elveszítesz egyet alul. Én legalábbis biztosan...
nem, más szemléletmód :)
Már miért ne tudnál? Nem csak az az optimalizálás, hogy alacsony szinten tudsz kódolni. Egy OOP kódit is igény szerint át tudsz alakítani, ha az szükségesnek bizonyul.
Procedurális alapon is tetszőlegesen összetett rendszert tudsz alkotni. Az másik lap, hogy elég nehéz ilyen alapokon egy ilyet megalkotni, és ha nem jól csinálod, akkor kezelhetetlenné válik a projekt.
Ez többször merül fel, de nem látom az összefüggést. Procedurális alapokon is nyugodtan használhatsz referenciákat.
Nekem meg meggyőződésem, hogy ez nem jó példa, és nem megfelelő dekompozíció eredménye.
Simán megteheted ezt OOP alapokon is, csak ismerni kell a lehetőségeket. Számtalan lehetőséged van, hogy futás közben egészíts ki egy objektumot az igényeknek megfelelően. És mindezt bárminemű "trauma" nélkül lehet elérni, csak tervezés/gyakorlat kérdése.
Ezzel teljesen egyet értek, viszont úgy érzem, hogy nem igazán ismered az OOP nyújtotta lehetőségeket.
Ezek jóformán alig jelentkeznek, mint overhead. Viszont van egy olyan aspektusa is a dolognak, hogy pl. kevesebb kódot kell az értelmezőnek beolvasnia, értelmeznie, ami által meg akár nyerhetsz is. Plusz a jobban átlátható kód eredményezheti azt is, hogy jobban át fogod látni a problémát, és hatékonyabb kódot fogsz tudni írni. Ez a gondolat kicsit jobban kibontva.
Ha az OOP, mint plusz réteg jelenik itt meg, akkor nem hiszem, hogy ne lehetne úgy OOP kódot írni, hogy ne lehetnél tisztában az alsóbb "réteg" működésével, sőt ez nagyon fontos is, különben tényleg nem fogsz tudni hatékony kódot írni.
Felhő
Jajj
Szerintem nem így kell megközelíteni az objektum-orientált programozást. Nem egy adu ászról van szó, csak egy programszervezési módszerről. A funkcionális programozás, a névterek használata mind-mind adott esetben hatékonyabb, vagy ugyanolyan jó kódot eredményezhetnek.
Én úgy érzem, hogy amiről te beszélsz, az a "hagyományos" procedurális, és az objektum orientált kód összevetése PHP esetén, és ez is csak egy igen szűk nézőpontból. Az OO nem egyszerűen önmagában jobb, hanem jobb és hatékonyabb tud lenni sok esetben.
Az egésszel csak annyit szeretnék mondani, hogy ne essünk túlzásba az OO dícséretében. Pont. Egyébként kb. egyetlen konkrét előnyt sem írtál le az OO mellett, csak egy darab hátrányt. Tessék konkrétumokról beszélni!
Egységbe zárás
kipróbálom
Most éppen fejlesztési stádiumban van a honlapom. Szinte az egészet átírom. Sokféle modulom van. (pl.: cikk, vicc, apróhirdetés és blog – ezek egy sémára)
Mivel nagyjából mindegyik ugyanúgy működik, készítek egy cikk osztályt. Ezzel megvan a cikk osztály, és ebből származtatom/örököltetem a többit. A feliratokat, tábla neveket változókba (tulajdonságokba) teszem, így csak a megjelenítő (tag)függvényt kell felülíratni.
Mivel több honlapon használom ezeket, nem kell a változók átvitelével bíbelődni, csak megváltoztatom az objektum tulajdonságát és kész.
Na ez a tervezett, és most jön a megvalósítás.
Valahogy így kell az objektumok világában gondolkodni?
prototípus?
hogy is?
Múltkor problémát jelentett a mezők adatainak a tárolása. Végül is úgy oldottam meg, hogy az adatokat elmentettem egy php fájlba (egy több dimenziós tömbben). Ha szükségem volt csak beágyaztam a megfelelő helyre.
Itt meg akkor, csak beágyaznám a megfelelő osztályt, létrehozóm az objektumot, feltöltöm a tulajdonságainak megfelelően az adatokkal. Lehet így elég könnyen megváltoztatni, vagy inkább tároljam fájlban (többnyelvűség esete)?
Igazából gondban vagyok, mert nem tudok minden modult „önjáróra” átalakítani. Jelenleg külön fájlban van összes adatmódosítással kapcsolatos függvény (űrlapkészítő, adatfeldolgozó, ellenőrző és ezeket összefogó függvény), az összes alapvetőfüggvény (adatbázis kezelés, hibakezelés) és maga a modul (ez leginkább a megjelenítésért felel). Az előbbi kettőt szinte az összes modul használja. Vannak olyan modulok is amelyek elég nagyok és gyakorlatilag nem használom minden funkcióját, ezért ezeket külön fájlban tárolom. (Pl.: felhasználó kezelés, ez mindig jelen van; de a hirdetési, bannercserés részt ritkán használják)
Vagy legyenek inkább ezek az objektumok? Csak olyan éles határt nem tudok húzni. (Pl.: az alapvetőfüggvények között)
Ha a cikk modul lenne a prototípus, akkor nem csak a megfelelő modult kell beolvasnom, hanem még a cikkekét is. Tehát inkább hozzak létre több osztályt, amelyek kisebb változtatásokban különbőznek, de így legalább nem kell fölösleges részt betölteni.
Ti hogy oldjátok meg ezeket a problémákat?