PHP OOP
Sziasztok!
A PHP OOP-val most ismerkedek, de előzőleg már volt dolgom az OOP programozással más nyelveknél. Így a nagyon alap dolgok mennek. Sajnos még két hétig nem tudok olyan gép elé ülni, melyen ki is tudom próbálni a tanultakat, most azonban egy olyan kérdésbe futottam, amit tisztázni kell, mert egyébként a későbbiekben félrevezethet.
Tehát a kérdésem. Tegyük fel, hogy egy bejelentkező felületet akarok megvalósítani, ahol a belépett tagot egy Member objektumban tárolom. Ez az objektum létrejön a sikeres bejelentkezést követően, majd a header segítségével átirányítom a látogatót a kezdőlapra (vagy bárhova). Kérdésem, hogy itt valamilyen módon elérhető az adott Member objektum? Vagy milyen módon lehet azt később felhasználni? Esetleg ti az ilyen lehetőségeket hogy oldjátok meg?
Egy másik kérdés pedig, hogy van egy fórum, benne hozzászólások, téma nincs benne az egyszerűség kedvéért. Fórum objektum tartalmaz több hozzászólás objektumot. Ezt PHP-ban miként lehet tárolni (mint javaban pl az arraylist)?
Tehát engem főként az objektumok hatásköre, elérhetősége érdekelne egy tapasztalt PHP OOP szemszögéből :)
Köszi szépen,
nistv4n
■ A PHP OOP-val most ismerkedek, de előzőleg már volt dolgom az OOP programozással más nyelveknél. Így a nagyon alap dolgok mennek. Sajnos még két hétig nem tudok olyan gép elé ülni, melyen ki is tudom próbálni a tanultakat, most azonban egy olyan kérdésbe futottam, amit tisztázni kell, mert egyébként a későbbiekben félrevezethet.
Tehát a kérdésem. Tegyük fel, hogy egy bejelentkező felületet akarok megvalósítani, ahol a belépett tagot egy Member objektumban tárolom. Ez az objektum létrejön a sikeres bejelentkezést követően, majd a header segítségével átirányítom a látogatót a kezdőlapra (vagy bárhova). Kérdésem, hogy itt valamilyen módon elérhető az adott Member objektum? Vagy milyen módon lehet azt később felhasználni? Esetleg ti az ilyen lehetőségeket hogy oldjátok meg?
Egy másik kérdés pedig, hogy van egy fórum, benne hozzászólások, téma nincs benne az egyszerűség kedvéért. Fórum objektum tartalmaz több hozzászólás objektumot. Ezt PHP-ban miként lehet tárolni (mint javaban pl az arraylist)?
Tehát engem főként az objektumok hatásköre, elérhetősége érdekelne egy tapasztalt PHP OOP szemszögéből :)
Köszi szépen,
nistv4n
Kipróbálni miért ne tudnád,
Attól tartok, te is beleestél abba, amibe én az elején: az objektumokat valami olyan dolognak képzeled, ami a session egész időtartama alatt létezik. Na ez PHP esetében nincs így. Meg lehet (elméletileg) oldani pl. ... szerializációnak mondják "magyarul"?
Erre gondolok: http://php.net/manual/en/language.oop5.serialization.php
De érzésem szerint ez nem igazán illik a PHP logikájába. Egy fokkal egyszerűbb az élet, ha úgy számolsz az objektumokkal, hogy a lap letöltésekor létrejönnek, miután véget ért a letöltés, meg is szűnnek.
---------------
Mondom ezt úgy, hogy erősen kezdő vagyok a témában, szóval könnyen lehet, hogy valaki rövid úton cáfolja amit írtam. :)
Köszönöm a sok választ, látom
Én személy szerint támogatom az OOP terjedését, hisz "rákényszeríti" az embert, hogy átlátható kódot gyártson. És bár a jelenlegi körülmények között a kód lehet, hogy hosszabb lesz, mint ha procedurálisan írta volna meg a programozó, ha későbbi erre valami fejlesztést szeretnének eszközölni, akár más programozóval, akkor egy jól dokumentált forráskód megkönnyíti ezt a munkát.
De akár a saját munkámat is könnyíti, előző példánál maradva, ha a Member osztályom egyik függvénye írja ki a felhasználónevet több oldalon is, majd a megrendelő úgy gondolja, mától a vezeték+keresztnév kiírás legyen, akkor elég itt változtatni egy sort, és az oldal többi részén is megoldott a probléma.
Nem utolsó sorban, ha programozási nyelvet szeretne váltani valaki, akkor nem hátrányos, ha ismeri az OOP alapokat. Nekem ebben a JAVA-s ismereteim segítettek, hisz az alap logika a PHP és JAVA OOP közt megegyezik.
No meg ahogy nézegetem az állásajánlatokat, a legtöbb PHP programozótól elvárás, de legalábbis előnyként feltüntetett az OOP ismerete. Innentől kezdve szinte mindegy mit gondol a hétköznapi ember, ha ilyen állást szeretni megpályázni, jobb ha ismeri annak minden csínját-bínját.
Én személy szerint egy ideje már csinálgatok webes dolgokat, PHP megoldásokat is alkalmazok gyakran, ám azon jó része procedurális kód. Most, hogy kicsit komolyabban szeretnék a PHP körmére nézni (többek között azért, mert a szakdolgozatom egy PHP keretrendszer készítése, ahol szakdolgozat lévén nem ajánlott keretrendszereket használni, így nekem kell megírni szinte mindent az érdemi munka jegyében). És a tapasztalatom itt, és az egész webes világban (főként javascript) az az áttekinthetetlenség. Rengeteg fajta megoldás, melyek funkció sokszor átfedik egymást, vagy csak kisebb átiratai egymásnak. Először mind a PHP mind a JS framework-ök áttekintése, megismerése nagy gondot okozott, melyiket mikor, mire lehet használni. Aztán ezeket utána használni is tudni kell a munkád során, mert egyik cégnél ez az elvárás, másik cégnél pedig az. Nekem személy szerint - bár biztos van előnye - nem tetszik ez a fajta sokrétűség.
Nemrég volt szó a PHP-ban
Jómagam singletonokat használok, ami igazából nem sokkal több, mintha procedurálisan készítettem volna el, csak pár éve engem is meghatott az OOP pártiak ajvékolása, most meg már nincs értelme visszatérni.
Mondjuk ha ORM-et használ,
Általában erre az szokott jönni válaszként, hogy nagy látogatottságú oldalak, performancia, a PHP nem erre való, ne használjunk mindenre objektumokat, stb. Én meg erre azt mondom, hogy az ember tanuljon meg normálisan programot tervezni és implementálni és ha ez megy, akkor kezdjen "optimalizálni".
Kérdezőnek:
Objektumok halmazát többféle adatszerkezetben tárolhatsz, például szimpla asszociatív tömbben, vagy bármely SPL adatszerkeszetben: http://hu.php.net/manual/en/spl.datastructures.php
Két request között pedig az objektumok valóban elvesznek, ezért gondoskodni kell róla, hogy megmaradjanak: ez lehet relációs adatbázis, session (akár ez is lehet db-ben), nosql megoldások, stb.
A singletont meg egyre több
Persze, hogy meg lehet. Csak
A singletonról: lényegében a globális névtérben van, nem helyettesíthető, nehézkes a tesztelése. Keress rá a singleton, anti-pattern, evil szavak tetszőleges kombinációjára.
Csak több idő és több rejtett
Van egy ingatlanos oldalom, a látogató meg akarja nézni az egyik ingatlant.
$szobak_szama = $ingatlan->szobak_szama();
$terulet = $ingatlan->terulet();
...
vagy
$terulet = ingatlan_terulet($_ingatlan);
...
OOP-ben plusz egy sor a kód, ráadásul a script végén a PHP-nak kell felszabadítania az objektumhoz lefoglalt memóriát. Ha megnézek bármilyen weboldalt, az esetek túlnyomó többségében ennél nem végeznek bonyolultabb műveleteket.
És ezzel most nem kötözködni akarok, csak meg szeretném érteni, hogy miért is jó az OOP a weben. Ha több az előnye, mint a hátránya, áttérek rá.
A második példád is OOP.
A függvények ott a globális
És? Az osztályaid is.
A PHP egyik leggyakrabban
Vegyük példának az ingatlan adatainak azonosító alapján történõ betöltését.
Funkciónális programozás esetén az író nagyjából az alábbi szintaxis lehetõségek bármelyikét választhatja:
funkcionális?
Nem kötekedésképp, de nem
Bár a függvények elnevezése
Ez csak következetesség
Az $_ingatlan mi? Id? Mert
És mi van, ha többféle ingatlanod van és mondjuk egy szántóföld esetén nincs értelme szobaszámról beszélni. Egy ORM elintézi, hogy mondjuk a megfelelő típusú objektumot adja vissza neked adatbázisból, és a Szantofold::szoba_szama() kivételt dob. Viszont procedurálisan szépen telerakhatod ifekkel a függvénytörzset. Mindkét függvénynél, adott esetben.
Ez mind megvalósítás kérdése,
Az, hogy a
A kivételkezelés nem kötődik az objektumorientált szinatkszishoz: ha a nyelv támogatja, akkor procedurális nyelvtannal írt kódból is dobhatsz; ha nem támogatja, akkor objektumorientáltból sem fogsz tudni.
Természetesen tisztában
A kivételkezelésről annyit, hogy - gondolom tudod, de azért leírom nem feltétlenül neked - minden kivétel egy objektum és közvetlenül vagy közvetve az \Exception-ből származik. Ebből kifolyólag bátorkodtam a kivételkezelést az OOP-val kapcsolatos fogalomként említeni, ugyanis valószínűsítem, hogy aki ellenzi az OOP-t, meg úgy általában ördögtől valónak tartja a objektumok, osztályok használatát, az nem használ kivételeket sem.
Nem értem, miért kellenének
A PHP valóban csak az Exceptionből származtatott objektumokat engedi kivételként dobni: más nyelvekben bármilyen típusú adatot dobhatsz. Koncepcionálisan a kivételkezelésnek nincs köze az objetumorientáltsághoz.
Igazad van, tényleg
Semmi közöd hozzá, hogy
Nagyon is van közöm hozzá,
Nem tudom, vannak-e ismereteid Java vagy C# nyelvekben. Ott ez még inkább előjön és tapasztalható.
Az objektumorientáltság
Igen, van Java és C# tapasztalatom.
Mit nem értesz a dolgon?
Származtatással meg azért ne gyere, mert egyrészt erről csak OOP esetén van értelme beszélni, másrészt a privát attribútumokat nem kell ismernem, azokat ugyanis nem érem el a származtatott osztályban. És megint csak ott vagyunk, hogy a származtatott osztályban is pontosan látod az összes lehetőséget: member változókat és metódusokat, amikkel dolgozhatsz. Se többet, se kevesebbet.
Az IDE támogatásnak meg hogy ne lenne elvi korlátja? Getterek, setterek, implementálandó skeleten metódusok legenerálása, ezekhez tudtommal Reflection-t használnak az IDE-k. Reflection-nel hogy szeded ki, hogy a $form-ban milyen kulcsok lehetnek? De még ha annotációkban gondolkodsz, hogy fogalmazod meg a kulcsok függőségeit, stb.?
Fussunk neki újra. Kérlek,
Az objektum egy belső állapottal rendelkező entitás, amihez műveleteket definálhatunk. Egy objektumot meg lehet valósítani egy egyszerű egész számmal, vagy egy összetett struktúrával, mint egy asszociatív tömb. A műveletek függvények. Amikor műveletet végzel egy objektumon, akkor átadod a függvénynek az objektumot és a szükséges paramétereket, az pedig, amennyiben kell, elvégzi a belső állapot módosítását.
Neked, mint az objektum felhasználójának, ha az objektumot tömbként valósították meg, nem kell ismerned a tömb kulcsait, mert kizárólag az objektum nyilvános felületén, a függvényeken keresztül érintkezel az objektummal. Ezen függvényekhez ugyanúgy használhatsz IDE támogatást.
A származtatás ugyanúgy megvalósítható, a tömböt bővítheted a saját kulcsaiddal, és megírhatod hozzá a saját függvényeidet.
Fent privát helyett természetesen védettet akartam írni. Azt a védett kategóriát, amit sokan nem ok nélkül tartanak súlyos koncepcionális hibának, figyelembe véve, hogy egy leszármazott osztály ugyanolyan felhasználója az ősosztálynak, mint bárki más, és mint ilyen a védett tulajdonságok használatával vagy magát teszi kockázatnak az ősosztály megvalósításának változásakor, vagy bebetonozza azt a megvalósítást.
Szerintem egyébként egy tömb kulcsaihoz getter/setter generáló kód írása még reflectiont sem igényel.
A probléma az, hogy a tömb
Nem az a kérdés, hogy ugyanaz a funkcionalitás megoldható-e procedurálisan. Hanem az, hogy melyik dolgozik a programozó keze alá. Ha egy objektum belső tulajdonsága kívülről nem módosítható, akkor az nem "látom", nem férek hozzá, magyarul szűkül azon programrészek száma, amit át kell nyálaznom, meg kell értenem. Hiába oldod meg a származtatást procedurálisan, attól még kívülről bármikor szétbarmolhatom az egészet anélkül, hogy tudnék róla úgy, hogy csak később jönnek elő a hibák. OOP esetén csak akkor van ilyen, ha rosszul írták meg a kódot, vagy szánt szándékkal hackelek (pl. reflectionnel, vagy mondjuk unserialize-zel).
A unit teszt, tervezési minták ismerős szavak? Számomra elkeserítő, hogy 2011-ben is arról kell vitázni, hogy miért jobb strictebb módszereket használni. És még igencsak messze vagyunk egy erősen típusos nyelvtől. Nem személyeskedésnek szánom, de te az a típus vagy, aki mondjuk a DirectoryIterator-t felesleges erőforrás pazarlásnak tartja? Csak mert ha igen, akkor részemről befejeztem a diskurzust :D
Miért baj, ha feleslegesnek tartja? ;-)
Ezt eredetileg humornak szántam, de jobban belegondolva: végül is van benne valami. Ha a fájlrendszerben akarok mászkálni, akkor előveszem a sekélyes python v. perl tudásomat és abban bűvészkedek.
Miért pont ezt emelted ki az iteratorok közül?
(azt hittem, legalább egyszer végigolvastam a PHP doksit, de most megint kiderült, hogy mégsem. Vagy csak feledékeny vagyok... :-) )
Nem erre való? A PHP egy
A fájlműveletekre nagyon is alkalmas a PHP, nem ez az a témakör, ahol érdemes elgondolkodni másik nyelv alkalmazásán, ha csak nem ismered azt jobban.
De persze nem lepődök meg azon, ha valaki elutasítja az OOP-t. Az első bekezdésbeli véleményt egy néhány éves Java tapasztalattal rendelkező, PHP-re áttérő programozó mondta nekem.
Fene tudja... számomra a PHP
Ugye a neve is PHP Hypertext Processor, amiből a Hypertext a HTML-re utal - azt most puskáztam a wikiből, hogy eredetileg Personal HomePage-nek nevezték. Tisztában vagyok vele, hogy a név semmit nem jelent, csak az eredeti céljára akartam utalni.
(nem lehet valamit csinálni a... drupal-lal(???), hogy ne préselje így össze a thread végét?)
A konvenciókat minden projekt
A vitába pedig kizárólag azért szálltam be, hogy megmutassam, lehetséges procedurális szintakszissal is objektumorientált kódot írni, nem pedig azért, hogy amellett kardoskodjak, hogy érdemes. Lehet létjogosultsága akkor, ha a teljesítmény fontosabb, mint a kényelem, akkor ha az jobban kézre esik valakinek, vagy ha olyan nyelvvel dolgozik, ami nem támogatja.
Ezzel a hozzászólásoddal
OOP
Röviden: Térj át, akkor is, ha az én hozzászólásom után még mindig nem fogod érteni a rendszer előnyeit. Majd használat közben megérted, miért olyan jó beáldozni a teljesítményt.
Hosszabban: Vegyük a te példádat. Mi az ingatlan a valóságban? Egy objektum. A weben objektumokat "kezelünk", amiknek vannak tulajdonságaik (név, cím, telefonszám, méret, kor, ...) és vannak képességeik (mentes, keresés, megjelenítés, belépés, kilépés, ...). Adja magát, hogy objektumként kezeljük őket.
De pl kiíratod a területet:
Amit te tehetsz, hogy szépen, mind a 20 helyen átírod a kódot:
Hogyan mentesz új sort fv-ekkel?
Programtervezési minták? Van egy oldalunk, ahol külső fájlból is importálunk. A fájl eredetileg XLS lehetett. Aztán jöttek a további igények, most már lehet CSV és TXT is. A bővítés az előrelátó "iterator pattern"-es megvalósítás miatt - hagy ne fordítsam már le :D -, pillanatok alatt megvolt. A Symfony "filter chain"-jét szintén hogyan valósítod meg szépen és egyszerűen? Sehogy...
Lehet, hogy a te kódod 40%-kal gyorsabb, de az enyém fele annyi idő alatt készen van, a változó igényekre gyorsabban és hibamentesebben reagál. Ismétlem, egyszerűen azért, mert egyébként is objektumokat kezelünk a weben (ingatlan, felhasználó), amiknek vannak tulajdonságai (terület, név, cím) és vannak képességeik (login, logout, registration, save, ...). Akkor nem így használni őket, badarság.
+1
Érdekes amit írsz az
Én 3-4 éve álltam át az OOP szemléletre a weboldalak programozása során, de úgy, ahogy leírod, még sosem használtam őket. Egyszerűen azért, mert ha minden valódi objektumot példányosítanék, akkor nem 40%-kal, hanem 400%-kal lenne lassabb a weboldal.
Képzeljünk csak el egy webshopot, amiben kilistázol oldalanként 50 terméket. Ha ezt objektumként kezeled, akkor 50 objektumot példányosítanál? Fórumbejegyzés? Stb...
Röviden, nálam a való élet objektumai tömbökben vannak, amik az adott adatmodellhez tartoznak, egy példány van belőlük (általában).
Mondjuk olyannal még nem nagyon találkoztam, hogy valamelyik objektum paraméterét egyenként kell beállítani (pl. setTerulet). Jellemzően a POST tömböt szoktam iterálni (nyilván ellenőrizni, stb), és azt betolni az model rétegnek insertre, vagy update-re.
Rosszul gondolkodom-e?
Ezt csak megerősíteni tudom.
Igen, rosszul gondolod.
_Szerintem_ igen. Pusztán
Simán igen, és nem kényelmi,
Egyik oldalról kacag a rossz
Lehet, hogy nekem rosszak az elképzeléseim, de a hazai webáruházaknál szerintem az is nagy forgalom lehet, ha percenként egy-öt lekérés érkezik.
Ilyen körülmények közt az ötven, száz objektum példányosítása (már ami az objektumok okozta overheadet illeti) talán nem okozhat érzékelhető lassulást. Mondjuk az amazonnál már el tudom képzelni, hogy ez valóban komoly gondot jelentene, de ők nem hinném, hogy PHP-re építenek. (bár ki tudja...)
A varázsszó: cache
Van webáruházunk, a frontendet agyon optimalizáltuk és cache-eltük, több helyen "kihagytuk" az ORM-et KÉSŐBB! Nem hiszem, hogy te gyorsabb kódot tudnál írni, mert egyszerűen a cache miatt van, hogy nincs is adatbázis lekérés. (Bár még így is lassú, mert egy szar VPS-en fut jelenleg, viszont a tied sem lenne gyorsabb :D )
Az nem baj, hogy nagyon figyelsz a sebességre, DE sokkal fontosabb, hogy először legyen vmi, és aztán lehet optimalizálni, már ha KELL! Mindig a végén optimalizálunk, okkal. Tökmindegy, milyen gyors lesz a te áruházad, ha az enyém 1 hónappal korábban az ügyfelek ÉS a kereső előtt van, továbbá mire a tied is elkészül, az enyém is van már olyan gyors, ha nem gyorsabb. Egy másik fórumtémában olvastad a keretrendszerese "cikkem"?
Értem, hogy tökre profinak érzed magad, amiért a csordával szemben próbálsz haladni - én is ilyen voltam úgy 8 évvel ezelőt :D -, viszont a programozás nem hülye gyerekeknek van, ha itt elterjed vmi, az azért van, mert működik, nem azért, mert jobb a marketingje.
Nem profinak érzem magam,
Én még úgy tanultam, amikor programozni tanítottak, hogy ami problémát előre látok, azt még fejlesztés közben megpróbálom elkerülni, nem utólag "gányolok" optimalizáció címén. "Finom" célzás -> ha tudom, hogy valami feleslegesen sok CPU-t fog zabálni és problémás lehet, akkor nem hagyom ott azzal, hogy majd utólag optimalizálom.
És bocs, de nagyon sokszor láttam már, hogy a divat itt is előrébb való, mint az észérvek. Hozhatnám példának az elmebeteg CSS-t, az eredetileg a HTML dinamikussá tételére kitalált PHP önálló programnyelvként való kezelését és hasonlókat...
Volt világ OOP előtt is és azt sem merném kijelenteni, hogy rosszabbul mentek a dolgok, amíg mondjuk COBOL-ban kellett fejlesztgetni.
-------------------------------------
Egyébként épp a hozzászólásod erősít meg azon hitemben, hogy ez az egész szimpla divat. Ugyanis ha nem az lenne, akkor nem védenéd te, meg néhány - más fórumról ismert - társad ilyen stílusban. Csakhát amikor elfogynak az érvek, akkor egyszerűbb személyeskedve folytatni, mint gondolkodni. :D
remelem nem bantalak meg de
de egyebkent ha szerinted nem jo OOP-ben fejleszteni, akkor ne tedd. ennyi.
Szeretem, amikor valaki nem
Te is azt csinálod, mint az előtted szóló: érzelmi alapon "érvelsz".
Mitől lenne "széllel szemben", hogy szerintem az OOP szimpla divat, nem több? Ez van, együtt kell vele élni, de ne kezeljük már csodaszerként!
(azt már meg sem említem, hogy hosszú évek óta Java-val dolgozó ex kollégák mit anyáznak a lassúsága miatt... pedig "kicsit" gyorsabb, mint mondjuk egy PHP)
en nem igazan ervelek :).
Igen, erről beszéltem, "nem
Azt meg bocsásd meg nekem, hogy szóváteszem, ha valami nem tetszik...
Igen, mert a weben pont
Azt azért tegyük hozzá, hogy
Egy átlag munkánál, ahol ki kell tenni egy cikket, hozzá pár kapcsolódó terméket, egy fejlécmenüt, láblécmenüt - szerintem nem életbevágó a használata. Talán egy webshopnál sem. Hisz mit csinálsz? Lekérdezel pár dolgot az adatbázisból, kidekorálod, aztán "kinyomtatod". Minek ide zártság meg öröklődés?
+1
Mert később bővíteni kell. És
nem érzelem
Momentán én értetlenül állok néhány weblabor fórumozó azon állandóan jelentkező kényszere előtt, ami miatt minden nap el kell jönnie erre a fórumra, csak hogy közölhesse, hogy mennyire nem jó a web, minden alkotó eleme vacak, és különben is minek akarunk mi ezekkel a szarokkal dolgozni nap mint nap?
Egy csomó dolog van, amit én sem tartok sokra, de pl nem megyek a joomla magyar fórumára, napjában többször, csak hogy kiírhassam magamból mennyire kókányolt, trehány izének tartom.
Mégegszer: Ha nem tetszik az OOP szemlélet, nem tetszenek az OOP keretrendszerek, akkor ne használd! De minket, akik megelégedéssel, hatékonyan tudjuk használni ezeket a rendszereket, légy szíves, ne tarts kevesebbre!
Nem tudom miért nem lehet
Esetemben pl. rá vagyok kényszerülve, hogy PHP-t és MySQL-t használjak, bármennyire nem ez a célom, mert az ingyenes tárhelyeken csak ez van. Szívesebben foglalkoznék mondjuk Java+DB2 párossal (na jó, legyen Oracle, azt valamennyire ismertem), de ez kicsit sokba kerülne. :D
Egyébként nem emlékszem rá, hogy bárki azért járna akár ide, akár más fórumokra (néhány trollt leszámítva, bár olyannal itt még nem találkoztam), hogy elmondja, mennyire szar az adott hely témájául szolgáló technika/eszköz/stb. De engedjétek már meg, hogy akinek negatív véleménye van a dolgokról, az is elmondhassa! Az ilyen reakciókból nekem csak az jön át, hogy "jajj, már megint bántja valaki a szent x.y.-t", ergo érzelmi alapokon viszonyultok a témához.
H.Z. v2 es Hidvégi Gábor
" hogy elmondja, mennyire szar az adott hely témájául szolgáló technika/eszköz/stb. De engedjétek már meg, hogy akinek negatív véleménye van a dolgokról, az is elmondhassa!"
elmondhatod nyugodtan, de az elmult hetekben masrol sem szol a weblabor, mint a te nyavajgasod. bar kellenek ehhez masok is, mert igazabol nincs ertelme hozzaszolni a temaidhoz, es ha nem szolna senki hozza, akkor lassan de biztosan megunnad. vagy jol elbeszelgetnel magaddal
H.Z. v2-nek legalább van
Érveléstechnikailag ez kicsit
gondolom az a gond, hogy nem
vagy csak en latom igy?
Igen, pontosan úgy
Greg nem szólt hozzá a
Na jól van kisfiam, ezt még
Nálam troll listára kerültél.
Hadd engedtessék már egy
Pár hónapja én is pont arra a
AJAX
Divat vs trend
Viszont amiket kiemeltél, az pont nem jó. HTML5 és AJAX tök jó! A kereső csak a forrást látja, és a HTML5-tel például sokkal jobban meg lehet mondani a keresőnek, mi fontos és mi nem. Márpedig a kereső az atyaúristen, mert ha nem talál meg senki, akkor lehetsz akármilyen gyors és jó, nem lesznek ügyfeleid. Az AJAX kicsit túlmisztifikált, megvan a maga területe, most még sokan ott is használják, ahol nem kell, de ez volt a Flash-sel is. Láttam már Flash-es fórumot, használhatatlan is volt :D Hosszú távon viszont ezek szépen lecsengenek, ma már senki nem keres meg minket azzal, hogy legyen minden Flash. A divat röpke pillanat, ami viszont bevált, fejlődni kezd. Az objektumorientált programozás bevált. Az eseménykezelés bevált. A keretrendszerek - PHP, javascript - beváltak. A fejlesztési időt drasztikusan csökkentették, úgy, hogy a hibák száma is csökkent - tapasztalat.
Úgyhogy részben igazad van. De amiről 10 éve jelennek meg könyvek, cikkek, azért kicsit meredek "divatnak" bélyegezni.
a HTML5-tel például sokkal
Új tag-típusok
Igen
Meg tudod mondani, melyek
Igen
Egyértelmű a keresőnek, hogy ami a nav-ban van, az oldalnavigációhoz van, a sectionben lévő elemek pedig fontosabbak, mint az aside-ban lévők. A figure-ban lévő képnél a kereső össze tudja kapcsolni, hogy a képhez konkrétan milyen "tartalmi" rész vonatkozik, tehát azért, mert egy oldalon van egy kép, nem a teljes oldalból és az alt tulajdonságból tudja kikövetkeztetni, mikre keresve kell ezt a képet megmutatni a felhasználónak, hanem sokkal pontosabban be tudja azonosítani. A time is segíthet a keresőnek, hogy a szövegben milyen dátum információk lelhetőek fel, mert egy Citroenről szóló cikkben a 2010 jelenthet térfogatot, szélességet, súlyt és dátumot is. A felhasználó pedig lehet, hogy a 2010-es modelleket keresi, és nem a 2010 kg-os verziókat, esetleg éppen fordítva.
Vagy itt vannak a mikroadatok: http://slides.html5rocks.com/#microdata
Bár nem a keresőhöz tartoznak, de az új input elemek nagyon hasznosak lehetnek admin felületen: http://slides.html5rocks.com/#new-form-types .
A <menu>, <nav>, <header>
A microdata válasz a kérdésemre, viszont magából a HTML 5 szabványtervezetből nem találok rá, csak külön, ha rákeresek. Hol kapcsolódnak ezek?
Akkor ne használd
A te elméleted szerint a h1-h6 is csak erre van, a stronggal és a többivel egyetemben. Ezek szerint neked az lenne előrelépés, ha a HTML5 egyetlen tag-et definiálna, mondjuk <tag> néven és kész. Esetleg még maradhat az <a>, elvégre minden egyéb a dokumentum struktúráját határozza meg. Te ezek szerint még nem olvastál a kereső optimalizálásról.
Ha szerinted teljesen (???) feleslegesek és nem érted, hogy a keresőnek ez miért segítség, hogy részletesebben tudja elemezni a dokumentumot - merthogy egy kereső robot ezt csinálja, elemzi a dokumentumot, és neki baromira nem mindegy, hogy h1 vagy h6-ban van a szöveg, mert tudja, hogy mást jelent -, akkor azzal nem tudok mit kezdeni, ne használd.
Más megközelítésben: 3 dolog "nézi" a forrást: A fejlesztők, a böngészők és a keresők. A középsőt kizárhatjuk, a böngészőknek nyilván teljesen mindegy, hogy <ungabunga> vagy a <title> jelenti a címet. Vmiért igény mutatkozott a továbblépésre, tehát marad az, hogy vagy a fejlesztők, vagy a keresők, esetleg mindkettő miatt lett szemantikusabb - én az utóbbira tippelek. Te fejlesztő vagy, tehát ha miattad csinálták, akkor örülnöd kéne. Ha a keresők miatt, akkor meg ott tartunk, mint az előző.
Esetleg még mondhatjuk azt, hogy a HTML5 valójában visszalépés, és a HTML4-nél volt a csúcspontja, sőt, a Google és a Bing is mindig (???) csak a valóban releváns találatokat jeleníti meg. Akkor örvendezhetünk, hogy szerencsére a legjobb technológiák már most rendelkezésünkre állnak ;)
Esetleg kétségbe vonod a szemantika fontosságát? Akkor nálad tényleg minden <div>-ben van. Megnézzük, hol jön ugyanaz az oldal a keresőben, ha <h1>-et használsz címnél, és akkor, ha <div class="title">-t?
A választ másik témába írtam,
Mint ahogy divat a divattal
Jézusom :D
Keretrendszer használata pro és kontra
After all! What is this no-framework?
Php - ORM rendszerek
Megírtam ezt:
PHP OOP
Ezek után azt mondani, hogy nem érvekkel jövök elő... :D Egyébként ez nem verseny. Szóval ha te nagyon sebességre mész, ajánlom, hogy írd meg C-ben, esetleg írhatnál alá saját webszervert is, az még gyorsabb lenne, vagy saját Linux disztribúció is mehetne. Te láttál dolgokat a bankban, de mit? Te tizen évig bankban dolgoztál, én meg 11-12 éve fejlesztek webre, a weblaboron 9 éve regisztráltam. Írtam saját keretrendszet is, amikor még nem volt. Ja, és Perlben kezdtem, akkor még nem volt PHP, vagy legalábbis nem volt elterjedt. De ha a fentieket végig olvasod, akkor is láthatod, tapasztalatból beszélek. Elméletileg igazad van, lehet ehhez ragaszkodni, de a gyakorlat az én esetemben engem igazolt. Mert pontosan azon a véleményen voltam, mint te, csak okos emberek felhívták a figyelmem néhány dologra. Ezért jó okos emberektől olvasni, vagy mondjuk Meetup-okra járni. Te honnan szerzed a tudásod? Hol mondják azt, amiket te?
Ez üzlet. A startupok nagy része elvérzik. Az ügyféligény menet közben folyamatosan változik. A script nyelvek azért váltak olyan piszkosul sikeressé a webfejlesztés terültén anno, mert C-ben megírni ugyanazt, sokkal tovább tartott, és tart ma is. Sebesség vs fejlesztési idő. Sokkal jobb a CD lemez és a bakelit, mégis mindenki MP3-at hallgat, mert az igények 99%-ra elég. Ettől még igazad lesz, hogy "de hát a bakelitnek jobb a hangminősége". Az ügyfél ezt leszarja. Lehet elméletileg olyanokat kijelenteni, hogy egy ORM-mel 400%-kal lassabb a rendszer, csakhogy ezt a gyakorlat EGYÁLTALÁN nem igazolja. Viszont olyanokat igazol, hogy amit 5 éve 4-6 hónap volt lefejleszteni, ma 1-2. És nem azért, mert gyorsabban gépelnénk. De tényleg nem akarlak meggyőzni, ez nem verseny, meg már írtam eleget ez ügyben. Elméletileg igazad van, te nyertél. Elméletileg.
Maradjunk annyiban, hogy a
Erre céloztam, amikor azt írtam, hogy elfogytak az érvek, jöhet a személyeskedés.
A vita a tudás cseréje, a vitatkozás a tudatlanságé
A stílusért elnézést, de ha vki nagyon határozottan és rugalmatlanul áll ki - szerintem - hülyeségek mellett, miközben 20 másik ember, más-más módon, nagyobb tapasztalattal, érvekkel, hivatkozásokkal felépítve mondja a ellenkezőjét, ott akaratlanul is feltételezem, hogy már nem a logika mentén haladunk, hanem bekavarnak az érzelmek. "Ádáz vitában a felek nem az igazságot védik, hanem saját csalhatatlanságukat."
OK, ha lesz rá energiám,
Félreértések elkerülése végett: nem a tudásodat óhajtottam megkérdőjelezni.
És ha megnézed a többi hozzászólásomat: függetlenül attól, hogy pusztán "divathóbortnak" tartom az OOP-t, momentán én is ennek a tanulásával töltöm szobafogságom heteit... Szóval a "széllel szemben" (nem tudom, te írtad-e - ha nem, akkor bocs) nem igazán állja meg a helyét.
Viszont emlékszem még arra az időre, amikor a strukturált programozást kiáltották ki világmegváltó módszernek és a Chapin kártya volt az üdvözítő tervező eszköz...
(és az ördögtől való a goto! :DDD )
Aztán jött az OOP, de akkor már nem programoztam, viszont még hosszú évekig procedurális programok készültek a környezetemben és nem éreztem lassúbbnak, nehézkesebbnek a programozók munkáját, mint évekkel később, sőt... Jött a java korszak és jöttek a heveny anyázások... Mondjuk ebben benne lehetett az is, hogy hirtelen többet vártak a programozóktól, mint korábban, ezért kevésbé voltak kitesztelve a programok. Ennek legalább tíz-tizenöt éve.
És pár hónapja az egyik java-s exkolléga szidta de nagyon ezt az egész objektum orientál világot. Na az felejthetetlen volt :-)
+1
A file_get_contents() nem
mit szerettel volna
Tyrael
Azt, hogy bármilyen nyelvben
lehet irni, chris viszont azt
azzal en sem ertek egyet, hogy 1-1 kiragadott pelda alapjan kijelentsuk, hogy a pythonban, vagy php-ben ugyanaz a feladat kevesebb sor kodbol megvan.
igaz, hogy a java bizonyos szempontbol kicsit terjengos, de imho sokkal nagyobb, konzisztensebb es jobb minosegu komponensgyujtemeny erheto el javahoz, mint a masik ket felsorolt nyelvhez.
Tyrael
„Premature optimization is
Ezen túlmenően pedig a fősodor objektumorientált szintakszisa olyan elvek nyelvtani formába öntése, amik bármilyen projekt és paradigma esetén követendőek, és csak remélni merem, hogy mondjuk a banki szférában is alkalmazzák őket.
Szolgáltatás–felület–implementáció hármasa, felelősségek, laza csatolás és erős kohézió, kódújrahasznosítás…
Mert ha nem, azt nevezik gányolásnak. Mindenhol.
Továbbra is tartom, hogy az
Szerencsére forráskódokat nem láttam, így nem tudok nyilatkozni. (amit láttam/írtam, annak nem volt forráskódja, ott nehezen lehetett volna bármi "tudományos" módszert követni :-) )
Az OOP-nek melyik az a
Tervezési minták?
Ez az elmélet. Ezen kívül meg ott van 11 év saját tapasztalata, plusz azoké, akik ezeket a módszereket kidolgozták ~20 év alatt.
Leginkább a 11 év saját
Ezt említettem valahol korábban: ha e kettő megvan, szvsz édesmindegy, hogy OOP, procedurális v. egyéb.
Szerintem.
Érdekes amit írsz az
Pont ez az összefüggés lenne az OOP lényege és értelme.
Ez benchmark eredmény vagy hasraütés? Szerintem az utóbbi. Az általános tapasztalat (ami egybeesik a sajátommal) az, hogy PHP 5.3-ban egy objektum példányosítása nem számottevően költségesebb művelet, mint egy asszociatív tömb létrehozása. Párezer objektumpéldány esetén már szignifikánssá válhat a különbség, de PHP webalkalmazásokban ilyesmire azért ritkán van szükség.
Erről jutott eszembe egy érv.
Ugye tudod, hogy vannak olyan
pár éve engem is meghatott az
Nagyon lassan haladok a témával, mert hiányzik a motiváció, de... minél jobban belemászok, annál inkább érzem, hogy a PHP-ben inkább csak dekoráció az objektum orientáltság.
Konkrét példa: összedobtam egy pár soros kódot, ami egy táblázatba szedi az aktuális könyvtár tartalmát. Utána, mivel az OOP mostanság kezd mániámmá válni, átírtam az egészet úgy, ahogy elképzeltem mindezt objektum orientált formában. A feladat méretéből adódóan nem tudom megmondani, a sebességéből mennyit vesztett, de a forráskód mérete jóval nagyobb lett és nem vagyok biztos abban, hogy olvashatóbb lesz, ha pár hónap múlva újra előszedem. Az egyetlen ok amiért ragaszkodom mégis az OOP eszközökhöz, hogy hosszabb távon Java-t + (Python-t v. Ruby-t), + esetleg Scala-t szeretnék tanulni és azokat szeretném használni. PHP-ben inkább erőforrás pazarlásnak tűnik ez az egész, többek közt azért, mert minden oldal letöltés ismételt példányosítással jár.
Persze, ha minden igaz, ugyanez elmondható valamennyi HTML-be ágyazható nyelvről.
és az emberi erőforrás?
én véleményem: a legtöbb modern nyelvben nem objektumorientáltan programozni emberi erőforrás pazarlás.
Az érmének két oldala van, ma nem az a CPU idő, és plusz memória foglalás lesz a pénzkidobás amit épp OOP elvesz, hanem a fizetett programozói órabér.
és ugyan már annyiszor elhangzott itt a weblabor-on is, de azért újra megemlíteném: a szűk keresztmetszet (még PHP-esetében sem) a CPU idő, és a memória igény a hardver-en, hanem az I/O műveletek.
Légy szíves, fejtsd ki,
széllel szemben
A fejlesztők, a nyelvek, és az eszközök egyre jobban az OOP-támogatják.
egy normál projektnél is hány függvényed lesz a globális névtérben? pár száz? ezer? Ami még épp kezelhető. és egy (tényleg) nagy projektben?
és akkor nem beszéltük arról hogy elkezdesz használni valamilyen előre megírt függvénykönyvtárat, ami ha ugyan úgy a globális névtérbe szemetel akkor simán felülírhatják egymást, vagy ha az "függvénykönyvtár" OOP-alapú, akkor keverheted a kettőt a forráskódban.
Persze nem kell ahhoz OOP hogy szép kódot írjunk (pl Gnome), de OOP-tan szerintem (nekem legalábbis) könnyebb.
Megfordítva a kérdést: ugye ti lemértétek hogy mennyit lassít egy OOP?
PHP-ban az osztálynevek is
azert arra kivancsi lennek,
senki nem emlitette meg a szalban, de az OOP nagyon fontos tulajdonsaga, hogy lehetove teszi a osszetartozo adatok es metodusok osszekapcsolasat illetve a belso megvalotas kulvilagtol torteno elfedeset(Encapsulation).
a nevterek segithetnek ezen, de ugye ez proceduralis nyelvekben nem mindenhol elerheto, :
http://en.wikipedia.org/wiki/Namespace_(computer_science)#Emulating_namespaces
a Principle of Least Knowledge is sokkal konyebben megvalosithato es betarthato OOP eszkozokkel, mint nelkule.
szemely szerint esszel hasznalva (nem minden html tag php object az oldalon) egy nagyon hatekony eszkoz.
Tyrael
Nem értem, hogy jön ide, hogy
Mit értesz összetartozó adatok és metódusok összekapcsolásán? Bármilyen erősen típusos nyelv lehetővé teszi ezt a procedurális nyelvtannal is. Gyengén típusos nyelvek esetén marad a konvenció.
A megvalósítás elfedése a procedurális nyelvtannal is lehetséges, amennyiben a szerző megírja a szükséges függvényeket, csakúgy, mint az objektumközpontú szintakszissal. Kikényszeríteni valóban nem lehet, de akkor, amikor majd minden objektumorientált nyelv reflektív, számít ez bármit is? Azonkívül, kitől akarod védeni a kódot? Szinte egyáltalán nem jellemző, hogy külső környezetben fusson. A fejlesztő tartsa magát a konvenciókhoz.
Azzal, hogy ne legyen minden HTML címke objektum, nem értek egyet: szinte minden súlyos biztonsági és használhatósági és rengeteg fejlesztési probléma abból származik, hogy sorosított adatokat kezelnek az alkalmazásaink anélkül, hogy értelmeznék őket. Ha PHP-ban gondot okoz az, hogy egy HTML dokumentumot obejtumhierarchiaként kezeljünk, akkor nem PHP-val kell dolgozni.
Remélem mostanra már tiszta, hogy nem az OOP alapelveinek előnyeit kérdőjelezem meg, hanem, hogy ezen alapelvek egyetlen letéteményese-e a manapság használatos objektumorientált szintakszis.
Mit értesz összetartozó
azt amit az OOP is mond, az osszetartozo adatok es a rajtuk vegezheto muveletek(metodusok) osszefogasanak a lehetoseget.
pl. ANSI C-ben sem tudsz data hidingot csinalni, sem arra nincs lehetoseged, hogy 1-1 libnel(fajl szintunel) kissebb egysegekben osszefoghasd az osszetartozo nagyobb egysegeket.
az eros tipusossag nem latom, hogy hogyan segitene ezen, szoval 1 peldat ha irnal pls.
nem azert akarok data hidingot, hogy ne lassa a masik fejleszto az en kodomat, hanem hogy a boundaryk konyebben lathatoak es betarthatoak legyenek.
egy jol megirt OOP kodbol sokkal egyszerubben ki tudok emelni egy onallo reszt a dependenciaival egyutt, mint egy jol megirt strukturalt kodbol.
azert jo hogy eljutottunk odaig, hogy ami 15 eve a legkenyelmesebb mondja volt a html generalasnak, az ma mar nem alkalmas ra szerinted. :)
hiaba kezeled a kodban fastrukturakent objectekben a html-t, a vegen ugyis vissza kell szerializalnod, amit ha rosszul irsz meg, akkor ugyanugy sebezheto vagy generalhat hibas kodot.
nem tudom, szerintem az igazsag valahol a ketto kozott van, szerintem vannak olyan elemei az OOP-nek, amit az OOP-s eszkoztart hasznalata nelkul nem tudsz megvalositani.
Tyrael
Egy erősen típusos nyelvben
Miért lesz egy procedurális kódban nehezebb tartani magad az adatrejtéshez? Az ökölszabály az, hogy adaton műveletet kizárólag a hozzá definiált függvényeken keresztül végezhetsz.
Nem látom, hogy mitől könnyebb kódot kiemelni az objektumorientált szintakszissal írt projektből, mint a procedurális nyelvtanúból. Sok osztályokkal dolgozó nyelvben (péládul C++) is tudok az osztály törzsén kívül műveleteket megadni, innentől kezdve pont annyira van nyelvtanilag összefogva, mintha függvényeket írnék hozzá.
Az, ami 15 éve a legkényelmesebb, sosem volt a legjobb, attól, hogy kényelmesnek tűnik. Valójában egyáltalán nem kényelmes, már akkor sem, amikor több lépcsőben kell előállítani a kimenetet. Biztonságosabbnak pedig azért biztonságos, mert ha karakterlánc helyett HTML dokumentumként kezeled, akkor csak egyszer kell biztonságosan megírnod (valakiknek megírnia helyetted), míg, ha nem, akkor minden alkalmazásod minden oldalán újraimplementálod a sorosítást. És benne fogsz hagyni biztonsági réseket.
Összegyűjtöd azt, amit nem tudsz megvalósítani a procedurális szintakszissal?
Ha csak az egyik
Az egységbe zártság mellett van olyan tulajdonsága is az OOP-nek, hogy többalakúság és öröklődés.
lásd pl. printf, sprintf, fprintf függvényeket. Itt megvan az egységbe zártság, hurrá. De te mégiscsak a printf függvényt szeretnéd meghívni, de hol a standard kimenetre, hol egy szöveges változóba, hol egy fájlba szeretnél írni. Más a neve a függvénynek, holott ugyanazt csinálja. Más a footprintje is, hisz más "objektumon" dolgozik, de csak azért más. Nem lenne szebb $stream->printf()?
Persze mondhatod, hogy akkor adjuk át a printf-nek a $stream-et mindig és csókolom.
Máris megvalósítottuk procedurálisan azt amit OOP-vel. És akkor itt jön az amit procedurálisan nem fogsz megoldani, méghozzá az, hogy fordítási időben mondd meg, hogy az adott kód az jó lesz-e avagy sem. Az adott stream-re tud-e a printf írni vagy sem.
A fentit procedurálisan csak úgy tudod megoldani, ha típus nélküli változót/mutatót/referenciát adsz át a printf-nek, vagyis sérted az egységbezártság elvét, hogy a többalakúságot elérd. Fordítási időben így nem deríthető ki ez a probléma, csak futásidőben. Ott is csak akkor, ha egy olyan ágra tudod zavarni a programodat ahol az adott probléma előjön.
Arról nem is beszélek, hogy adott esetben kapsz majd egy olyan hibaüzenetet ami nem feltétlenül arról fog szólni, hogy az adott $stream-re nincs implementálva a printf, hanem valami egészen más és furcsa hibaüzeneted lesz. (nem azt írom, hogy nem lehet normális hibakezelést megvalósítani, hanem azt, hogy nem gondolhatsz mindenre)
Egyébként pont egy erősen típusos nyelvben fog előjönni mennyire király is az OOP, amikor az egységbezártságot és a többalakúságot is meg kell egyszerre valósítanod.
A lényeg, hogy meg lehet írni mindent procedurálisan is, csak egy magasabb absztrakciós szintet nem tudsz benne megvalósítani. Vagyis a fordítóba/értelmezőbe beletettek egy csomó olyan dolgot amit egyébként le kéne programoznod, és állandóan értelmezned. (mi ez a sok hülyeség??? áááá ez az izé...)
pp
Végre normális érvek.
Amit leírtál, az a
Az öröklődés hiányát pedig azért tartom ingatagnak, mert a legtöbb nyelv amúgy is csak egyszerű öröklődést támogat; a többszörös öröklésre az egyetlen megoldás a beágyazás, ami pedig procedurális szintakszissal is nagyszerűen megvalósítható.
Örülnék, és megköszönném, ha
pp
C++.
Ezt egy picit kevésnek érzem.
Vagy a "meg lehet oldani", az nem olyan egyszerű és nem is biztos, hogy használható vagy átlátható?
Mert akkor megint ott vagyunk ahol a part szakad.
Én dolgozom olyan kóddal ami OOP szemlélettel van megvalósítva procedurális eszközökkel. De nem érzem azt, hogy olyan könnyedén átlátható lenne mint ha OOP-ben lenne írva az egész. Mivel tanítom is, tudom, hogy pont ezért milyen magas a belépési küszöb és mennyivel lenne alacsonyabb, ha öndokumentáló OOP-s kód lenne, annak ellenére, hogy nagyon jónak tartom a dokumentációját és magát a kódot is.
Szóval én nem vitatom, hogy meg lehet, csak nálam a "lehet"-ben benne van az is, hogy az adott célt elérem-e vele.
Tehát az nem kérdés, hogy az adott absztrakciós szintet el lehet-e érni procedurálisan avagy sem, hanem azt, hogy az adott nyelv az adott absztrakciót biztosítja-e avagy sem.
Amennyiben a nyelv nem biztosítja az adott szintet, akkor neked programozónak minden pillanatban meg kell lépned a transzformációt. Ami egy kis gyakorlással könnyedén megtehető - és már észre se veszed -, de a belépési szintet megemeli.
Régen élveztem, ha olyan kódot tudok írni amit senki se ért rajtam kívül, és még nekem is törnöm kell rajt a fejem, hogy megértsem. Ma már azonban az olyan kód írását érzem kihívásnak amit minél könnyebben érthető bárki számára.
pp
Pontosan mire vársz példát?
Azt már feljebb is írtam, hogy én csak annyit kívántam demonstrálni, hogy jó és rossz kód közt nem az tesz különbséget, hogy melyiket írják a beépített OOP szintakszissal. Ettől még koránt sem biztos, hogy ne volna érdemes ez utóbbit használni, ha elérhető, de azt tudni kell, hogy ha indokolt, akkor a legtöbb dolog nélküle is megvalósítható, vagy legalábbis nem lenne elvi korlátja, a használatának pedig van teljesítményvonzata.
Amit a karbantartható kódról írsz, abban természetesen teljesen igazad van.
Mondjuk a klasszikus példát a
És most a szuperkategóriák(jó/rossz) helyett maradjunk a könnyen értelmezhető/nehezen értelmezhető síkon.
Továbbra is azt mondom, hogy "jó kód"-ság romlik, ha az absztrakciós szintet az OOP nélkül akarod megvalósítani.
OOP-nál a magasabb absztrakciós szint -> könnyen érthető kód -> jobb kód.
OOP-nélkül a magas absztrakciós szint -> nehezen érthető kód -> rosszabb kód.
Abban igazad van, hogy pusztán attól, hogy OOP-t használ valaki nem lesz jó a kód, hisz a jóságnak számos fokmérője van, ráadásul ezek a feladattól, vagyis az elérendő céltól/céloktól függnek.
Azonban ha nézünk két kódot amik többi jóság paramétere és absztrakciós szintje megegyezik, de az egyiket OOP-ben írták a másikat OOP nélkül akkor ez utóbbi kerül ki győztesen a jó kód versenyből.
Legalábbis így gondolom, de könnyen meggyőzhető vagyok egy kódrészlettel, mert mint írtam felül, amit én láttam az pont az ellenkezőjéről győzött meg. (vagyis minden egyéb tulajdonságában kiemelkedő a kód, mégis szebb és jobb lenne, ha OOP-ben lenne)
pp
Szükségtelen, igazad van :)
ez igaz, de a gyakorlatban
Míg egy osztálygyűjteményben jellemzően a osztálygyűjtemény nevével kezdik osztály nevét, és utána jön csak a funció neve. (főleg a PHP esetében, ahol 5.3-ig nem voltak névterek..)
Ha nincsenek névterek, akkor
Légy szíves fejtsd ki, hogy
Már írtam korábban.
Azt hiszem, már másik
Ennyit arról, hogy a CPU nem szűk keresztmetszet. Valamelyik banknak dolgoznak, már nem tudom, melyiknek és nem weblapok készítésével foglalkoznak. A korábbi, közös munkahelyünkön én üzemeltető voltam, de ott sem volt egészen egyértelmű, hogy a proci ne lehetne szűkös, sőt... pedig csak néhány száz felhasználós rendszereket üzemeltettem.
Ami az emberi erőforrásokat illeti, én inkább a divat követésének tudom be, hogy gyorsabb manapság az OOP. Egyszerűen annyi, hogy ezekre készülnek keretrendszerek.
Ha teljesen 0-ról kell valamit összerakni, akkor esélyes, hogy mondjuk PHP-t használva a hagyományos úton gyorsabban készülne el a rendszer és (akár lényegesen) hatékonyabb lenne, mint az objektum orientált. Ha meg nem 0-ról indulsz, akkor csak az a kérdés, hogy a meglévő környezeted mennyire van kiépítve, mennyire ismered a kezedben lévő fejlesztő eszközt.
Ezt most leírtam, de részemről ezzel lezártam a témát.
re
CPU időt tovább én nem vitatom, van itt rendszergazda, vannak itt milliós látogatottságú oldal(akat) üzemeltetők, ők mondják. és hiszek nekik.
Hogy nulláról mennyi idő alatt készül el egy rendszer az egy dolog. Az másik hogy ha a fejlesztő elmegy a cégtől akkor egy új munkatárs mennyi idő alatt fogja átlátni a forráskódot. Egy program teljes életciklusát kell nézni, nem a megírom=>átadom=>leszarom-ból kell kiindulni.
Konkrét példa: összedobtam
FilesystemIterator? :)
Annyiban persze igazad van, hogy egy pár soros scripthez, ami gyakorlatilag nem tartalmaz logikát, teljesen fölösleges az OOP. Ahhoz is, hogy egy MySql lekérdezés eredményét HTML formában megjelenítsd. Egyre több viszont az olyan webalkalmazás, ami ennél sokkal összetettebb logikát igényel, és ahogy nő az alkalmazás bonyolultsága, úgy válnak egyre nyilvánvalóbbá az OOP előnyei.
Ami a teljesítményt illeti: Tapasztalataim szerint sok esetben olyanok aggódnak leginkább a plusz memória- és CPU-igény miatt, akik procedurális kódot írván szemrebbenés nélkül includeolják minden requestnél a 15000+ soros functions.php állományt, akkor is, ha 3 sornyi kódra van szükség belőle :) (##kukac##H.Z. v2: Ez utóbbit ne vedd személyesnek, természetesen nem rólad van szó.)
Hm. Igen, abban a 15000 soros
OOP
Tapasztalatom szerint nem lehet -- az én definícióm, elvárásaim szerint -- szépen programozni PHP környezetben. Ez főként annak köszönhető, hogy a PHP alapvetően statikus HTML dokumentumok előállítására való, mi pedig jellemzően alkalmazásokat akarunk vele írni. Nem erre termett, ennek okán szopás van, ha az ember alkalmazáslogikai megközelítésben akarna vele dolgozni.
Az elmúlt hónapok kísérletezgetései után én azt látom, hogy ha szükségét érzed, akkor adott részeken használj OOP megközelítést (pl. db kezelő megoldás). Itt most konkrétan a nyelv által biztosított OOP megoldásokra gondolok. Mindenáron nem érdemes, főleg nem objektumhegyeket építeni.
Megy itt az eszmecsere, hogy OOP vagy sem. Én azt látom, hogy édesmindegy, hogy mit csinálsz kód szinten. Ha 3/6/12 hónap múlva kérnek egy kisebb funkcióbővítést és azt nagyobb szopás nélkül meg tudod oldani, akkor a rendszer programozástechnikai felépítése kielégítő. Ennél többet, szebbet programozás szintjén lehet elképzelni, felépíteni, de ahogyan látom, sok esetben értelmet energiapazarlás...
Én azt hittem, hogy majd fantasztikusan egyszerű, letisztult, szép megoldásokat tudok alkalmazni a PHP fejlesztés során. Csalódtam, az én elvárásaimnak nem felel meg ez a közeg. Ez a szubjektív véleményem, nem egyéb...
Van tapasztalatod más
Re
Én az elmúlt években fel akartam építeni egy olyan programozási eszköztárat, amivel szépen, tisztán, egyszerűen lehet programozni. Minél többet tudtam meg a WEB technológiai hátteréről annál inkább kiábrándultam ebből a közegből programozói szempontból.
Most már sem kedvem, sem energiám nincsen más programozási nyelvek iránt érdeklődni. Más irányba indulok a közeljövőben, ahol nem kőműves leszek, hanem építész (nem programozás) -- tudom nagyképű kijelentés, de jó oka van annak, hogy így fogalmazok.
Sajnálom, hogy így alakult,
Re
A programozást gyerek korom óta imádom és néhány éve rá kellett jönnöm, hogy nekem ez inkább egy kedves hobbi, mint hivatás. Már tudom mi a hivatásom, így a közeljövőben már ennek szeretnék élni...
Ami a "10 év múlva teljesen más lesz"-t illeti. Ebben én is biztos vagyok. A tekintetben viszont szkeptikus vagyok, hogy jelentős változások lesznek technológiai szemszögből (első körben ki kellene kukázni a HTTP-t, stb-stb.). Ne legyen igazam! Ezt kívánom, mind a WEB-re fejlesztők, mind a WEB-et felhasználók érdekében...
A múlt nem változtatható meg,
Így van
Valóban nem lehet a multat megváltoztatni, de tanulni lehet/kell belőle. Így pedig érthetetlen számomra, hogy a W3C ahelyett, hogy új irányt dolgozna ki, még mindig a HTML-lel, CSS-sel és a browser megközelítéssel tököl. Ez az irány maradhatna egy stagnáló ágnak (amíg elég elterjedt nem lesz az új) és ezerrel dolgozhatnának az új vonalon, ami már akár meg is jelenhetett volna az iPhone, iPad jellegű termékekben. Ezeket az új fejlesztéseket lenne értelme demózni itt-ott (hogy legyen valós feedback a felhasználóktól), nem pedig az eyecandy megoldásokat HTML5 + CSS + JS témában, ami meglátásom szerint szórakozásnak jó, de a WEB érdemi továbbfejlesztésére nem.
Nem láttam az elmúlt években itt a Weblaboron olyan blogmarkokat, amik arról szóltak volna, hogy emberek egy csoportja eszeveszett tempóban dolgozna az új technológiákon, amit pl. a Google és a többi nagy igencsak örömmel fogad és besegítenek a fejlesztésekbe.
Sokkal inkább olvasni a jQuery, az ilyen-olyan framework-ökkel kapcsolatos témákról, no meg arról, hogy a Google, meg a többiek mit-merre-hogyan és miért kellene az ő megoldásaikat használni.
Ha már ott van a Google-nél a Labs részleg (és valószínűleg máshol is, mert itt, ebben az iparágba F+K nélkül nem megy a szekér), akkor igen gyorsan lehetne tolni az új irányt, keresni a kapcsolatot, kellene összedolgozás Facebook, Google, Microsoft, stb. egy közös célért, a jobb WEB-ért. Persze tudom, belelóg a kezem a bilibe, aztán majd felébredek. Nem értem a világot, de nem is akarom már megérteni.
Értem én és hiszek ebben közösségi építés szellemben -- mert vallom, hogy máshogyan nem is lehet --, csak valahogy nem látom ezt visszaköszönni a valóságban, a WEB-es világban.
Én pedig most már úgy gondolom, hogy az IT szép és jó, de elég komolyan üres energia, így inkább más területre koncentrálom hamarosan a bennem lévő tettvágyat...
Minden szavaddal egyetértek,
Re
Működő technológiák
Visszafelé kompatibilitás
Értem én az okfejtésedet és logikus is, egy bizonyos pontig. Én azt gondolnám, hogy az IT világban dolgozó, elhivatott szakemberek azért dolgoznak, hogy egyre jobbat és jobbat alkossanak (ezzel szolgálva másokat).
A visszafelé kompatibilitás egy pont után már csak nyűg és visszafog, és az ilyen húzások is mind arra apellálnak, hogy az elkerülhetetlen váltás dátumát kitolják. Ez nem jó megközelítés, nagyon nem. Ha nem mi, akkor a gyerekeink lesznek kénytelen döntést hozni, de akkor már ki tudja, hogy lesz-e értelme annak a döntésnek, mert akár nagyobb gondok is lehetnek...
Tudom ez a gondolatmenet távolra vezet, de ilyen szinten összefügg minden ebben a világban. Aki ezt nem akarja látni, az igencsak szűklátókörű és legfőképpen felelőtlen. Persze könnyebb az igazságot elkendőzni, mint szembenézni vele, de végső soron csak az utóbbi lehetőség marad. Ha nem mi, akkor a gyerekeink vagy az unokáink lesznek kénytelenek lépni. Valakinek kell, ezt a felelősséget az ember a gondolkodás képességével együtt kapta...
Írod, hogy "amíg a felhasználónak elég". Ennek nem így kell(ene) működnie. Mutatsz egy új irányt, aztán majd kiderül, hogy működik-e. Az IT világban dolgozónak nem a meglévők fenntartása, hanem a folyamatos fejlesztés a dolga...
El kéne odáig jutnia végre a társadalomnak, hogy az önös érdek mellé vagy adott esetben elé helyezi a közösségi érdeket, mert csak ennek révén maradhat fenn a társadalom és ennek révén fejlődhet.
Milyen érdekes, hogy egy IT problémát vissza lehet vezetni társadalmi szintre, igaz?
Az emberek túlnyomó
Egen
Profizmust pedig el kellene
Hányszor találkoztunk már olyannal, hogy
- mert így tudtam megoldani.
Holott a helyes válasz kb. az, hogy
A vezetőség vagy a
Ahogy látom, a vita a
Valóban most már nem
(Bár az egymás letrollozását ennek ellenére eltávolítandónak tekintem, akárcsak ezt az általam indított mellékszálat.)
Megnéztem az adatbázist,
Uncle Bob (Robert C. Martin)
Ha jól veszem ki, 40 éve foglalkozik programozással, nem tudom, hogy ő milyen szakmai tekintély, vagy mennyire lehet adni a szavára, de ha csak véleménynek vesszük, amit mondott (videóban a 23. perc után kb 3 perc hosszan), akkor is érdemes ezen elgondolkodni:
"The OO paradigm is often thought to be `Modeling the real world`... This is complete nonsense... By the way we not modeling the real world, we model the execution of the bunch of instructions inside the computer... What OO gave us is just a simple syntax"
szerintem mindenkeppen
az eloadorol nemi hatterinfo http://en.wikipedia.org/wiki/Robert_Cecil_Martin
erdemes odafigyelni arra amit mond, nem a levegobe beszel.
az OOP kapcsan kulon kiemelte meg a polimorfizmust mint featuret(24. perctol a videoban), es ez az amit, a korabbi paradigmak nem, vagy csak nagyon korulmenyes/error prone modon tudtak megvalositani(fuggvenyekre mutato pointerek).
Tyrael
Azt esetleg érdemes