ugrás a tartalomhoz

PHP OOP

nistvan · 2011. Jún. 19. (V), 11.20
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
 
1

Kipróbálni miért ne tudnád,

H.Z. v2 · 2011. Jún. 19. (V), 11.59
Kipróbálni miért ne tudnád, ha van neted? Bármely free tárhely, ahol 5-ös PHP fut, alkalmas rá.

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. :)
40

Köszönöm a sok választ, látom

nistvan · 2011. Jún. 20. (H), 22.31
Köszönöm a sok választ, látom itt is mindenki más és más szemszögből közelíti meg a dolgokat. Eddig is ezzel találkoztam, ezért is bizonytalanodtam el picit. A hozzászólásokat olvasva pedig úgy gondolom, tényleg az a legjobb megoldás, ha az ember felváltva használja a procedurális és objektum orientált módszereket.

É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.
2

Nemrég volt szó a PHP-ban

Hidvégi Gábor · 2011. Jún. 19. (V), 12.23
Nemrég volt szó a PHP-ban való objektumorientált programozásról a fórumon, de most hirtelen nem találom. A vélemények megoszlanak, de a H.Z. v2 által leírtakat csak megerősíteni tudom, az objektumok megszűnnek, miután az adott oldal (html) kódjának generálása befejeződött. Innentől kezdve szerintem kérdéses, hogy van-e értelme minden hozzászóláshoz egy új objektumot példányosítani, vagy csak egyszerűen a lekérdezés válaszát berakod egy tömbbe és csinálsz belőle html-t.

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.
3

Mondjuk ha ORM-et használ,

Protezis · 2011. Jún. 19. (V), 13.48
Mondjuk ha ORM-et használ, akkor ott létrejönnek a kérdéses objektumok. A singletont meg egyre több helyen mondják anti-patternnek (és tényleg az). Szerintem az ilyen és ehhez hasonló hozzászólások igencsak rossz tanáccsal szolgálnak a kezdőknek.

Á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.
5

A singletont meg egyre több

Hidvégi Gábor · 2011. Jún. 19. (V), 14.23
A singletont meg egyre több helyen mondják anti-patternnek (és tényleg az). Szerintem az ilyen és ehhez hasonló hozzászólások igencsak rossz tanáccsal szolgálnak a kezdőknek.
Ezt kifejthetnéd bővebben. Én azt írtam, hogy a procedurális programozás tökéletesen megfelel (nekem) a webre, ráadásul azt is ugyanolyan jól meg lehet tervezni és implementálni, mint objektumorientáltan.
6

Persze, hogy meg lehet. Csak

Protezis · 2011. Jún. 19. (V), 14.55
Persze, hogy meg lehet. Csak több idő és több rejtett hibát tartalmaz. Nem azért távolodunk egyre inkább a gépi kódtól, mert ez a divat, hanem azért megyünk egyre magasabb absztrakciós szintekre (mi, programozók), mert egyre könnyebb és gyorsabb így a fejlesztés. És bár egyes esetekben ez nem járható út (driverek, stb.), pont a webnél szerintem nagyon is jól működik.

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.
7

Csak több idő és több rejtett

Hidvégi Gábor · 2011. Jún. 19. (V), 15.21
Csak több idő és több rejtett hibát tartalmaz.
Miért?
a webnél szerintem nagyon is jól működik
Miért?

Van egy ingatlanos oldalom, a látogató meg akarja nézni az egyik ingatlant.

$ingatlan = new Ingatlan($_ingatlan);
$szobak_szama = $ingatlan->szobak_szama();
$terulet = $ingatlan->terulet();
...

vagy
$szobak_szama = ingatlan_szobak_szama($_ingatlan);
$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á.
8

A második példád is OOP.

Joó Ádám · 2011. Jún. 19. (V), 15.40
A második példád is OOP.
9

A függvények ott a globális

Hidvégi Gábor · 2011. Jún. 19. (V), 15.44
A függvények ott a globális névtérben vannak.
29

És? Az osztályaid is.

Joó Ádám · 2011. Jún. 20. (H), 11.59
És? Az osztályaid is.
10

A PHP egyik leggyakrabban

kuka · 2011. Jún. 19. (V), 16.46
A PHP egyik leggyakrabban kifogásolt tulajdonsága a függvénynevek és paraméterlisták kavartsága.

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:

$ingatlan = ingatlan_betolt($azonosito);
ingatlan_betolt($azonosito, &$ingatlan);
ingatlan_betolt(&$ingatlan, $azonosito);
$ingatlan = betolt_ingatlan($azonosito);
betolt_ingatlan($azonosito, &$ingatlan);
betolt_ingatlan(&$ingatlan, $azonosito);
Viszont objektum orientált programozás esetén a logikus lehetõségek száma csökken:

$ingatlan = new ingatlan();
$ingatlan->betolt($azonosito);
Megjegyzés, hogy az OOP iránt csak mértékkel rajongok, a webes OOP-ért pedig egyáltalán. A fentiekben csak egy más szempontra szerettem volna rámutatni.
11

funkcionális?

H.Z. v2 · 2011. Jún. 19. (V), 16.53
Nem kötekedésképp, de nem kevered a procedurális programozást a funkcionálissal? ;)
12

Nem kötekedésképp, de nem

kuka · 2011. Jún. 19. (V), 17.04
Nem kötekedésképp, de nem kevered a procedurális programozást a funkcionálissal? ;)
Dehogynem. Természetesen procedurális programozást kellett volna írnom. Köszönöm az észrevételt.
13

Bár a függvények elnevezése

Hidvégi Gábor · 2011. Jún. 19. (V), 17.23
Bár a függvények elnevezése megegyezés kérdése, de ez valóban felfogható előnyként. Emellett megemlíteném az autoloadert, ami szerintem hasznos dolog.
30

Ez csak következetesség

Joó Ádám · 2011. Jún. 20. (H), 12.01
Ez csak következetesség kérdése. A PHP-fejlesztőkre nem jellemző.
38

Az $_ingatlan mi? Id? Mert

Protezis · 2011. Jún. 20. (H), 19.58
Az $_ingatlan mi? Id? Mert akkor gondolom mindkét függvényedben lekérdezed adatbázisból a tényleges rekordot, míg első esetben akkor csak teszed ezt, amikor létrehozod az objektumot.

É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.
39

Ez mind megvalósítás kérdése,

Hidvégi Gábor · 2011. Jún. 20. (H), 20.34
Ez mind megvalósítás kérdése, procedurális programozásnál is meg lehet oldani, hogy csak egy lekérdezés fusson le.
41

Az, hogy a

Joó Ádám · 2011. Jún. 21. (K), 16.31
Az, hogy a perzisztenciarétegből hányszor kérdezel le, tökéletesen független attól, hogy objektumorientált vagy procedurális szintakszist használsz. Abban a változóban egy objektum lesz, bármilyen típussal, ami alkalmas arra, hogy a képviselt entitás állapotát tárolja. Ha skalár, akkor skalár, ha összetett típus, akkor összetett adat.

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.
47

Természetesen tisztában

Protezis · 2011. Júl. 10. (V), 11.42
Természetesen tisztában vagyok azzal, hogy több lekérdezés nélkül is megoldható procedurálisan a probléma: globális változókkal. Valóban nagyon jól átlátható kódot eredményeznek.

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.
48

Nem értem, miért kellenének

Joó Ádám · 2011. Júl. 10. (V), 18.51
Nem értem, miért kellenének ehhez globális változók. Tárolhatod az adatokat asszociatív tömbben, amit átadsz a függvényeknek.

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.
50

Igazad van, tényleg

Protezis · 2011. Júl. 11. (H), 07.59
Igazad van, tényleg megoldható, passzolgatod a függvényeknek a referenciát, mint például a Drupalban. A fejlesztés fele meg azzal megy el, hogy túrod az API-t, hogy mégis milyen kulcsok és értékek vannak/lehetnek abban a tömbben. És bármelyik modul belerondíthat.
51

Semmi közöd hozzá, hogy

Joó Ádám · 2011. Júl. 13. (Sze), 17.46
Semmi közöd hozzá, hogy milyen értékek vannak benne, használd a függvényeket. (De ha lenne is, miben különbözik ez attól, mintha a tulajdonságok/metódusok után túrod az API-t?). A tömb tartalmát kizárólag a szerző kódja használhatja közvetlenül.
52

Nagyon is van közöm hozzá,

Protezis · 2011. Júl. 14. (Cs), 02.03
Nagyon is van közöm hozzá, ugyanis amikor épp hozzáfejlesztek valamit az adott kódhoz, akkor tudnom kell, hogy az adott függvény milyen kulcsokat vár a tömbben. Ezért hivatkoztam a Drupalra: pontosan ismerned kell az összes kulcsot, azok értékeit (hierarchikusan lefelé mindent), és ezekhez teljesen hozzáférsz, korlátlanul módosíthatod őket mindenféle kontroll nélkül. És igen, különbözik a metódusoktól: egyrészt definiálhatod a láthatóságot, másrészt az IDE-k is a kezed alá dolgoznak. Kis túlzással egy ismeretlen, de jól összerakott rendszerben csak a Ctrl+Space-t kell nyomogatni.

Nem tudom, vannak-e ismereteid Java vagy C# nyelvekben. Ott ez még inkább előjön és tapasztalható.
53

Az objektumorientáltság

Joó Ádám · 2011. Júl. 14. (Cs), 15.29
Az objektumorientáltság konzervatívabb iskolái szerint a leszármazott osztály csak bővítheti, nem módosíthatja az ősosztály funkcionalitását. De még ha nem is értesz egyet ezzel a megközelítéssel, a tömbkulcsok pontos ismerete semmiben sem különbözik a privát attribútumok ismeretétől. Ha osztályt akarsz leszármaztatni és felülírni a régi metódusokat, akkor ugyanúgy meg kell nézned a változókat, tehát az érved ismét nem állja meg a helyét. Ha nem kívánsz ezzel foglalkozni, akkor használd a publikus interfészt, vagyis a tömbhöz adott függvényeket. Az IDE támogatásnak sincs elvi korlátja.

Igen, van Java és C# tapasztalatom.
54

Mit nem értesz a dolgon?

Protezis · 2011. Júl. 14. (Cs), 18.50
Mit nem értesz a dolgon? Használni szeretnél egy kódbázist. "A" esetben procedurálisan írt kódot kell használnod: ahhoz, hogy megfelelő paraméterekkel tudd hívni a függvényeket, ismerned kell a tömb paraméterek kulcsait és jelentéseit. "B" esetben nincsenek tömb paraméterek, vagy legalábbis egyszintűek (ténylegesen tömbként használod), helyettük objektumok vannak, itt az IDE alád tolja az összes lehetőséget (látod a többi alap típust, mert annotálva vannak a metódusok, meg type hintet is használtak, ahogy illik), pontosan látod, hogy milyen elérhető metódusokkal dolgozhatsz. A hangsúly azon van, hogy ismered a lehetőségeket. Drupálban ismert tömbös mókánál nyálazhatod az API-t hogy megismerd, mik a lehetőségeid.

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.?
55

Fussunk neki újra. Kérlek,

Joó Ádám · 2011. Júl. 15. (P), 19.00
Fussunk neki újra. Kérlek, vonatkoztass el attól, amit eddig felépítettél magadban, és felejtsd el a Drupalt.

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.
56

A probléma az, hogy a tömb

Protezis · 2011. Júl. 15. (P), 21.17
A probléma az, hogy a tömb értékei nem belső állapotok, azokat kívülről könnyedén, bármikor módosíthatod. Őszintén kérdezem, amikor egy ismeretlen rendszerbe botlasz, én "kidumpolsz" egy tömböt, akkor elkezdesz kutakodni a globális névtérben egy olyan függvény után, ami az elvártaknak megfelelően módosítja a tömb kívánt értékét, vagy kézzel belenyúlsz? A lényeg, hogy mindkét eset működik egészen addig, amíg egy másik művelet nem függ az adott értéktől. Amit az adott függvény mondjuk végrehajt, de te átbarmoltad kézzel a tömböt és nem tudtál róla, hogy más műveletet is végre kell hajtani az adott esetben. Osztályok esetén, ha azok jól vannak megtervezve, nem kell ilyenekkel foglalkoznod. Állítom, hogy először megnézed az osztály felületét, hogy milyen lehetőségek vannak, és próbálod azokat használni. Ez a lényege. Most azon vitázunk, ami egyértelmű, ami egyértelmű előnye az OOP-nek a procedurális programozással szemben, amiért az egészet kitalálták.

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
57

Miért baj, ha feleslegesnek tartja? ;-)

H.Z. v2 · 2011. Júl. 15. (P), 21.55
Nem értelek: PHP nem arra való, hogy a fájlrendszerben matass vele... E célra van rengeteg egyéb nyelv.

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... :-) )
58

Nem erre való? A PHP egy

Protezis · 2011. Júl. 15. (P), 22.27
Nem erre való? A PHP egy script nyelv. Sokszor használom nem webes fejlesztések esetén is. Azért ezt emeltem ki, mert konkrétan ezt már így hallottam más ember szájából (vagyis ő azt mondta, hogy felesleges túlbonyolítás), valamint azért is, mert állásinterjúkon is többnyire csak a "Hallottál már az SPL-ről?" kérdésig jutok el, és a minták, unit tesztek, TDD, DI container, satöbbi csemegék a nemleges válasz miatt elmaradnak. Mondtak már nekem olyat is, hogy neki bizony - "bár nagyképűnek hangzik" - nem nagyon lehet újat mutatni. Mivel nem akartam beégetni, inkább csak a kijáratot mutattam meg.

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.
59

Fene tudja... számomra a PHP

H.Z. v2 · 2011. Júl. 16. (Szo), 07.00
Fene tudja... számomra a PHP nem sokkal több, mint egy HTML kiegészítés. Mert ugye az eredeti célja ez volt. Tudom, hogy másra is használható, de (hülye példa!) a húst sem flex-szel szoktam aprítani... :-)
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?)
60

A konvenciókat minden projekt

Joó Ádám · 2011. Júl. 16. (Szo), 19.23
A konvenciókat minden projekt esetén meg kell ismerni és be kell tartani. Az OOP szintakszis használatával az értelmező valóban szigorúbban ellenőrzi, amit csinálsz, de ez sem garancia, mert reflection van, és ha a PHP annak is számít, más nyelvekben, mint például a Ruby, a metaprogramozás sokkal bevettebb gyakorlat, így a szigorú elvhűség és a varázslat közt sincs éles határvonal. Végső soron csak a megállapodástól függ, mit szabad és mit nem.

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.
61

Ezzel a hozzászólásoddal

Protezis · 2011. Júl. 16. (Szo), 21.18
Ezzel a hozzászólásoddal majdnem teljesen egyetértek, egyedül a "ha az jobban kézre esik valakinek" részt egészíteném ki azzal, hogy: ... és csak egyedül fejleszt, vagy a csapata is hasonlóképpen áll hozzá a kérdéshez. De van egy olyan érzésem, hogy ezt te is így gondoltad.
62

OOP

fchris82 · 2011. Júl. 17. (V), 12.59
A PHP anno nem ismerte az osztályokat és objektumokat, függvények voltak. A php4 óta van ez a képessége. Aztán elkezdtek megjelenni a keretrendszerek, amik nem kis sebesség növekedést hoztak a fejlesztésekben. ÉS! Mind objektumorientált. Nos, a trend elég egyértelmű. Ezek után két eset lehet. Vagy a világ fejlesztőinek nagy része teljesen hülye, hogy ebbe az irányba mennek, vagy te tudsz még nagyon keveset, és ezért kétkedsz.

É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á.


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:
echo $terulet.' m2';
Mivel a területet mindig így iratod ki, ezért ez a kódban előfordul pl 20 helyen. Jön a megrendelői igény, hogy a cég szeretne terjeszkedni, betörnek a Londoni piacra, és ott viszont már négyzet inch-ben IS fel kellene tűntetni az adatokat MINDENHOL!
Amit te tehetsz, hogy szépen, mind a 20 helyen átírod a kódot:
echo $terulet.' m2 ('.($terulet*1550.387).' square inch)';
Nos, ha objektumokban gondolkozol, ez némileg kicsit egyszerűbb. Mindenhova ezt írod:
echo $ingatlan->getFormattedSize();
És amit később átírsz:
public function getFormattedSize()
{
  return $this->getSize().' m2'.;
}
Erre:
public function getFormattedSize()
{
  return $terulet.' m2 ('.($terulet*1550.387).' square inch)';
}
Az objektum orientált programozás átláthatóbb, egyértelműbb, könnyebben bővíthető és fejleszthető, jobban olvasható, logikusabb kódot eredményez. Az öröklődés egy hatalmas plusz.

Hogyan mentesz új sort fv-ekkel?
save_ingatlan($id, $tulaj_id, $cim, $terulet, $created_at, $updated_at);
Ez tök jó is lehetne, csak a paraméterlistát és sorrendet győzd fejben tartani. De mi van, ha csak a területet akarod módosítani, semmi mást nem?
save_ingatlan($ingatlan['id'], $ingatlan['tulaj_id'], $ingatlan['cim'], 40);
ORM-mel szépen átlátható, hogy mi történik:
$ingatlan->setTerulet(40);
$ingatlan->save();
Az objektum majd szépen konvertálja magának az adatokat. Ha pl van olyan, aminek értéke összefügg a terület értékének változásával, VAGY csak megadni lehet, de módosítást le kell tiltani, akkor csupán szerkesztenem kell a setter fv()-et:
public function setTerulet($v)
{
  $current = $this->getTerulet();
  parent::setTerulet($v);

  if($current!=$v)
  {
    $this->log('Megváltozott a terület!');
  }
}

public function setCreatedAt($v)
{
  if(!$this->getCreatedAt())
  {
    parent::setCreatedAt($v);
  }
  $this->securityLog('Vki megpróbálta megváltoztatni a létrehozás dátumát!');
}
Akkor annak szépségeibe még bele se mentem, hogy szeretnél egy felületet, ahol az adatokat különböző paraméterekre szűrve szeretnéd kilistázni. Hogyan rakod össze az SQL-t? Én csináltam ilyet régen, ÉS AGYRÉM! Tele van if-fekkel, próbálkozol olyasmivel, hogy először összerakod a WHERE részt, aztán azt vizsgálva adogatod a join-okat, tele lett hibával és aztán sírás közeli állapotba hozta az embert, ha bővíteni kellett mondjuk. ORM-mel nagyságrendekkel egyszerűbb, ami meg mégsem, ott továbbra is lehet használni raw SQL-t.

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.
63

+1

pkadam · 2011. Júl. 17. (V), 13.18
Ilyen gyakorlatias érvelést még nem olvastam az OOP mellett, pedig egy ideje már foglalkoztat a téma. Engem meggyőzött :)
64

Érdekes amit írsz az

deejayy · 2011. Júl. 18. (H), 07.34
Érdekes amit írsz az összefüggésről a való élet objektumai és a PHP objektumai között.

É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?
65

Ezt csak megerősíteni tudom.

Hidvégi Gábor · 2011. Júl. 18. (H), 07.49
Ezt csak megerősíteni tudom. És emiatt a legtöbb objektumom singleton, sőt, nem is nevezném őket objektumnak, inkább emiatt csak függvénygyűjtemények.
66

Igen, rosszul gondolod.

Protezis · 2011. Júl. 18. (H), 08.03
Igen, rosszul gondolod. Szerinted használna bárki ORM-et, ha 400%-ot lassítana egy fórumoldal listázásakor?
68

_Szerintem_ igen. Pusztán

H.Z. v2 · 2011. Júl. 18. (H), 08.18
_Szerintem_ igen. Pusztán kényelmi szempontok miatt. Csak nem egy alsó kategóriás szervert tolnak a rendszer alá, hanem vesznek egy felső-közép kategóriába tartozót, erős hardverrel.
129

Simán igen, és nem kényelmi,

tgr · 2011. Júl. 20. (Sze), 22.09
Simán igen, és nem kényelmi, hanem gazdaságossági szempontok miatt. Vegyünk mondjuk egy kis startupot egymilliós szerverrel és öt fejlesztővel. Ha áttérnek egy keretrendszerre. ami tízszeresére emeli az erőforrásigényt (forintban mérve) és megduplázza a fejlesztési sebességet, az kilencmilliós kiadás, mondjuk három év alatt amortizálódik el, akkor évi hárommillió. Ha egy fejlesztő keres mondjuk havi 150-et, az a cégnek úgy 300-ban van, az öt fejlesztő együtt évi 18 millió. Ha dupla sebességgel tudnak dolgozni (azaz az eredeti helyzethez képest még öt fejlesztő munkáját megkapja a cég ingyen), az a szerverköltség levonása után évi nettó 15 millió nyereség a cégnek. A számok hasraütésszerűek, de nagyságrendileg stimmelnek: a vas sokkal olcsóbb, mint az ember.
67

Egyik oldalról kacag a rossz

H.Z. v2 · 2011. Júl. 18. (H), 08.16
Egyik oldalról kacag a rossz májam, mert ugye rendszeresen megkapom, hogy túl sokat foglalkozom a proci használattal, másik oldalról...
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...)
69

A varázsszó: cache

fchris82 · 2011. Júl. 18. (H), 15.47
Vannak cache-elési módszerek, használni kell. Egy ORM, egy keretrendszer lassabb, de a fejlesztés benne SOKKAL gyorsabb. Persze miután értesz hozzá.

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.
70

Nem profinak érzem magam,

H.Z. v2 · 2011. Júl. 18. (H), 16.01
Nem profinak érzem magam, csak lehúztam tizenegynehány évet bankban, üzemeltetőként és láttam "érdekes" dolgokat, amik igencsak ellentmondanak a tőletek olvasható véleményeknek.

É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
71

remelem nem bantalak meg de

Greg · 2011. Júl. 18. (H), 16.48
remelem nem bantalak meg de ahogy latom nalad valami gond van. folyamatosan szellel szemben vizelesi kenyszert latok :).
de egyebkent ha szerinted nem jo OOP-ben fejleszteni, akkor ne tedd. ennyi.
74

Szeretem, amikor valaki nem

H.Z. v2 · 2011. Júl. 18. (H), 17.26
Szeretem, amikor valaki nem tud olvasni... De remélem, nem bántalak meg vele.
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)
75

en nem igazan ervelek :).

Greg · 2011. Júl. 18. (H), 17.37
en nem igazan ervelek :). pont azt irtam, hogyha neked nem tetszik ez a megkozelites, akkor nem kell hasznalni. csak azt latom hogy itt egyfolytaban ervelsz a html, az oop, stb ellen. az osszes hozzaszolasod amit olvastam valaminek az ellenzeserol szolt.
77

Igen, erről beszéltem, "nem

H.Z. v2 · 2011. Júl. 18. (H), 17.39
Igen, erről beszéltem, "nem igazán érvelsz" :-)
Azt meg bocsásd meg nekem, hogy szóváteszem, ha valami nem tetszik...
78

Igen, mert a weben pont

Hidvégi Gábor · 2011. Júl. 18. (H), 17.39
Igen, mert a weben pont ezekkel az alapokkal van baj, mint a HTML, a CSS, a HTTP protokoll. Ennyi nem elég?
76

Azt azért tegyük hozzá, hogy

Hidvégi Gábor · 2011. Júl. 18. (H), 17.37
Azt azért tegyük hozzá, hogy más nyelvben lehet haszna az OOP-nek, valamint a Wikipédia cikkében is azt írják, hogy igazából nagy projekteknél jön elő az öröklődés előnye.

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?
85

+1

fchris82 · 2011. Júl. 19. (K), 01.03
Valóban, én nagy projektekről beszélek. Kis projektekre ott a Wordpress, meg a Joomla webshop modulokkal, azokat nem kell külön fejleszteni. Amihez viszont azok kevesek, az már "nagy projekt".
88

Mert később bővíteni kell. És

Joó Ádám · 2011. Júl. 19. (K), 02.35
Mert később bővíteni kell. És már úgyis kész van. Ami meg nincs, azt OOP-ben könnyű modulárisan hozzáadni.
81

nem érzelem

tiku I tikaszvince · 2011. Júl. 18. (H), 20.37
Szerintem itt kevesen vannak, akik valamilyen technika mellett csupán érzelmi indokok mentén teszik le a voksukat.

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!
92

Nem tudom miért nem lehet

H.Z. v2 · 2011. Júl. 19. (K), 06.39
Nem tudom miért nem lehet megérteni: amikor az ember szinte rá van kényszerítve adott tehcnológiák használatára (lásd web), akkor nem nagyon teheti meg, hogy nem tetszik, nem használja.
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.
104

H.Z. v2 es Hidvégi Gábor

Greg · 2011. Júl. 19. (K), 10.12
H.Z. v2 es Hidvégi Gábor IP-jet azert megneznem :). mintha egy es ugyanaz lenne.
" 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
107

H.Z. v2-nek legalább van

Hidvégi Gábor · 2011. Júl. 19. (K), 10.42
H.Z. v2-nek legalább van véleménye, te eddig nem sokat tettél hozzá a dolgokhoz, megnézve az utóbbi hozzászólásaidat.
109

Érveléstechnikailag ez kicsit

fchris82 · 2011. Júl. 19. (K), 11.26
Érveléstechnikailag ez kicsit sántít. Szóval H.Z v2-vel minden oké, mert neki legalább van véleménye. Greg is a véleményét mondta, de az már szerinted viszont probléma. Miért, mert neki más a véleménye?
110

gondolom az a gond, hogy nem

Greg · 2011. Júl. 19. (K), 11.41
gondolom az a gond, hogy nem vitazok vele. es ugyebar a troll fo jellemzoje, hogy szitja a vitat :)
vagy csak en latom igy?
112

Igen, pontosan úgy

H.Z. v2 · 2011. Júl. 19. (K), 11.51
Igen, pontosan úgy viselkedsz, mint egy troll.
113

Greg nem szólt hozzá a

Hidvégi Gábor · 2011. Júl. 19. (K), 11.55
Greg nem szólt hozzá a témához, hanem H. Z. v2-t kritizálta.
111

Na jól van kisfiam, ezt még

H.Z. v2 · 2011. Júl. 19. (K), 11.49
Na jól van kisfiam, ezt még gyakorold egy kicsit.
Nálam troll listára kerültél.
97

Hadd engedtessék már egy

Hidvégi Gábor · 2011. Júl. 19. (K), 08.19
Hadd engedtessék már egy kifejezetten az internettel foglalkozó oldal fórumán elmondani, hogy gondok vannak a webbel, méghozzá alapvetőek. Persze lehet csukott szemmel járni, mint a nagy többség, meg az embernek magában tartani a gondolatait, de attól nem jut előbbre a világ.
73

Pár hónapja én is pont arra a

Hidvégi Gábor · 2011. Júl. 18. (H), 17.21
Pár hónapja én is pont arra a következtetésre jutottam, hogy sajnos a számítástechnikában is mindent a divat határoz meg, nem az észérvek. Egyszerűen az emberek képtelenek megfogalmazni, hogy mire van szükségük, a médiában (beleértve a blogokat) mindenhol azt látják pl., hogy AJAX, meg HTML5, és akkor azt hiszik, hogy nekik hirtelen az kell. Hogy miért - azt már nem tudják megmondani.
82

AJAX

pkadam · 2011. Júl. 18. (H), 22.40
Azért az AJAX előnyei eléggé kézzelfoghatóak és objektívek. Nekem felhasználóként is élményfokozó, hogy nem kell egy lapot újra letölteni, amikor nem akarok elnavigálni, csak egy műveletet végzek. Például, ha nyomok egy "tetszik"-et Facebookon :)
84

Divat vs trend

fchris82 · 2011. Júl. 19. (K), 00.39
Volt ilyen korszak régen, hogy akármilyen ügyfél jött, bemondta, hogy neki kell fórum. A céges weboldalra :D Kérdeztük, miért? Mert a konkurenciának is van! :D Ekkor rendszerint elmagyaráztuk neki, hogy ha senki nem használná, márpedig a konkurenciánál sem használják, akkor tök felesleges. Mi szívesen lefejlesztjük, ki is számlázzuk, csak felesleges.

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.
90

a HTML5-tel például sokkal

Hidvégi Gábor · 2011. Júl. 19. (K), 06.12
a HTML5-tel például sokkal jobban meg lehet mondani a keresőnek, mi fontos és mi nem
Hogyan lehet ezt megtenni HTML5-ben?
91

Új tag-típusok

pkadam · 2011. Júl. 19. (K), 06.23
Szerintem arra gondolt fchris (persze javítson ki, ha tévedek), hogy az új tag-típusok a böngészők számára könnyebben azonosíthatóvá teszik a bennük lévő tartalmat.
98

Igen

fchris82 · 2011. Júl. 19. (K), 08.48
Az új tag típusokkal pontosabban meg lehet határozni, hogy az oldalon mi micsoda, a keresők sokkal több információt kapnak arra vonatkozóan, hogy melyik tartalmi elem milyen funkciókkal rendelkezik.
99

Meg tudod mondani, melyek

Hidvégi Gábor · 2011. Júl. 19. (K), 08.55
Meg tudod mondani, melyek azok az új tag-ek, amelyektől pontosabb találati listát fognak adni a keresők? Például arra az igen egyszerű kérdésre, hogy "hány köbcentis motorja van a Citroen Xsara Picasso 1.6-nak?".
101

Igen

fchris82 · 2011. Júl. 19. (K), 09.48
Innen nézd át: http://slides.html5rocks.com/#semantic-tags-1
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 .
105

A <menu>, <nav>, <header>

Hidvégi Gábor · 2011. Júl. 19. (K), 10.30
A <menu>, <nav>, <header> stb. elemek csak és kizárólag a dokumentum struktúráját definiálják, a keresést nem segítik, és - szerintem emiatt - teljesen feleslegesek. A keresők már most is vannak olyan intelligensek, hogy felismerjék ezeket az elemeket a HTML 4-ben is.

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?
108

Akkor ne használd

fchris82 · 2011. Júl. 19. (K), 11.10
kizárólag a dokumentum struktúráját definiálják

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?
117

A választ másik témába írtam,

Hidvégi Gábor · 2011. Júl. 19. (K), 12.25
A választ másik témába írtam, mert nem tartozik a PHP OOP témakörhöz.
89

Mint ahogy divat a divattal

Joó Ádám · 2011. Júl. 19. (K), 02.37
Mint ahogy divat a divattal szembehelyezkedni is ;)
83

Jézusom :D

fchris82 · 2011. Júl. 19. (K), 00.26
Uhhh. Ajánlottam ezeket:
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.
94

Maradjunk annyiban, hogy a

H.Z. v2 · 2011. Júl. 19. (K), 06.47
Maradjunk annyiban, hogy a személyeskedő, nagyképűsködő szövegeidre régebben sem voltam különösebben vevő, itt meg végképp nem. Ezzel a hozzászólással pl. potyára fárasztottad magad, mert csak a címét voltam hajlandó elolvasni. :D

É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

Erre céloztam, amikor azt írtam, hogy elfogytak az érvek, jöhet a személyeskedés.
100

A vita a tudás cseréje, a vitatkozás a tudatlanságé

fchris82 · 2011. Júl. 19. (K), 09.21
Lépjünk ezen túl felnőtt módjára, és az elején linkelt szakmai tartalomra próbálj meg reagálni légy szíves, ha már azzal jöttél, hogy szerinted elfogytak az érvek. Mutasd meg, hogyan kellett volna ;)

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."
115

OK, ha lesz rá energiám,

H.Z. v2 · 2011. Júl. 19. (K), 12.04
OK, ha lesz rá energiám, elolvasom az érdemi részét is a hozzászólásodnak. Sajnos ahogy öregszem, úgy tűröm egyre nehezebben a khm... kifogásolt stílust, mert egyre kevesebb kedvem van a flame-hez. ;-)

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 :-)
121

+1

fchris82 · 2011. Júl. 19. (K), 23.16
Na, akkor majd folyt köv ;)
É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 :-)
Anno olvastam egy banchmarkról, ahol a Python, Java, PHP nyelvek sebességét hasonlították össze, és belevettek egy olyat is, hogy egy példa oldal elkészítése, melyikben hány karakter és sor. Ott rótták fel a Java-nak, hogy nagyon szép és jól átgondolt nyelv, akár gyors is tud lenni, de ugyanaz Pythonban sokkal kevesebből megvan. PHP-ben a fájl teljes tartalmának beolvasása: file_get_contents(), akár távoli szerverről is lekéri, Java-ban emlékeim szerint az nem ennyi. Bár régen foglalkoztam vele és akkor sem nagyon mélyen. Azt gondolom, az arany középút általában a legjobb. Nyilván nem jó, mindenhol objektumokkal szórakozni, viszont van, ahol elévülhetetlen előnyökkel tud szolgálni.
122

A file_get_contents() nem

Joó Ádám · 2011. Júl. 20. (Sze), 03.33
A file_get_contents() nem nyelvi elem.
127

mit szerettel volna

Tyrael · 2011. Júl. 20. (Sze), 16.47
mit szerettel volna mondani?

Tyrael
130

Azt, hogy bármilyen nyelvben

Joó Ádám · 2011. Júl. 21. (Cs), 03.53
Azt, hogy bármilyen nyelvben lehet írni függvényt, ami egy hívással visszaadja egy állomány tartalmát. Minimum rossz példát hozott.
135

lehet irni, chris viszont azt

Tyrael · 2011. Júl. 21. (Cs), 11.56
lehet irni, chris viszont azt emelte ki, hogy bizonyos nyelv eseteben nem kell, mert resze a beepitett fuggvenyeknek.

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
87

„Premature optimization is

Joó Ádám · 2011. Júl. 19. (K), 02.30
„Premature optimization is the root of all evil.” – Donald Knuth neve remélem ismerősen cseng.

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.
93

Továbbra is tartom, hogy az

H.Z. v2 · 2011. Júl. 19. (K), 06.44
Továbbra is tartom, hogy az előre gondolkodást nem nevezném optimalizálásnak.

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 :-) )
72

Az OOP-nek melyik az a

Hidvégi Gábor · 2011. Júl. 18. (H), 17.17
Az OOP-nek melyik az a tulajdonsága, amitől gyorsabban fogsz programozni?
102

Tervezési minták?

fchris82 · 2011. Júl. 19. (K), 09.59
Tervezési minták? Öröklődés? Keretrendszerek? Az a tudat, hogy eleve objektumokat kell kezelnünk, egyszerűsíti a tervezést, hogy miket is kell leprogramozni, mikkel dolgozunk, miket kell tudniuk.

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.
116

Leginkább a 11 év saját

H.Z. v2 · 2011. Júl. 19. (K), 12.06
Leginkább a 11 év saját tapasztalat és a keretrendszerek léte.
Ezt említettem valahol korábban: ha e kettő megvan, szvsz édesmindegy, hogy OOP, procedurális v. egyéb.
Szerintem.
79

Érdekes amit írsz az

phtamas · 2011. Júl. 18. (H), 17.48
Érdekes amit írsz az összefüggésről a való élet objektumai és a PHP objektumai között.

Pont ez az összefüggés lenne az OOP lényege és értelme.
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.

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.
80

Erről jutott eszembe egy érv.

kuka · 2011. Júl. 18. (H), 19.00
Erről jutott eszembe egy érv. Amiért te nem példányosítasz „kézzel”, azért sok nyelvben lépten-nyomon ott vannak az objektumok. Például Python, Ruby, JavaScript és sok más nyelv esetében a sima számok is objektumok:

>>> 3.14.__class__   
<type 'float'>
>>> 3.14.__str__()   
'3.14'
>>> 3.14.is_integer()
False

irb(main):001:0> 3.14.class
=> Float
irb(main):002:0> 3.14.to_s 
=> "3.14"
irb(main):003:0> 3.14.integer?
=> false

>>> typeof 3.14
"number"
>>> Number.prototype.isInteger=function() { return Math.floor(this)==this }
function()
>>> 3.14.toString()
"3.14"
>>> 3.14.isInteger()
false
>>> 3..isInteger()
true
Tehát azzal, hogy nem csinálsz saját osztályokat még nem biztos, hogy a példányosítások többségét megspórolod.
86

Ugye tudod, hogy vannak olyan

Joó Ádám · 2011. Júl. 19. (K), 02.20
Ugye tudod, hogy vannak olyan nyelvek, amiben minden objektum? Mármint komolyan – leírsz egy számot, és metódust hívsz rajta.
4

pár éve engem is meghatott az

H.Z. v2 · 2011. Jún. 19. (V), 14.01
pár éve engem is meghatott az OOP pártiak ajvékolása


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.
14

és az emberi erőforrás?

solkprog · 2011. Jún. 19. (V), 19.33
te véleményed: PHP-ben objektumorientáltan programozni gépi erőforrás pazarlá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.
15

Légy szíves, fejtsd ki,

Hidvégi Gábor · 2011. Jún. 19. (V), 19.44
Légy szíves, fejtsd ki, milyen tapasztalatok alapján alakult ki ez a véleményed!
19

széllel szemben

solkprog · 2011. Jún. 19. (V), 20.46
2 lehetőséget látok: egyik hogy "széllel szemben pis@lni", és ragaszkodni a procedurális programozáshoz, vagy menni az árral ráhangolódni majd élvezni az OOP-t.
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?
31

PHP-ban az osztálynevek is

Joó Ádám · 2011. Jún. 20. (H), 12.03
PHP-ban az osztálynevek is globális konstansok. Ha két könyvtár üti egymást, ugyanúgy gondban vagy. Mindkét esetben megoldás a névterek használata, az érved innentől semmis.
37

azert arra kivancsi lennek,

Tyrael · 2011. Jún. 20. (H), 16.08
azert arra kivancsi lennek, hogy mennyire jellemzo a proceduralis kodban a nevterek hasznalata, plane PHP-ban, ahol csak az utolso major verzioban kerult be a nyelvbe.

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
42

Nem értem, hogy jön ide, hogy

Joó Ádám · 2011. Jún. 21. (K), 16.47
Nem értem, hogy jön ide, hogy mi jellemző? Az objektumorientált szintakszis egyik feladata a névtér biztosítása. Procedurális szintakszissal vagy használod a nyelvben biztosított névterezési lehetőséget, vagy pedig előtagokat (vagy utótagokat) használsz. Amennyiben a nyelvben nincsenek valódi névterek, az osztályok esetén sem lesz más választásod, mint ez utóbbi.

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.
43

Mit értesz összetartozó

Tyrael · 2011. Jún. 21. (K), 17.33
Mit értesz összetartozó adatok és metódusok összekapcsolásán?

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.

Azonkívül, kitől akarod védeni a kódot? Szinte egyáltalán nem jellemző, hogy külső környezetben fusson.

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.

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.

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.

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.

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
46

Egy erősen típusos nyelvben

Joó Ádám · 2011. Jún. 22. (Sze), 16.02
Egy erősen típusos nyelvben nem tudom ugyanazt a függvényt más típusú argumentummal meghívni, mint amihez írtam. Innentől kezdve az adatok és a műveletek összefogottak.

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?
95

Ha csak az egyik

pp · 2011. Júl. 19. (K), 07.21
Ha csak az egyik tulajdonságot vizsgáljátok, sose juttok dűlőre.

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
96

Végre normális érvek.

Hidvégi Gábor · 2011. Júl. 19. (K), 07.41
Végre normális érvek.
118

Amit leírtál, az a

Joó Ádám · 2011. Júl. 19. (K), 20.17
Amit leírtál, az a legmesszemenőbbekig igaz. Amiért irreleváns, az az, hogy csak C-re igaz, a C pedig nem eléggé típusos, ugyanis a függvény kézjegyének nem része a paraméterlista. Egy olyan nyelvben, amiben az, minden további nélkül megvalósítható volna a többalakúság, hisz a függvények neve mindenhol ugyanaz volna, miközben az egységbezárást is garantálná. Mi sem szomorít el jobban, mint e hiányossága a nyelvnek.

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ó.
120

Örülnék, és megköszönném, ha

pp · 2011. Júl. 19. (K), 20.57
Örülnék, és megköszönném, ha egy konkrét példát is villantanál ezekből a nagyon erősen típusos nyelvekből, amikkel a fenti két dolgot könnyedén meg lehet oldani, mert - valószínűleg hiányos műveltségem okán - az általam ismert erősen típusos nyelveknél a fenti - általad semmisnek minősített - probléma fennáll.

pp
123

C++.

Joó Ádám · 2011. Júl. 20. (Sze), 03.33
C++.
125

Ezt egy picit kevésnek érzem.

pp · 2011. Júl. 20. (Sze), 07.28
Ezt egy picit kevésnek érzem. Továbbra is várom a konkrét példát.

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
133

Pontosan mire vársz példát?

Joó Ádám · 2011. Júl. 21. (Cs), 04.50
Pontosan mire vársz példát? Amire kértél adtam, egyáltalán nem ritkaság a function overloading, amit ellenpéldaként hoztál arra pedig ez megoldás.

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.
134

Mondjuk a klasszikus példát a

pp · 2011. Júl. 21. (Cs), 06.30
Mondjuk a klasszikus példát a ponttal és körrel ahol van egy move eljárás amit csak egyszer a pontnál kell leírni, és a hasonló elemekre ugyan úgy működik. Ebbe benne van az egységbezártság, többalakúság és az öröklődés is.

É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
136

Szükségtelen, igazad van :)

Joó Ádám · 2011. Júl. 21. (Cs), 13.57
Szükségtelen, igazad van :)
44

ez igaz, de a gyakorlatban

solkprog · 2011. Jún. 21. (K), 20.35
Jó persze ez igaz, de a gyakorlatban ha függvényt nevezel akkor azt a funkció neve alapján teszed (legalábbis gondolom). És ez sokszor igaz a letölthető függvénykönyvtárakra is.
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..)
45

Ha nincsenek névterek, akkor

Joó Ádám · 2011. Jún. 22. (Sze), 15.50
Ha nincsenek névterek, akkor a függvény nevét is a könyvtár nevével kezdem. A gyakorlatban.
103

Légy szíves fejtsd ki, hogy

fchris82 · 2011. Júl. 19. (K), 10.03
Légy szíves fejtsd ki, hogy milyen tapasztalatok alapján alakult ki az ellenkező véleményed ;)
106

Már írtam korábban.

Hidvégi Gábor · 2011. Júl. 19. (K), 10.32
16

Azt hiszem, már másik

H.Z. v2 · 2011. Jún. 19. (V), 20.16
Azt hiszem, már másik topic-ban is említettem: egykori kollégák panaszkodtak néhányszor, hogy iszonyatosan lassúak az objektum orientált rendszerek és nem találnak más lehetőséget az optimalizálásra, mint azt, hogy az üzleti logika egy részét átteszik az adatbázisba, tárolt eljárásokba.
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.
20

re

solkprog · 2011. Jún. 19. (V), 20.54
adatbázison belüli művelet jó hogy gyorsabb adatbázison belül mind azon kívül. OOP ide vagy oda.

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.
17

Konkrét példa: összedobtam

phtamas · 2011. Jún. 19. (V), 20.29
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.


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ó.)
18

Hm. Igen, abban a 15000 soros

H.Z. v2 · 2011. Jún. 19. (V), 20.35
Hm. Igen, abban a 15000 soros dologban sok e-gazság van. ;)
21

OOP

Max Logan · 2011. Jún. 20. (H), 09.30
Nos, én az elmúlt bő fél évben többféle megközelítésben készítettem honlapokat, admin felületeket, mini fórumot, üzletkötői rendszert.

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...
22

Van tapasztalatod más

Hidvégi Gábor · 2011. Jún. 20. (H), 09.46
Van tapasztalatod más nyelvekkel?
23

Re

Max Logan · 2011. Jún. 20. (H), 10.02
Nincsen, de itt most a PHP-ről és az OOP témakörről van szó, nem is volt célom semmilyen általnos következtetés levonása.

É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.
24

Sajnálom, hogy így alakult,

Hidvégi Gábor · 2011. Jún. 20. (H), 10.07
Sajnálom, hogy így alakult, sok sikert kívánok az új szakmádhoz! A web nagyon fiatal, s emiatt sok helyen kiforratlan, profizmust én nem várok semmilyen területen. Cserébe nagyon gyorsan fejlődik, és tíz év múlva biztosan teljesen más lesz.
25

Re

Max Logan · 2011. Jún. 20. (H), 10.24
Köszönöm, de nem igazán szakma. :-) Ezért is fogalmaztam ilyen "ködösen".

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...
26

A múlt nem változtatható meg,

Hidvégi Gábor · 2011. Jún. 20. (H), 10.29
A múlt nem változtatható meg, de a jövő igen. Mi vagyunk a webes szakma, hogy mi lesz, csak rajtunk múlik.
27

Így van

Max Logan · 2011. Jún. 20. (H), 11.26
Ez így van, csak én nem tudok mit kezdeni azzal a jelenséggel, hogy a világban tartalmakat megosztó emberek mind a HTML5, CSS3, jQuery és hasonló dolgok okán publikálnak, nem pedig közösséget szerveznek a WEB új technológiai alapjainak létrehozására.

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...
28

Minden szavaddal egyetértek,

Hidvégi Gábor · 2011. Jún. 20. (H), 11.57
Minden szavaddal egyetértek, és már biztos láttad a hasonló hozzászólásaimat itt, a weblaboron. A lehetőség adott, te foglalkoztál már ilyen közösségépítéssel?
32

Re

Max Logan · 2011. Jún. 20. (H), 12.10
Voltak/vannak terveim közösségépítésre. Részben ezzel is szeretnék majd foglalkozni, de elsősorban nem informatikai területen.
33

Működő technológiák

Poetro · 2011. Jún. 20. (H), 12.50
Az a gond, hogy vannak a működő technológiák, amikhez mindenki ragaszkodik. Kiforrottak a rá épülő eszközök és közösség, amit nehéz eldobni valami új miatt. Gondolj csak bele, hogy például, már az ezredforduló előtt tudták, hogy az IPv4 nem lesz képes hosszú távon kielégíteni az igényeket, és hamarosan korlátokba fogunk ütközni, mégsem terjedt el az IPv6, mivel az eszközök, és szoftverek amik az IPv4-re épültek, még elég jók voltak. Ma, amikor már igazából kifogytunk az IPv4 címekből, az eszközök és szoftverek nagyobb hányada, valamint a szolgáltatók jó része még mindig nem támogatja az új szabványt. Szóval ameddig valami működik, és a felhasználóknak elég, addig nem fognak nagyobb lépéseket tenni a szolgáltatók, gyártók és szoftverfejlesztők azért, hogy valami, ami még nem bizonyított átvegye a helyét egy olyannak ami még "működik". Hatalmas nyomást kell gyakorolni ahhoz, hogy ez a váltás bekövetkezzen, valamint kellenek jó demonstrációk, hogy az új működik is (lásd például IPv6 nap).
34

Visszafelé kompatibilitás

Max Logan · 2011. Jún. 20. (H), 13.19
Egyre inkább érzem azt, hogy a visszafelé kompatibilitás olyan szinten fogja vissza az IT világot, hogy az már döbbenet.

É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?
35

Az emberek túlnyomó

Hidvégi Gábor · 2011. Jún. 20. (H), 13.58
Az emberek túlnyomó többségének az az elsődleges célja, hogy eltartsa önmagát és szűk környezetét, a cégekre ez méginkább igaz. Emellett vannak olyan jól fizetett programozók, akik megengedhetik maguknak, hogy nyílt forrású dolgokat fejlesszenek. Továbbá mindenhonnan olyan visszajelzéseket lehet kapni, hogy legyen pénzed, és akkor bármit megkaphatsz. Valóban jóval több embernek kéne felismerni, hogy ha olyat tesz, amitől az ő közösségének jobban fog menni, akkor neki magának is jobb lesz a sorsa.
36

Egen

Max Logan · 2011. Jún. 20. (H), 14.10
Van egy film, melynek címe: A békés harcos útja. Ezen filmben hangzik el az a gondolat, hogy: a legnemesebb feladat a mások szolgálata...
49

Profizmust pedig el kellene

deejayy · 2011. Júl. 10. (V), 19.51
Profizmust pedig el kellene várni bárkitől, tekintet nélkül a szakmára, itt is.

Hányszor találkoztunk már olyannal, hogy
- ezt miért így működik/használható/etc?
- mert így tudtam megoldani.


Holott a helyes válasz kb. az, hogy
- mert az összes többi alternatíva rossz volt /és persze itt logikus érvekkel alátámasztani az állítást/
114

A vezetőség vagy a

kuka · 2011. Júl. 19. (K), 12.02
A vezetőség vagy a társszerkesztők esetleg véget vethetnének a kialakult szardobálásnak, hogy ne alacsonyítsuk a szakmai fórumot a parlament szintjére. Vagy csak én érzem így?
119

Ahogy látom, a vita a

Joó Ádám · 2011. Júl. 19. (K), 20.26
Ahogy látom, a vita a személyes kitérők után visszakanyarodott szakmai vágányra. Effélét pedig – a saját véleményemtől függetlenül – nem kívánok korlátozni. Akit fáraszt, görgesse át.
126

Valóban most már nem

kuka · 2011. Júl. 20. (Sze), 08.54
Valóban most már nem szükséges a közbelépés.

(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.)
132

Megnéztem az adatbázist,

Joó Ádám · 2011. Júl. 21. (Cs), 04.32
Megnéztem az adatbázist, befér még.
124

Uncle Bob (Robert C. Martin)

deejayy · 2011. Júl. 20. (Sze), 07.26
Uncle Bob (Robert C. Martin) előadását pillantottam meg twitteren (http://skillsmatter.com/podcast/agile-testing/bobs-last-language).

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"
128

szerintem mindenkeppen

Tyrael · 2011. Júl. 20. (Sze), 17.54
szerintem mindenkeppen erdemes vegignezni a videot.

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
131

Azt esetleg érdemes

Joó Ádám · 2011. Júl. 21. (Cs), 04.30
Azt esetleg érdemes hozzátenni, hogy amiről OOP kapcsán polimorfizmusként beszélünk, az valójában a hierarchikus típusok bevezetése, ami szükségszerűen magával vonja a kései kötést. Ez valóban olyasmi, ami egyedi, bár procedurális nyelvekben sem volna akadálya a bevezetésének. A típushierarchia, mint olyan, egyébként nem feltétele, elképzelhető egy olyan megoldás is, amiben egy változó több egyenrangú típust tárolhat.