ugrás a tartalomhoz

Ti,hogy értettétek meg az oop-t?

Szita Szilárd · 2013. Már. 22. (P), 19.33
Üdv,már korábban volt egy kérdésem,ahol egy nyelvről kérdeztem és ti nem ajánlottátok a php-t.
Ezért elkezdtem a c# és beleolvastam az oop be,de nem igazán értem.
Ti,hogy értettétek meg az oop-t?
 
1

Az objektumot úgy lehet

Hidvégi Gábor · 2013. Már. 22. (P), 20.26
Az objektumot úgy lehet felfogni, mint egy zenedobozt, amibe bedobsz egy százast, és lejátssza neked azt a zenét, amit kiválasztasz. Hogy ez hogyan történik, az az ő belső ügye (megnézi, hogy jó-e a pénz, amit bedobtál, elindítja a zenét stb.), a lényeg, hogy ő zártan működik, a belső ügyeibe csak korlátozottan avatkozhatsz bele.
2

Thinking in Java

Poetro · 2013. Már. 22. (P), 21.15
Nekem Bruce Eckel: Thinking in Java könyve segített megérteni vagy 15 évvel ezelőtt. És természetesen a fenti könyv Java-ra koncentrál, de a benne lefektetett elmélet más nyelvekre is alkalmazható, maximum a szintaxis lesz különböző.
3

Sajnos

Szita Szilárd · 2013. Már. 23. (Szo), 09.01
Sajnos nem értem meg lehet elmegyek tanárhoz
8

Jó ötlet

Pepita · 2013. Már. 23. (Szo), 22.08
Szerintem legjobb egy megfelelő tanárral kezdeni - bár anno én is könyvből tanultam meg (Delphi 5 mesteri szinten, '97 táján).

Bár tanárok közül is láttam párat, akik tanították, de nem értették.

Olyasmi, mint az autó: van egy csomó tulajdonsága / funkciója, ezek közül van ami kívülről (is) látszik, van ami beleülve sem. Plusz létre lehet hozni az ő mintája alapján al-változatokat is. Vagy egy nagyon jó könyv és / vagy egy jó tanár kell hozzá, sajnos egyiket sem tudok aktuálisan ajánlani.
9

Belenézek

Szita Szilárd · 2013. Már. 23. (Szo), 22.13
Belenézek a Delphi-s könyvbe.
Szerencse angol tudásom eléggé jó koromhoz képest.
Lehet valami angol nyelvű szakirodalom lesz belőle!
Vagy ténylegesen egy tanár!!!!
10

Ha Delphi

Pepita · 2013. Már. 23. (Szo), 22.43
Ha a Delphi-n keresztül gondolod, akkor jó (vagy jobb?) lehet még a Programozzunk Delphi 5 rendszerben, ez valamivel újabb kiadás (2001), és talán nem olyan száraz.

Magát az OOP-t megérteni nem feltétlenül (általad) használt programnyelven keresztül kell, de hasznos.

Szerk.: megnéztem, a D5 mesteri szinten is 2000-es.
4

Én sokat olvastam, és egy idő

inf3rno · 2013. Már. 23. (Szo), 09.03
Én sokat olvastam, és egy idő után összeállt a kép.

Btw. elkezdtem egy cikket ezzel kapcsolatban talán egy hónapja, csak azóta nem tudtam foglalkozni vele. Pont ehhez nyújtott volna segítséget. Konkrétan mivel van problémád? Szerintem el tudjuk magyarázni...

Egyébként szerintem rosszul adják elő az oop-t, legalábbis nagyon logikus, hogy miért alakult ki, de nem úgy magyarázzák el, hanem azzal nyitnak, hogy van és kész, fogadd el... A másik, hogy nem mutatják meg, hogy hogyan kell használni, csak felvázolják, hogy mire van lehetőséged, aztán rád bízzák, hogy használd szabadon. A helyzet viszont az, hogy megvannak az alapelvek, hogy hogyan lehet jó oo kódot írni, és ha valaki ezeket nem tanulja meg, akkor nagyon hosszú idő alatt tudja csak kitapasztalni őket...
5

Példákból tanulok

Szita Szilárd · 2013. Már. 23. (Szo), 12.11
Példákból nagyon könnyen megértem a programozás lényegét most nézegettem direkt egy kicsit a php-t és egy Login scriptre találtam rá.

Alapvetően értettem ami le volt kódolva egy nagyon egyszerű programról van szó.
Tehát a kód állt egy adatbázis kapcsolódásból,adatbázis lekérdezés,hogy létezik az adott felhasználó jelszó páros,kb ennyiből állt a kód.
Na ezt megnéztem oop-ben és egy szót nem értettem belőle.
Addig eljutottam,hogy
class osztaly1 {
 
}
így tudok egy osztályt készíteni.

Akinek van levezetni nekem egy egyszerű php példát oop-ben azt megköszönném.
Ha már felhoztam a belépés témát akkor maradjunk ennél a témánál valami egyszerű ellenőrzés és kapcsolódás azt kész!
6

Nem biztos, hogy jobb az

inf3rno · 2013. Már. 23. (Szo), 14.50
Nem biztos, hogy jobb az egyszerű példa. Az OOP előnyei akkor jönnek elő, amikor bonyolódik a helyzet, és struktúrális programozással már kezd átláthatatlanná válni... Majd írok valamit mindjárt, csak előbb megkajálok...
7

:)

Szita Szilárd · 2013. Már. 23. (Szo), 16.07
Rendben
11

Na ez elfelejtődött. Az oop

inf3rno · 2013. Már. 23. (Szo), 22.48
Na ez elfelejtődött.

Az oop úgy működik, hogy először tervezel egy interface-t az alkalmazásodnak, aztán utána az alapján lefejleszted TDD-vel, amit akarsz bizonyos szabályokat betartva. Leginkább SRP-re érdemes odafigyelni, ami azt jelenti, hogy egy osztály csak egy dolgot csinálhat. Ha kéréseket intézel egy szerver felé, és betartod az SRP-t, akkor elég hamar kialakulnak rétegek. Ez azt jelenti, hogy lesz egy csomó olyan osztályod, ami hasonló dolgokat csinál, ezért ők egy rétegbe kerülnek. A rétegen belül meg a hasonló kódjukat újra lehet hasznosítani.

Nézzük a bejelentkezést. Vegyük nagyon egyszerűre a figurát, csak jelszót kell megadni, és admin jogot kapsz, ha eltalálod a jelszót, az admin joggal pedig képes vagy felülírni a régi jelszót. Kell még egy kijelentkezés gomb. Ez 3 oldal: login, logout, profile. A login saját magának küldi a jelszót, és siker esetén a profile-ra irányít. A profile saját magának küldi az új jelszót módosításkor. A logout a profile oldalon van, törli az admin jogot és a login-re irányít. Csinálok két git repo-t, az egyikben megírom struktúrálisan, aztán refaktorálom OOP-re, a másikban meg TDD-vel csinálom majd. A design meg minimál lesz, css nélküli table + html4. Kíváncsi vagyok mi jön ki belőle...
12

Úhh

Szita Szilárd · 2013. Már. 24. (V), 08.24
Úhh ez így bonyolultabb mint ami a könyvben van!
Úristen egy szót nem értek belőle :) TDD SPR
14

Látszik :)

H.Z. · 2013. Már. 24. (V), 09.36
Látszik :)
Mert még rosszul is írtad:
SPR helyett SRP = Single Responsibility Principle
TDD = Test Driven Development

Az elsőt keresd úgy, hogy "S.O.L.I.D. Robert C. Martin" (Ebből az S.=SRP)
A TDD az egy fejlesztési módszer, szerintem nem kellett volna belekeverni a témába.

Egyébként én úgy gondolom, az OOP egy annyira tág és bonyolult témakör, hogy így elég macerás megtanulni. Különösen, mikor az ember úgy érzi, hogy valamennyit már felfogott belőle és elkezd mélyebben turkálni a témában. És rájön, hogy sokan, sokféleképp magyarázzák/ültetik át a gyakorlatba ezeket az elveket. Főleg ez utóbbi miatt jó, ha van egy oktatód, mert akkor nem kavar meg, ha a neten kétféle magyarázatot találsz ugyanarra a témára.
Én a D, mint DIP, alias Dependency Inversion Principle kapcsán futottam előszöt ilyesmibe, mert nagyon nem értettem - azóta sem igazán, de ez más kérdés :) - és sok helyen, sokféleképp magyarázták. Volt ahol egyenlőségjelet tettek a Dependency Injection és a DIP közé, pedig ez így nem teljesen igaz.
A másik ilyen kedvencem az MVC (Model View Controller) gyakorlati megvalósítása. E téren is találkoztam sokféle véleménnyel és mind hihetőnek, elfogadhatónak tűnt...
Végül feladtam. :)
18

Nem is kell még

BlaZe · 2013. Már. 24. (V), 10.23
Én azt gondolom, hogy ezekből egyelőre nem is fontos értened bármit. Ezek akkor hasznos dolgok, amikor már production rendszert készítesz. Amíg a programozás alapjait tanulod, addig semmi szükség ilyesmire, mert csak összezavar és nem fogsz érteni semmit. Én ezt igaznak érzem az OOP-re is. Tanuld meg mi az, hogy változó, mi egy változó élettartama, változó scope, tanuld meg a vezérlési- (elágazások, ciklusok típusai) és adatszerkezeteket (vermek, sorok, listák stb), tanulj meg alapszinten algoritmusokat írni, és utána arra építkezve jöhetnek ezek a dolgok, mint pl az OOP alappillérei, miért jó, mire használjuk, mi az az objektum egyáltalán, mi a különbség az objektum, a class, az interface között és ezt egyre mélyebben. Ha ez megy, akkor jöhet majd a SOLID, design patternek és a többi high-level nyalánkság, amit inf3rno írt. De előbb rendezz tömböt, keress benne, számolj heti átlaghőmérsékletet stb. A klasszikus alap algoritmusok. Hidd el, hogy jobban jársz, ha lentről építkezel, nem egyből csillagrombolót akarsz gyártani. Mert ha akkor kell visszanyúlni a tök alapokhoz, amikor már úgy érzed, hogy tudsz programozni, az nagyon demotiváló.

A tanár sem buta dolog, de egy jó könyvvel se jársz rosszul, az mindig kéznél van, és ha elakadsz, pl itt is tudunk segíteni. Én ezeket ajánlom konkrétan:
Programozás tankönyv I.
Programozás tankönyv II.
http://www.kiskapu.hu/index.php?BODY=BookInfo&OP=details&ID=5516&VISIT=1

Tanár írta, tapasztalatom szerint nagyon jó bevezető könyvek.

Ezt nem ismerem, de első blikkre szintén érdekesnek tűnik:
A C# programozási nyelv a felsőoktatásban
Programozás tankönyv
Ha a C#-ot választottad, érdemes ezt is megnézni szerintem.
36

https://github.com/inf3rno/we

inf3rno · 2013. Már. 24. (V), 15.47
https://github.com/inf3rno/weblabor-forum-115535-strukturalt

Felszórtam ide. Nem csináltam TDD-s példát, struktúráltat csináltam, aztán azt alakítgattam át oops formára szép lassan, hogy érthető legyen mi miért történik. Lehet így sem, az de mindegy. :D A readme.md fájl folyamatosan változik, abban van benne, hogy éppen mit csinálok.
43

ez igen

zzrek · 2013. Már. 24. (V), 21.59
Csak épp belepislantottam abba amit csináltál (tehát nem az elkészült anyag minőségét értékelem, mert bár bizonyára az is kiváló, de most nem ezt akarom hangsúlyozni), az az érzésem támadt, hogy ez a fickó igencsak elhivatott, termelékeny és céltudatos (amellett, hogy segítőkész). Elismerésem! Csak ezt akartam mondani.
44

Csatlakozom

Pepita · 2013. Már. 24. (V), 23.24
az előttem szólóhoz!
45

Ja, ez már beteges,

inf3rno · 2013. Már. 25. (H), 05.06
Ja, ez már beteges, végignéztem a commit listát, egyfolytában ment 12 órát :D

Egyébként egy struktúráltan megírt oldalt soha nem szabad oopsre alakítani, mert hónapokat el lehet tölteni vele, és nagyon könnyen eltörik úgy, hogy nincsenek tesztek hozzá. Ha ilyesmibe futtok bele, akkor vagy ne vállaljátok, vagy nulláról írjátok újra az egészet, úgy sokkal gyorsabban megvan. Most csak a példa kedvéért követtem el ilyet...

Majd a TDD-s változatot is megcsinálom, kíváncsi vagyok, hogy az bizonyítja e a fenti állítást, és időben hogy fogok kijönni vele. Valószínűleg a kód minősége annál sokkal jobb lesz, mert tervezett lesz, viszont ugyanazt a fos html-t fogom gyártani hozzá... :D
54

OOP?

Hidvégi Gábor · 2014. Szep. 30. (K), 15.10
A végső OOP-s megoldás 15 kilobájt és 27 fájlból áll. Minden modulja cserélhető (munkamenet, állandó tár kezelése, hasítékfüggvény stb.), minden érték változóból jön. Ez nyilván ott előny, ahol szükség van a különböző részek cseréjére, mert nem elégedettek valamelyikkel, vagy pedig több módszert használnak.

A kérdés, amit fel kell tennünk, mielőtt bármibe belekezdünk, hogy szükségünk van-e ilyen mértékű rugalmasságra és absztrakcióra? Várható az, hogy másik profilmenedzsert építünk be? Valóban egy rendszeren belül egyszerre több hasítékfüggvény használatára van szükség?

Ha megnézzük a procedurális verzió egyik utolsó változatának tools.php-ját, 3,3 kilobájt, aminek az első fele (1,5 kb) tartalmaz minden, a működéshez szükséges kódot, a második felében a HTML sablonok vannak.

Amik ezek után felmerülhetnek:
- Az OOP változatban legalább ötször annyi kód van, ötször annyi hibázási lehetőséggel és jóval nagyobb memóriaigénnyel,
- A procedurális kódban van egy "workflow" (egy fájlban), azaz egy végignézés után pontosan tudni fogjuk, mi hogyan működik,
- Az OOP kódban ugyanez huszonhét fájlba van szétdarabolva, és a megértéshez jóval több időre és egy IDE-re van szükség,
- A php munkamenetkezelője függvényeinek lecserélésére van beépített módszer, így annak objektumorientált kezelése fölöslegesnek látszik.

Úgy gondolom, hogy ennél a példánál az OOP-t használni az nagyjából olyan, mintha Nehéz Gusztival mennénk amőbára. Több idő a lefejlesztés, a karbantartás, az átlátáshoz szükséges idő, és a megértéshez szükséges képzettség. A procedurális változat érzésem szerint a cégek túlnyomó többségének bőven elég, de ha mégis valamelyik belső "modulból" egy újabbra lenne szükség, akkor egy if/elseif ággal meg lehetne oldani.

Ez alapján ez a példa inkább annak a bemutatására jó, hogy mikor ne használjunk OOP-t (hisz jelen esetben többet árt, mint használ), és jogosan merülhet fel az a kérdés, hogy hol van az a szint, ahol (egyáltalán) érdemes rá áttérni.
56

Nekem ennek a projektnek a

inf3rno · 2014. Szep. 30. (K), 19.18
Nekem ennek a projektnek a következőek voltak a tanulságai:

- A procedurális változatnak megvannak a maga korlátai. Bizonyos méret felett egyre kényelmetlenebbé vált a használata, és egyre valószínűbb volt, hogy valamit elhibázok. Leginkább a hibakezelés volt az, amit nehéz nyomonkövetni, hogy minden rendben van e vele, mert több fájlra szét van osztva if-else ágakra ahelyett, hogy összefüggő kód blokkokban szerepelt volna. Lehetséges, hogy rosszul volt szervezve a kód ilyen szempontból. Esetleg ha van ötleted, hogy hogyan lehetett volna jobbra megcsinálni, akkor nyugodtan hozz létre egy külön ágat neki, és küldj pull request-et.

- Egy procedurális kód refaktorálása hasonló idő volt, mint nulláról újraírni az egészet OO alapon. Szóval ha van egy bármilyen méretű procedurálisan megírt projekt, akkor még jó minőségű kódnál sem éri meg OO-ra refaktorálni. Sokkal kényelmesebb átgondolni, hogy mire van szükség, és nulláról újraírni az egészet, ha OO kódra van szükség a továbblépéshez. (Közben tanultam néhány új technikát DDD-vel kapcsolatban, és talán lehetséges egy anti-corruption layer-el elfedni még az ilyen kódot is. Ebben egyelőre nincs tapasztalatom.)

- Érdemes keretrendszereket használni, mert jelentősen meggyorsítják a fejlesztési időt. Ez még talán úgyis igaz lehet, ha az embernek menet közben kell megtanulni a használatukat. (Keretrendszer választásnál nyilván érdemes ellenőrizni a kód minőségét, a közösség méretét, és hogy mennyire pörög a support.)
57

Szerintem jól átlátható a

Hidvégi Gábor · 2014. Szep. 30. (K), 19.34
Szerintem jól átlátható a procedurális kódod, a hibakezelést viszont úgy oldottam volna meg, hogy hibakódokat adok vissza minden esetben. Ez amiatt is jobb, mert könnyen lehet fordítani.

Akkor tartanék szükségesnek egy refaktorálást, ha már túl sok az if, de ez csak akkor fordulhat elő, ha évekig csak hízik a kód a sok új kéréstől.
58

Nem csak évek múlva

Pepita · 2014. Szep. 30. (K), 19.53
Nem kell fél év sem a túl sok if-hez.
Persze kinek mennyi a sok.
Viszont akkor már túl késő, jobb eleve úgy nekiindulni, hogy bármeddig továbbfejleszthető legyen a kód.
Emiatt nagyon egyetértek inf3rnoval a keretrendszert illetően.
59

Az OOP változatban legalább

inf3rno · 2014. Szep. 30. (K), 20.17
Az OOP változatban legalább ötször annyi kód van, ötször annyi hibázási lehetőséggel és jóval nagyobb memóriaigénnyel,


Ezek mérési adatok, vagy fogadjam el bemondásra?

Személy szerint eddig csak olyan procedurális kódokkal találkoztam, amik rossz minőségűek voltak, nem voltak hozzájuk tesztek, és tele voltak hibákkal. Ahhoz, hogy egy kódnál alacsony legyen a hibázási lehetőség az automatikus tesztek elengedhetetlenek. Biztosan lehetséges valahogy procedurális kódot felelősségi körök szerint szervezni, és automatikus teszteket futtatni rajta, nem folytam bele túlzottan ebbe a témába, de személy szerint én eddig semmi ilyesmivel nem találkoztam.

A procedurális kódban van egy "workflow" (egy fájlban), azaz egy végignézés után pontosan tudni fogjuk, mi hogyan működik,


Semmi akadálya, hogy az osztályokat összeszedd egyetlen fájlba, és akkor ott is lesz egy "workflow". Én személy szerint nem szeretem ezt a fajta kód szervezést, mert nehezen karbantartható kódot eredményez.

Az OOP kódban ugyanez huszonhét fájlba van szétdarabolva, és a megértéshez jóval több időre és egy IDE-re van szükség,


Általában a keretrendszereknek van egy fix projekt struktúrájuk. Ha azzal tisztában vagy, akkor nem szükséges jóval több idő, hogy eligazodj egy projektben. IDE-re nincs szükség a kód olvasáshoz, én pl github-ról nagyon jól meg tudok érteni kódokat az osztály-, metódus- és változónevek olvasgatásával. Általában nem szoktam 4-5 fájlnál többe belenézni, ha kíváncsi vagyok valamire. Az a tapasztalatom, hogy már egy 1000 soros fájlnál is jóval kényelmetlenebb ctrl+f-el keresgélni. A backbone pl egy jó példa arra, hogy hogyan lehet rosszul szervezett kódot csinálni, pedig nincs benne 10-nél több osztály szerintem.

A php munkamenetkezelője függvényeinek lecserélésére van beépített módszer, így annak objektumorientált kezelése fölöslegesnek látszik.


Lehet, hogy az, fogalmam sincsen. Régóta nem foglalkoztam a témával.

Több idő a lefejlesztés, a karbantartás, az átlátáshoz szükséges idő, és a megértéshez szükséges képzettség.


Nem tudom, hogy ezeket milyen adatok alapján írod, nekem teljesen ellentétesek a tapasztalataim. Nem hinném, hogy egy ilyen egyszerű projekt esetében céleszközök használatával bármilyen időkülönbség lenne. A procedurális kód megírása 5 óra volt, ezzel szemben keretrendszerrel 2 óra alatt megvolt az OO kód. Valószínűleg ha valamilyen procedurális keretrendszerrel (már ha van ilyen) futok neki, akkor ugyanennyi időbe telt volna. A karbantartással és az átlátási idővel kapcsolatban nehéz állást foglalni, mivel még sosem találkoztam jó minőségű procedurális kóddal. A spagetti kódokat rémálom karbantartani, aminek általában két oka volt, az egyik a gyenge átláthatóság, a másik, hogy tesztek nélkül kellett módosítanom egy egyébként is bugokkal teli kódot. A megértéshez szükséges képzettséggel nincs tapasztalatom, sosem próbáltam tanítani. Nekem az a véleményem, hogy jó minőségű procedurális kód írásához jóval magasabb szintű képzettség kell, mint hasonló minőségű OO kód írásához. Legalábbis jóval kevesebb a procedurális kódok fejlesztéséhez rendelkezésre álló eszközök száma.

A procedurális változat érzésem szerint a cégek túlnyomó többségének bőven elég, de ha mégis valamelyik belső "modulból" egy újabbra lenne szükség, akkor egy if/elseif ággal meg lehetne oldani.


Nyilván a cégek az olcsó humán erőforrást keresik, és ahhoz, hogy gyenge minőségű procedurális kódot írjon valaki kevesebb képzettség szükséges, mint ahhoz, hogy gyenge minőségű OO kódot írjon valaki. Szóval egyet tudok érteni azzal, hogy a cégek többségének tényleg elég.
60

»Az OOP változatban legalább

Hidvégi Gábor · 2014. Szep. 30. (K), 21.43
»Az OOP változatban legalább ötször annyi kód van, ötször annyi hibázási lehetőséggel és jóval nagyobb memóriaigénnyel,«

Ezek mérési adatok, vagy fogadjam el bemondásra?
Szimpla matek. A procedurális változatban a lényegi kódrész 1,5 kilobájt, a HTML sablonok 1,8. Ha az OOP 15 kilobájtjából kivonjuk ezek összegét, akkor megkapjuk az OOP overhead-jét, ami 15 - 3,3 = 11,7. 11,7 / 1,5 = 7,8, így nem ötször, hanem majdnem nyolszor annyi az OOP kód. Még jó, hogy az ötöt szkeptikusan fogadtad : )

Ahhoz, hogy egy kódnál alacsony legyen a hibázási lehetőség az automatikus tesztek elengedhetetlenek.
Vigyázz, most nagyot fogok mondani: szerintem a tesztek csak annak a bizonyítékai, hogy a programozó nem látja át a kódot, és nem tudja, hogy egy változás milyen következényekkel fog járni, mit fog eltörni. Én szóltam : )

Semmi akadálya, hogy az osztályokat összeszedd egyetlen fájlba, és akkor ott is lesz egy "workflow".
Szerintem a procedurális kódod azért átláthatóbb, mert két darab függvényt regényszerűen végigolvasva pontos képet kapunk a működésről. Az OOP kódban ugyanez 27 fájlra van szétbontva – ezen sokat nem változtatna, ha egy fájlban lenne, mert ugyanúgy ugrálni kéne a metódusok között.

»Több idő a lefejlesztés, a karbantartás, az átlátáshoz szükséges idő, és a megértéshez szükséges képzettség.«

Nem tudom, hogy ezeket milyen adatok alapján írod, nekem teljesen ellentétesek a tapasztalataim.
Pedig írtam is, de te is megnézheted. OOP kód: 15kb, 27 fájl, procedurális kód: 3,3kb, 1 fájl. Mindkettőben bruttó 70 sor a lényegi rész, ami a munkát végzi.

A procedurális kód megírása 5 óra volt, ezzel szemben keretrendszerrel 2 óra alatt megvolt az OO kód.
Azt ne felejtsd el, hogy a programlogika már megvolt akkor, mire az OO-t elkezdted, tehát csak kódszervezés volt az a két óra. Viszont valami nem stimmel, mert egy akkori bejegyzésedben még 12 órát említesz.
61

Még mindig itt tartunk?

T.G · 2014. Szep. 30. (K), 21.55
Ezeknek a bejegyzéseknek a provokáláson kívül van bármi érdemi célja? (ha legalább Adsense lenne a Weblaboron, de így?)

Miért van az, hogy a Weblabor ma egyenlő azzal, hogy mit miért ne használjak?
72

Még mindig

Hidvégi Gábor · 2014. Okt. 1. (Sze), 08.54
A célom az, hogy az emberek tegyenek fel kérdéseket, mielőtt döntést hoznak, és ismerjenek meg minél több lehetőséget, hogy ezeket a kérdéseket fel tudják tenni.

Ha nem ismered egy paradigma/eszköz/nyelv hátrányait, akkor hogyan fogod tudni kiválasztani a megfelelőt az adott probléma megoldásához?
83

Komolyan?

T.G · 2014. Okt. 1. (Sze), 13.49
Ez támogatandó lenne, ha tényleg erről lenne szó. Ellenben én az elmúlt néhány évben csak annyit látok, hogy Weblabor-on állandóan az a téma, hogy nehogy valami újítást használjunk, mert azt lehet rosszul is használni. Inkább ne újíts, abból nem lesz bajod!

Számomra az OOP az elmúlt tízen-évben bizonyított, tényleg értelmetlennek érzem ma azt bizonygatni, hogy miért lenne érdemes visszatérni az OOP előtti paradigmákra. Mert a Weblabor nem arról szól, hogy az ismert problémák okán, hogyan lépjünk tovább, hanem arról, hogy mit miért ne használjunk. Én nem látom azokat a kérdéseket, amelyek előrébb vinnének minket.

Hosszan kellene gondolkodnom, ha még egy ilyen innováció ellenes szakportált kellene mondanom. De nincs kizárva, hogy nincs is ilyen.
85

+1

bamegakapa · 2014. Okt. 1. (Sze), 14.28
Az a legunalmasabb benne, hogy periodikus. Az OOP már tényleg "rég" került sorra...

Ami a Weblabort illeti, kikopott már szinte mindenki innen, amennyire én látom. Gyakorlatilag Gábor a legaktívabb az oldalon, ő a Weblabor hangja manapság, őt meg ez foglalkoztatja.

Egyébként volt egy téma arról, hogy mi is ma a Weblabor, mi akar lenni, illetve hogy egy szellemváros az egész, meg is lett beszélve egy Nagy Találkozó, amire sokan mentek is volna, aztán az is elhalt.

Hogy a blogmarkokban mostanában gyakran megjelenő olcsó címadási gyakorlattal éljek:

Is Weblabor dead?
103

+1 +1

Pepita · 2014. Okt. 1. (Sze), 18.42
Is Weblabor dead?
Pedig nagy kár lenne.

Viszont jelenleg elsősorban Ádámon múlik, hogy mi lesz, lesz-e "Nagy Találkozó" (és mikor...).
86

Fentebb számokkal

Hidvégi Gábor · 2014. Okt. 1. (Sze), 14.29
Fentebb számokkal bizonyítottam, hogy van olyan helyzet (mint például az inf3rno által két módszerrel megírt login script is), ahol a procedurális kód minden tekintetben előnyösebb az OOP-nél.

Én készséggel elhiszem, hogy te az utóbbi tizen-évben olyan munkákon dolgoztál, ahol szükség volt az OOP eszközei által biztosított rugalmasság. Csak az a helyzet, hogy ez rajtad kívül senkit sem érdekel. Mint ahogy az sem érdekel az égvilágon senkit, hogy nekem nem tetszik az OOP, és procedurálisan dolgozom ugyanennyi ideje minden gond nélkül. És akkor tegyük mellé a funkcionális programozást is, mert van, akinek meg az működik.

Viszont az, ami érdekelhet másokat, az az, hogy amikor saját projektet kezdenek, mi alapján válasszák ki a számukra megfelelő módszert? Akár sokat is veszthetnek, ha vakon az egyik paradigma mellett teszik le a voksukat.
89

Fentebb számokkal

inf3rno · 2014. Okt. 1. (Sze), 14.49
Fentebb számokkal bizonyítottam, hogy van olyan helyzet (mint például az inf3rno által két módszerrel megírt login script is), ahol a procedurális kód minden tekintetben előnyösebb az OOP-nél.


Vannak olyan helyzetek, amikor nekem is kikerekednek a szemeim. :D
104

Véleményes...

Pepita · 2014. Okt. 1. (Sze), 18.53
Fentebb számokkal bizonyítottam, hogy van olyan helyzet (mint például az inf3rno által két módszerrel megírt login script is), ahol a procedurális kód minden tekintetben előnyösebb az OOP-nél.
Szerintem az, hogy kevesebb sor és kevesebb byte még erősen nagyon kevés ahhoz, hogy minden tekintet legyen.
Az átláthatóság, hordozhatóság és továbbfejleszthetőség egyenként is sokkal fontosabbak.
Ebből az első persze szintén szubjektív, de én azt gondolom, hogy a (nem teljesen kezdő) fejlesztők többsége könnyebben átlát, használ és fejleszt OO kódot, mint procedurálisat.
Saját tapasztalat: nemrég másoktól megörökölt projektet kellett továbbfejlesztenem, amiben volt egy functions.php alig 5-6000(!) sorral és kb. 200 különféle egyvelegfájl (backend-frontend keverék) az egyes funkcionalitások (vagy több) megvalósítására... Igencsak a hajunkat téptük, mikor egy változtatás miatt 50 helyen kellett módosítani. És így a legjobb IDE mellett is hatalmas a hibázási lehetőség.
106

Amit írsz a hatezer soros

Hidvégi Gábor · 2014. Okt. 1. (Sze), 19.25
Amit írsz a hatezer soros functions.php-ról, az kódszervezési probléma. Ezt meg lehet oldani procedurálisan és OOP-ben is jól.
123

Nekem az a tapasztalatom,

inf3rno · 2014. Okt. 2. (Cs), 14.44
Nekem az a tapasztalatom, hogy az ilyen projekteket vagy nem kell vállalni, vagy legatterolni az egészet, és nulláról újraírni. Szarból nem lehet várat építeni... Vagy hát lehet teljes refaktorálással és a tesztek utólagos megírásával, de annál könnyebb teljesen újraírni.

Ami talán még reális alternatíva az az event sourcing bevezetése az írással foglalkozó részeknél akár a jelenlegi adatbázis megoldással párhuzamosan, illetve a régi adatok alapján is meg lehet próbálni domain event-eket generálni. Ezzel még nem próbálkoztam.

Egyébként ez szerintem egyáltalán nem azt mutatja, hogy procedurális elveken nem lehet jó kódot írni. Egyszerűen csak arról van szó, hogy alacsonyabb a belépési küszöb, mint oo-nál, és ezért a legtöbb kezdő ilyen jellegű kódot ír. A PHP egyébként sem kimondottan támogatja meg a procedurális fejlesztést, szóval elég nehéz lenne a PHP-ban kezdők által leírt kódokból bármilyen mélyebb következtetést levonni.
173

Gábornak is

Pepita · 2014. Okt. 3. (P), 16.55
Ha alkalmazott vagy, nem válogathatsz annyira a módszerek közt, pláne nem az újraírás...

Nem annyira lehet procedurálisan jól és átláthatóan megoldani, mint OO.

Amiről írtam, azt eredetileg sem kezdők írták - ettől még elég rosszul. Újraírni nem volt idő és pénz, majd ha lesz...
66

Szimpla matek. A procedurális

inf3rno · 2014. Szep. 30. (K), 23.46
Szimpla matek. A procedurális változatban a lényegi kódrész 1,5 kilobájt, a HTML sablonok 1,8. Ha az OOP 15 kilobájtjából kivonjuk ezek összegét, akkor megkapjuk az OOP overhead-jét, ami 15 - 3,3 = 11,7. 11,7 / 1,5 = 7,8, így nem ötször, hanem majdnem nyolszor annyi az OOP kód. Még jó, hogy az ötöt szkeptikusan fogadtad : )


Nem fogadtam szkeptikusan, mérnök vagyok, nem szeretem, ha hasraütésre mondanak dolgokat.

Vigyázz, most nagyot fogok mondani: szerintem a tesztek csak annak a bizonyítékai, hogy a programozó nem látja át a kódot, és nem tudja, hogy egy változás milyen következényekkel fog járni, mit fog eltörni. Én szóltam : )


Ebben teljesen igazad van. A programozó is csak ember, akinek megvannak a korlátai. Én rengeteget hibázom, még triviális kódnál is, ezért írok teszteket. Bár ciki, de valamikor még a teszteknél is hibázom. ;-)

Néhány éve csináltam egy kisebb projektet tesztek nélkül. A pontos számokra nem emlékszem, csak a nagyságrendre: körülbelül 50 SQL volt benne. Ezek után úgy döntöttem, hogy mégiscsak írok integrációs teszteket, mert ránézésre találtam benne 1-2 hibát. A végeredmény az lett, hogy az 50-ből 25 SQL-ben voltak kisebb nagyobb hibák. A hibák többsége ritkán használt útvonalon volt, és/vagy nem feltétlen okozott kivételt, így előfordulhatott volna, hogy nagy részükre sosem derül fény. És akkor ez egy saját projekt volt, nem egy olyan, amit más írt, és nekem kellett belejavítanom... Tesztek nélküli kódnál már megfogadtam, hogy nem is vállalok semmi ilyesmit.

Azt hiszem többségünknek hasonló tapasztalatai vannak. Ha neked nincsenek, akkor vagy nagyon okos vagy, vagy nagyon hanyagul végzed a munkádat.

Szerintem a procedurális kódod azért átláthatóbb, mert két darab függvényt regényszerűen végigolvasva pontos képet kapunk a működésről. Az OOP kódban ugyanez 27 fájlra van szétbontva – ezen sokat nem változtatna, ha egy fájlban lenne, mert ugyanúgy ugrálni kéne a metódusok között.


OO kódnál általában hasonló a végeredmény, csak pár sorban összefoglalva, hogy mit csinál a kód. A változó és metódus nevekből általában minden kiolvasható, ha meg valaki arra is kíváncsi, hogy hogyan csinálja, akkor elkezdheti bújni a fájlokat. Nem biztos, hogy ez a projekt ilyen szempontból tökéletes.

Pedig írtam is, de te is megnézheted. OOP kód: 15kb, 27 fájl, procedurális kód: 3,3kb, 1 fájl. Mindkettőben bruttó 70 sor a lényegi rész, ami a munkát végzi.


Igazából 19 fájl és 14kb (plusz a keretrendszer), ha megnézed a framework-ös változatot. A framework-nél ott követtem el a hibát, hogy a rossz projekt struktúra miatt maga az alkalmazás logika nincs is tesztelve, csak a keretrendszer komponensei. Szóval nyugodtan számolhatsz rá 2x ennyi fájlt és méretet is, ha úgy jobbnak látod. A nagyobb méret egy jelentős része namespace, use, stb... kulcsszavakból származik, a másik része pedig az olvashatóságot és kereshetőséget könnyíti, úgy, mint osztálynevek, metódusnevek, változónevek, és így tovább.

A fejlesztési idő - projekt méret függvény a TDD esetében sokkal lankásabb, mint a procedurális kód esetében. Minél nagyobb a projekt, ugyanis annál több időbe fog telni a debuggolás, a végén pedig lehetetlen küldetéssé válik, és bedől a projekt. Az eleve teszt alapján írt kódoknál viszont, ha valami nem felel meg a teszteknek, akkor az azonnal kiderül, és nem kell keresni a hiba pontos helyét. Ez alól nálam eddig csak néhány alkalommal volt kivétel, amikor ilyen extrém dolgok voltak jelen, mint böngésző függő viselkedés, vagy valamilyen programnyelv vagy driver szintű hiba, amibe egyáltalán nem volt beleszólásom, és utána kellett nyomozni, hogy van e rá workaround.

A fentiek miatt a TDD-vel írt kódoknál a karbantartás általában nem debuggolást jelent, hanem új feature lekódolását.

Azt ne felejtsd el, hogy a programlogika már megvolt akkor, mire az OO-t elkezdted, tehát csak kódszervezés volt az a két óra. Viszont valami nem stimmel, mert egy akkori bejegyzésedben még 12 órát említesz.


A programlogika már a struktúrált kód esetében is megvolt, mivel a projektet annak az átgondolásával kezdtem. A 12 órát nem tudom hol olvastad. Ha pontos időket akarsz, akkor nézd meg a commit-ok idejét githubon. A 2 óra azért 2 óra, mert keretrendszert használtam, így a kód nagyrésze már előre meg volt írva, csak használni kellett...
71

Tesztek: nézd meg a

Hidvégi Gábor · 2014. Okt. 1. (Sze), 08.45
Tesztek: nézd meg a procedurális kódod kettő darab függvényét, és gondolkozz el azon, hogy ehhez milyen teszteket írnál, ha egyáltalán szükség van rájuk!

A változó és metódus nevekből általában minden kiolvasható, ha meg valaki arra is kíváncsi, hogy hogyan csinálja, akkor elkezdheti bújni a fájlokat. Nem biztos, hogy ez a projekt ilyen szempontból tökéletes.
Node az egész téma abból indult ki, hogy "Ti hogyan értettétek meg az OOP-t?" : )

A 12 órát nem tudom hol olvastad.
Itt írtad:
Ja, ez már beteges, végignéztem a commit listát, egyfolytában ment 12 órát :D
91

Itt

inf3rno · 2014. Okt. 1. (Sze), 14.57
Itt írtad...


https://github.com/inf3rno/weblabor-forum-115535-framework/commits/master

Nekem ez akárhogy is nézem 1 óra és 54 perc.

Node az egész téma abból indult ki, hogy "Ti hogyan értettétek meg az OOP-t?" : )


Nem értem ez az egész hogyan jön ide.
95

Akkor nem értem, miért írtál

Hidvégi Gábor · 2014. Okt. 1. (Sze), 15.42
Akkor nem értem, miért írtál 12 órát, ha csak kettő összesen.

Nem értem ez az egész hogyan jön ide.
A témanyitó kérdés az volt: "Ti hogyan értettétek meg az OOP-t?". Erre te készítettél egy procedurális, majd abból egy OOP kódot, hogy szemléltesd az OOP elveit.

Erre a következőt írtam:
Szerintem a procedurális kódod azért átláthatóbb, mert két darab függvényt regényszerűen végigolvasva pontos képet kapunk a működésről. Az OOP kódban ugyanez 27 fájlra van szétbontva – ezen sokat nem változtatna, ha egy fájlban lenne, mert ugyanúgy ugrálni kéne a metódusok között.
És most tegyük túl magunkat azon, hogy 19 vagy 27, nagyságrendileg megegyezik a kettő. Erre te ezt válaszoltad:
OO kódnál általában hasonló a végeredmény, csak pár sorban összefoglalva, hogy mit csinál a kód. A változó és metódus nevekből általában minden kiolvasható, ha meg valaki arra is kíváncsi, hogy hogyan csinálja, akkor elkezdheti bújni a fájlokat. Nem biztos, hogy ez a projekt ilyen szempontból tökéletes.
Tehát átláthatóságból az OOP kódod nem tökéletes, mert 19 fájlt kell átnézni, ha meg szeretnéd érteni a működését. Csak arra szerettem volna utalni, hogy akkor ez nem a legjobb demonstrációja az OOP melletti érveknek.

Egyébként meg nagyon nem tudod másképp megcsinálni, ha meg szeretnél felelni az SRP-nek és egyéb elveknek.
105

Középút

Pepita · 2014. Okt. 1. (Sze), 19.01
Ha a saját szemszögemből nézem, ti kb. a két végletet képviselitek:
inf3rno a "tökéletes" OOP-t,
te a 0 OOP-t.

Az igazság valahol a kettő közt van, mindenképp OO irányban.

Szerk.: elhangzott az is, hogy leginkább egy keretrendszer alatt. Akkor nem is (vagy sem) kell annyi felé darabolni.
107

Nem

Hidvégi Gábor · 2014. Okt. 1. (Sze), 19.29
Én azt a kérdést tettem fel, hogy hol van az a határ, ahol érdemes lehet áttérni OOP-re.
128

Én nem mondom, hogy tökéletes

inf3rno · 2014. Okt. 2. (Cs), 15.10
Én nem mondom, hogy tökéletes az OO tudásom. Sokat olvastam a témában, gyakorolgatom, de még jócskán van hova fejlődnöm. Az OO egyébként sem univerzálisan jó mindenre. Én is használok adatstruktúrákat (DTO), amiknek a feldolgozása inkább procedurális, mint OO, de nyilván mindenki más is ezt teszi, aki webfejleszt. Pl az összes DOM event adatstruktúra, illetve az egész DOM fa is egy nagy adatstruktúra, ami DOM node-okból áll, és így tovább... Szerintem, meg még sokak szerint az OO csak kiegészíti egy új eszközzel a procedurális programozást. Az eddigiek alapján nekem az a tapasztalatom, hogy aki megkérdőjelezi az OO létjogosultságát, annak lövése sincs, hogy mire jó, és hogy hogyan kellene használnia.
13

Lehetséges..

Szita Szilárd · 2013. Már. 24. (V), 09.31
lehetséges megértettem az egészet :) de még nem biztos.
Néztem egy videót és ott egy állat osztályt készített és abból megértettem :)
Na megpróbálok írni valamit :) php-val,de előtte átnézem a php dokumentációját
15

oop

Hidvégi Gábor · 2013. Már. 24. (V), 09.46
Maga az elv egyszerű, és elvileg bármit meg lehet írni objektum orientált alapokon, azt kell inkább megérteni és megtanulni, hogy hol érdemes. Az OOP-nek nagy irodalma van, rengeteg a programozási minta, amelyeket sokszor egy nagyon speciális feladathoz lehet hatékonyan felhasználni egy nagyon speciális esetben.

Az általad hozott bejelentkezési példában én biztosan nem használnék, de akár egy teljes felhasználókezelésben sem, mert ha teszem azt minden divatos elvnek (TDD, SRP, SOLID és társaik) meg szeretnék felelni, akkor lenne egy ezer soros kódom, sima függvényekkel meg megoldom ugyanazt mondjuk százból, tizedannyi hibázási lehetőséggel. A szomszédba is gyalog megy az ember, nem tankkal.

Nem vitatom a témában tapasztaltabbak véleményét, akik azt mondják, hogy ez bizonyos esetekben szükséges lehet, mondjuk nagy projektnél, amin sokan dolgoznak. De ahhoz, hogy ezt el lehessen dönteni, rengeteg munkában kell részt vennie először az embernek, és emiatt nem biztos, hogy a C# a legjobb választás első nyelvnek, mert itt nincs választási lehetőséged, mindent OOP-ben kell megoldanod. Még van időd változtatni.
16

Ez hibás hozzáállás! Az

H.Z. · 2013. Már. 24. (V), 10.10
Ez hibás hozzáállás! Az objektum orientált rendszerek egyik lényege az újrahasznosíthatóság. És ez okozza az egyik legnagyobb problémát is: nagyon jól meg kell tervezni az alapokat ahhoz, hogy valóban újrahasznosítható kódod legyen, ne csak egy osztályokból-objektumokból álló kódhalmaz.
Persze, egy kizárólag usernév/jelszó hitelességére épülő beléptető rendszerhez nincs szükség OOP-re. Mi több, programozásra sem, hiszen a webszerver is képes jelszóvédett tartalmakat szolgáltatni (amit már rég elfelejtett a többség)
De ha továbbgondolod és jogosultságkezeléssel is foglalkoznál, ráadásul egy bővíthető jogosultsági rendszert akarsz, akkor már érdemes elgondolkodni rajta, hogy OOP irányba menni.

Ha a szemem nem akadályozna, akkor is elakadtam volna azon, hogy annyira előre kell gondolkodni egy valóban korrekt OOP rendszer felépítésekor, amennyire már képtelen vagyok - és tartok tőle, hogy ezzel sokan vannak így, max. maguknak sem ismerik be. (nem rád céloztam, mielőtt...)
17

Az objektum orientált

Hidvégi Gábor · 2013. Már. 24. (V), 10.22
Az objektum orientált rendszerek egyik lényege az újrahasznosíthatóság.
Régi munkáimban nagyon szép include-olható, önállóan használható, nem OOP szintaktika szerint megírt, pusztán függvényekből álló fájljaim vannak. Valamit rosszul csináltam?
De ha továbbgondolod és jogosultságkezeléssel is foglalkoznál, ráadásul egy bővíthető jogosultsági rendszert akarsz
És ha nem akarok?
19

Biztos, hogy ugyanazt értjük

H.Z. · 2013. Már. 24. (V), 10.32
Biztos, hogy ugyanazt értjük újrahasznosíthatóság alatt?
20

Újrahasznosíthatóság

BlaZe · 2013. Már. 24. (V), 10.33
Régi munkáimban nagyon szép include-olható, önállóan használható, nem OOP szintaktika szerint megírt, pusztán függvényekből álló fájljaim vannak. Valamit rosszul csináltam?

Gondolj arra, hogy volt-e olyan include-od, ami pl a jogosultságkezelést csinálta (A), és voltak-e más include-jaid, amik erre épültek (B). Aztán gondolj arra, hogy B-ben máshogy szeretnél jogosultságot kezelni egy project kapcsán, illetve hogy mit kell ehhez tenned (kell írnod egy A'-t, és B'-t). Már dupla kódot tartasz karban. Egy kulturáltan megtervezett OO rendszernél ez annyi, hogy írsz egy másik osztályt, ami implementálja a beléptetést, és azt dobod át B-nek, B-n semmit nem kell módosítani, de A-n sem. Ezt jelenti a jó újrahasznosíthatóság, nem azt, hogy ugyanazt, ugyanúgy, ugyanolyan szoros függőségekkel újra használni.
21

És ezt a laza csatolást OO

Hidvégi Gábor · 2013. Már. 24. (V), 10.54
És ezt a laza csatolást OO nélkül nem lehet megoldani?
22

Nyilván meg lehet, hiszen a

BlaZe · 2013. Már. 24. (V), 11.10
Nyilván meg lehet, hiszen a processzoron sem OO utasítások futnak :) A kérdés nem ez, hanem hogy meg lehet-e hatékonyan és átláthatóan oldani. Értem ezalatt, hogy a hívó oldalon pl tudod-e, hogy mit fogsz meghívni, tudsz-e fordítási idejű ellenőrzést végezni az elvárt subrutinra stb. Ha valahol van egy pointer, függvény referencia (tedd ide azt, ahogy megoldanád), a hívó oldalon ezek szignatúrájáról pl fogalmad sincs, ami jelentős mértékben bonyolítja a program karbantarthatóságát. De megint ott tartunk, hogy vitatjuk egy nagyon komoly elméleti háttérrel és gyakorlati tapasztalattal megtámogatott best practice létjogosultságát? :)
24

Nem. Én csak azt vitatom,

Hidvégi Gábor · 2013. Már. 24. (V), 11.22
Nem. Én csak azt vitatom, hogy mindenhol ezt kéne használni.
25

Senki nem mondta, hogy

BlaZe · 2013. Már. 24. (V), 11.34
Senki nem mondta, hogy mindenhol ezt kell használni. De kb az esetek 99%-ában célszerű :) Ha úgy közelítesz egy feladathoz, hogy itt nem kell OOP, mert ez még nem annyira bonyolult (lásd a jogosultságkezelési példát), akkor rosszul állsz neki, és rossz döntést hozol. A programokat úgy írjuk, hogy feltételezzük közben, hogy használatban lesz, ergo karban kell tartani, tovább kell fejleszteni stb. Ráadásul igyekszünk úgy megírni programrészeket, modulokat, hogy egy az egyben át lehess emelni más programokba is. És ha ezt végiggondolod, egy jól tervezett OOP rendszernek (többek között a korábban említettek miatt) itt már nagyon komoly előnye lesz egy szoros csatolású include halomhoz képest.
27

Kötexem

H.Z. · 2013. Már. 24. (V), 11.42
Azért azt tudod, hogy ez "előre optimalizálás"? ;))))
(bocs, nem bírtam kihagyni... mindig a fejemhez vágták, hogy előre optimalizálok, valahányszor megjegyeztem, hogy nem árt végiggondolni, mit is csinálok a programban :) )
29

vastag idézőjel

blacksonic · 2013. Már. 24. (V), 12.06
Azért itt az előre optimalizálást igencsak vastag idézőjellel kell írni :)
28

szerintem

zzrek · 2013. Már. 24. (V), 11.57
Szerintem egyetértetek a Gáborral, csak míg ő azt mondja, hogy "bizonyos esetekben" addig te azt, hogy "az esetek 99%-ában". Akinek az OOP-re van ráállva az agya, az akkor is azt fogja használni, ha épp az esetek maradék 1%-a van. Vagyis a szomszédba megy tankkal. Kétségtelen viszont, hogy ritkán fordul elő, hogy a szomszédba a fizetésünkért mennénk... :-)
30

Igen, egyrészt a

BlaZe · 2013. Már. 24. (V), 12.16
Igen, egyrészt a százalékokban nem értünk egyet. Én azt gondolom, hogy a jól karbantartható és újrahasznosítható programok készítéséhez a jelenlegi leghatékonyabb út az OOP. Valóban nem gondolkodom azon, hogy OOP legyen-e, vagy nem. Erre sok esélyem nem is lenne, tekintve hogy OOP nyelven programozok :) Nagyon gépközeli kódot azt gondolom kevésbé éri meg OOP-ben írni, de ilyet egy átlagos programozó gyakorlatilag nem készít, vagy csak nagyon ritkán. Én ezzel indoklom az 1%-ot. De lehet ezzel még túloztam is :) Gábor ezzel szemben azt mondja, hogy ő alapból nem használ OOP-t, mert csak elbonyolítja a dolgokat (legalábbis nekem ez jön le a soraiból).
31

KISS

Hidvégi Gábor · 2013. Már. 24. (V), 12.42
Jelenlegi – korlátos tudásommal – úgy látom, ott érdemes OOP-t használni, ahol szükség van az öröklődésre, a polimorfizmusra és a zártságra. Eddigi munkáim lehet, hogy nagyon egyszerűek voltak, de egyszerre nem használtam mindet, és hiába írtam át OOP-re a kódot, mert mások véleménye alapján úgy éreztem, akkor lesz jó, nem láttam előnyét.

Amiben viszont a végletekig hiszek, az az egyszerűség. Minél egyszerűbb valami, annál nehezebb elrontani, ez eddig mindig bejött. Az OOP használatával viszont nagyon könnyen el lehet menni a másik irányba, lásd az 1+1-es blogmarkot.
32

Az öröklődés, polimorfizmus

BlaZe · 2013. Már. 24. (V), 13.00
Az öröklődés, polimorfizmus és egységbe zárás az OOP alappillérei ugye. De ezek nem célok, hanem eszközök! Vagyis nem azért programozunk OOP-ben, hogy örököltethessünk pl, hanem azért örököltetünk és override-olunk, mert ezzel bizonyos célokat nagyon hatékonyan tudunk megvalósítani. Nevezetesen pl a leszármazottankénti (implementációnkénti) részletekben, vagy egészében eltérő viselkedést az őstől (pl configból, vagy db-ből olvassuk be a jogosultsági szinteket). És lehet folytatni.

Elbonyolítani mindent el lehet. Akár OOP, akár procedurális az implementáció. Az elbonyolított kód rossz és értelmetlen. Azonban az tény, hogy OOP kódnál kell egy komolyabb tapasztalat, hogy ne elbonyolítottnak láss egy összetettebb öröklődési fát, hanem lásd meg az értelmét. Rövidebben: az oo engineering és az over-engineering nem szinonim fogalmak :)
39

Fontos és kimaradt

Pepita · 2013. Már. 24. (V), 21.38
Egy érv / ellenérv eddig kimaradt a vitátokból, pedig elég fontos. Itt írod:
ott érdemes OOP-t használni, ahol szükség van az öröklődésre, a polimorfizmusra és a zártságra
Ezek közül - remélem, te is így gondolod! - ha egyre is szükség van, máris indokolt az OOP.
Itt kiemelném a zártságot, ill. a függvények és változók hozzáférhetőségét. Egy mai webes projektben ez szinte mindig elengedhetetlen (pl. MVC), így máris "kiesett a játékból" a procigyűjteményed.

De vannak további ellenérvek is:
- Az ilyen beszúrt (include) gyűjteményekkel hogyan tudod megvalósítani, hogy ne írd felül (véletlenül sem) egyik fv-eddel a másikat?
- Ha csak 3-4 ilyen fájlt kell az adott projektben felhasználni, máris gázos lesz a későbbi újrahasznosítás, mert később egy pici változtatás kell, de ehhez mindegyikbe bele kell nyúlnod valahol egy kicsit (hogy működjön is) -> máris jóval bonyolultabb a feladat, mint osztályok esetében. Túl sok dolgot kell neked fejben tartanod, hogy melyik fv. melyik másikakat használja, stb.
- A (globális) láthatóság elég veszélyes tud lenni, főleg változók esetében.

Fenti okokból én azt javaslom, hogy még akkor is osztályokat használj, ha egyszerű fv-gyűjteményként használod őket, semmit nem örökítesz, stb., mert így könnyebben tudod módosítani, újrafelhasználni, és el tudod rejteni azt, amit kell. Egyszerűbb projekteknél ez elég is.
55

Az ilyen beszúrt (include)

Hidvégi Gábor · 2014. Szep. 30. (K), 17.54
Az ilyen beszúrt (include) gyűjteményekkel hogyan tudod megvalósítani, hogy ne írd felül (véletlenül sem) egyik fv-eddel a másikat?
Fatal error: Cannot redeclare hehe() in D:\Dokumentumok\php\inc_inc.php on line 2

Egy mai webes projektben ez szinte mindig elengedhetetlen (pl. MVC)
MVC? Normálisan még nem láttam megvalósítva. Például a HTML kód ezer könyvtárban van szétszórva, és a sitebuilder is ezeken rágja át magát, ha valahol módosítani kell? Az MVC eleve egy rugalmatlan elképzelés, hisz az esetek 99%-ában bele van égetve, az adatoknak hogyan kell megjelenniük (mondjuk HTML formában). Ennél sokkal hatékonyabb lenne egy olyan megoldás, amiből kioperálják a V-t, teljesen különválasztják, s aki a kapott adattömbből – amibe korábban belehánytak mindent, amit kellett – majd eldönti, hogy mit és hogyan jelenít meg.

- Az öröklődés megbukott

- Az egységbezárás ellentmond a separation of concerns elvének, egyszerű példa: Egységbezárás esetén az adott adatok az adott objektumhoz tartoznak. Vegyünk egy adattömböt, amiben a site struktúrája fel van sorolva egy lekérdezés eredményeképp. Ezt két helyen is felhasználhatjuk: 1, legenerálunk belőle egy menüt, 2, elkészítjük belőle a navigációs sávot (címlap -> cikkek -> cikk). Mit és hogyan zárjunk egységbe? Legyen egy objektumban az egész? Feleljünk meg a single responsibility elvnek? - Legyen egy class a nyers adatoknak, és egy-egy a menünek és a navigációs sávnak? Vagy mi lenne, ha valahol lenne egy tömböm az adatokkal, máshol vannak függvényeim, aztán aki akar, olvasgat a tömbből, így programozóként nem azzal töltöm el az időmet, hogy megfeleljek valaki homályos elképzeléseinek.

Ha csak 3-4 ilyen fájlt kell az adott projektben felhasználni, máris gázos lesz a későbbi újrahasznosítás
Elnevezés kérdése. Teljesen mindegy, hogy $menu = new Menu(); $menu->beolvas();, vagy pedig menu_beolvas(); parancsokat adunk ki.

A (globális) láthatóság elég veszélyes tud lenni, főleg változók esetében
Egy átlag weboldalt két globális változóval el lehet készíteni (php esetében a szuperglobálisokon kívül): egy az sql linknek és egy a tartalomnak (amibe belekerül a menü, az oldalsáv elemei stb.).
64

Ez hogy jött már megint? :)

BlaZe · 2014. Szep. 30. (K), 22.46
Ez hogy jött már megint? :) Leült a weblabor és bedobod a lerágott csontot? :)

Ha indulnál egy félreértelmezés világbajnokságon, én tuti rád fogadnék ;) Az öröklődés nem bukott meg, ma is használt dolog. Az emberek rájöttek, hogy mire nem való, és hogy miért/hol jobb a composition. De nem most, már jórég. Ettől még nem bukott meg, csak arra használjuk, amire való. Egyébként a múltkori blogmarkoddal már veszélyes közelségbe kerültél a design patternekhez :)

Érdekes egyébként látni, hogy időnként újra és újra rácsodálkozik a szakma ugyanarra. Amire gondolok, hogy kezdenek rájönni a többszálú programozással kapcsolatban, hogy állapotot megosztani szálak között nem jó, főleg nem jó valamit több szálból írni. Sem sebesség, sem karbantarthatóság szempontjából. Bezárják ilyen izékbe (ojjettumokba) az adatokat és nem kirakják nagy közös globális kódbázis elé, hanem tesznek elé egy interface-t, amin keresztül menedzselten (és lokalizáltan) karbantartható az állapota, más szálaknak read-only nézetet (neadjisten másolatot) adnak stb. Ez is encapsulation. Az eredmény pedig a korábbi race condition hellhez képest egy karbantartható és relatíve egyszerű kódbázis. Ugyanaz a motiváció mögötte, mint OOP esetében. Karbantartható kódot írni a felelősségi körök meghatározása nélkül nem lehet. Ennek egy előfeltétele az encapsulation. Ez ellen lehet kapálózni, de nem érdemes :)

A példádra egyébként a megoldás az, hogy több interface-en (nézet) keresztül teszed elérhetővé a belső reprezentációdat (esetedben tömböt). Akkor nem kell sok másolatot csinálni az adatból, ráadásul a felhasználási helyen egyértelmű, hogy mit kell vele csinálni, nem csak van egy nyers adathalmaz, aztán találd ki mit kezdj vele.
67

Érdekes egyébként látni, hogy

inf3rno · 2014. Okt. 1. (Sze), 00.15
Érdekes egyébként látni, hogy időnként újra és újra rácsodálkozik a szakma ugyanarra.


Ó ez egyáltalán nem csak többszálú kódnál megy, hanem nagy méretben architektúrák tervezésénél is.

Pl DDD-nél a domain model-t teljesen le lehet választani egy interface-el a megjelenítéstől és az adatbázisról, így külön tesztelhető unit test-ekkel.

Ugyanígy REST-nél az uniform interface constraint azt írja le, hogy szabványokat kell használni olyan interface kialakítására, ami független az aktuális service implementációjától. Ygy a kliensek lazán csatoltak lesznek ehhez az implementációhoz, és ezért a kliensek újrahasznosíthatóak a service-ek pedig szabadon cserélhetőek. Így lehetséges (lenne) internet méretben skálázódó alkalmazásokat írni (ha a szakma felfogná, hogy mit jelentenek ezek a dolgok).

Gondolom másoknak is vannak hasonló példái. A probléma az lehet, hogy sokan baromi műveletlenek, és nem is hajlandóak továbbképezni magukat, aztán néhány év munka után feltalálják a spanyol viaszt. Pl a clean architecture, onion architecture, hexagonal architecture mind szinte azonos alapokon nyugszanak csak az elnevezések mások, amiket használnak (a clean architecture volt az egyetlen, ami hivatkozik egy azt hiszem 80-as évekbeli könyvre, ahol leírják teljesen ugyanazt). Ugyanígy DDD-vel kapcsolatban láttam már video-t ami a microservices-t írja le, és így tovább, szerintem még elég hosszú a lista... Én általában ha ilyen világmegváltó ötletem van, akkor napokig ülök a google előtt, mire rátalálok arra, hogy hogyan nevezik mások a nagy újításomat...
70

Ó ez egyáltalán nem csak

BlaZe · 2014. Okt. 1. (Sze), 00.34
Ó ez egyáltalán nem csak többszálú kódnál megy, hanem nagy méretben architektúrák tervezésénél is.
Valóban nem, azért hoztam ezt példának, mert a többszálú programoknál nagyon tipikusak az ilyen problémákból fakadó bugok, és mert a kód nagyon törékeny az ilyen egymás feje felett átnyúlkálásokra.
73

Az a csont messze nincs még

Hidvégi Gábor · 2014. Okt. 1. (Sze), 09.17
Az a csont messze nincs még lerágva. Lehet, hogy számodra a kompozíció teljesen ismert fogalom, de például a Wikipédián nincs megemlítve, és sok más helyen sem lehet találkozni ezzel a fogalommal. Ha pedig nem is tanítják (mert mondjuk a tankönyvek/tananyag le van maradva pár évvel), akkor egy csomóan elavult tudással bújnak ki az iskolapadból, és így olyan kódokat gyártanak, ami rosszabb, mintha például a jó öreg procedurális módszert választották volna.

Ezen a példán látszik, hogy mennyire nagy és összetett dolog a programozás. Sok évet kell dolgoznia valakinek vagy rengeteg irodalmat el kell olvasni, mire át tudja látni egy paradigma/eszköz legtöbb előnyét és hátrányát.
92

a kompozíció teljesen ismert

inf3rno · 2014. Okt. 1. (Sze), 14.59
a kompozíció teljesen ismert fogalom, de például a Wikipédián nincs megemlítve


A composite pattern szerinted micsoda?!
110

Az iskola célja, hogy olyan

BlaZe · 2014. Okt. 1. (Sze), 23.40
Az iskola célja, hogy olyan alapozást nyújtson, amire ráépülve megérthetők a komplexebb megoldások is, amit majd a munkád során használsz. Ez elsősorban elméleti alapozást jelent. Iskolában gyakorlati tapasztalatot nem tudsz szerezni. Legalábbis nem összehasonlítható a munkatapasztalattal. Ezzel nincs is gond, hisz nem erre való. A gond az, ha valaki ezt nem ismeri fel, és nem tanul. Ez egy olyan szakma, hogy folyamatosan képezni kell magad, könyveket, blogokat, előadásokat bújni. És van jó anyag bőségesen. Szóval arra ne hivatkozzunk, hogy tanulni kell, hogy az ember jó szakemberré váljon. Persze hogy kell. Nálunk pl belső céges oktatás van a jó(nak gondolt) junioroknak, pont ezért, hogy bevethetőek legyenek.

A compositiont egyébként nem tudom honnan veszed, hogy kevéssé ismert dolog. Ez azért nem egy új találmány, bőséggel találni róla infót.
74

Lassú

Hidvégi Gábor · 2014. Okt. 1. (Sze), 09.31
Egyébként úgy jött már megint elő, hogy a hétvégén készítettem egy roppant egyszerű tesztet. Írtam két php fájlt, az egyikben procedurálisan, a másikban OOP módon kapcsolódtam MySQL-hez, lefuttattam egy lekérdezést ezerszer, és megmértem az utóbbi futási idejét.

Az eredmény: a procedurális kód 26, az OOP 50 sorból jött ki, továbbá a procedurális átlagosan 8%-kal gyorsabb volt. A memóriafoglalásban nem volt ekkora eltérés, a procedurális maximálisan 418, az oop 421 kilobájtot evett.

Ezen nagyon felhúztam magam, hogy hagytam magam meghülyíteni, és átírtam az adatbáziscsatolómat OOP-sre.
75

Megnézném

vbence · 2014. Okt. 1. (Sze), 11.42
Ilyenkor illik a kijelentés mellé rakni a két szkriptet.

Más (ezerszer megbeszéltük a WL hasábjain): A magasabb absztrakciós szint előnye többekközött, hogy fenntarthatóbb kódot eredményez, ennek ára nagyobb erőforrásigény. - Ez ugyanígy igaz egy PHP-ASM vitában.
76

Nekem erről csak az jut

H.Z. · 2014. Okt. 1. (Sze), 11.55
Nekem erről csak az jut eszembe, hogy oop előtt is volt élet, lecseng a divatja, lesz helyette más, de azt is lesz aki ugyanígy kritizálja majd. :)
93

Nekem erről csak az jut

inf3rno · 2014. Okt. 1. (Sze), 15.02
Nekem erről csak az jut eszembe, hogy oop előtt is volt élet, lecseng a divatja, lesz helyette más, de azt is lesz aki ugyanígy kritizálja majd. :)


Valószínűleg ez lehet a fő probléma, hogy sokan divatból próbálkoznak imitálni, úgy, hogy az alapvető dolgokat sem értik.
23

Csak saját véleményem: mire

H.Z. · 2013. Már. 24. (V), 11.21
Csak saját véleményem: mire megoldod strukturált vagy egyéb eszközökkel, addigra objektum-orientálttá válik az egész, csak a szintaxis lesz más. :)
40

Csak saját véleményem

Pepita · 2013. Már. 24. (V), 21.42
Mire a procihoz ér a programod, addigra rég struktúrált... :)
41

A procinak semmit sem jelent

H.Z. · 2013. Már. 24. (V), 21.45
A procinak semmit sem jelent a strukturált programozás. Az már gépikód, nagy jóakarattal nevezhetjük procedurálisnak. A strukturált más témakör. :))

ui: gépikód tényleg nem egy szó? A hejjesirásselenrörzöm aláhúzza... Viszont a strukturált (a kulturált mintájáta) rövid ú. ;)
46

Az utolsó gondolatról volt

deejayy · 2013. Már. 25. (H), 09.28
Az utolsó gondolatról volt szó az egyik nem-is-olyan-régen tartott PHP meetupon, ahol az előadó a S.O.L.I.D.-ról vázolta az alapokat.

Ha jól rémlik az O-nál merült fel, hogy tulképpen kivitelezhetetlen, hiszen nem lehetséges annyira előre gondolkodni, hogy minden jövőbeli igényre felkészülj, viszont lehet úgy refaktorálni a meglévő kódot miután ismered az új igényt, hogy "mintha erre felkészültünk volna" (kvázi, "megágyazol" neki), és utána implementálod valójában az új igényt.
47

Én is kb erre jutottam, ezért

inf3rno · 2013. Már. 25. (H), 12.03
Én is kb erre jutottam, ezért lehet csak tényleges igényekkel hatékonyan dolgozni. Ha nincsenek tényleges igények, csak valami általános kódot kell írnod egy célra, akkor a végtelenségig lehet bonyolítani...
26

Kész!

Szita Szilárd · 2013. Már. 24. (V), 11.39
Na elkeszultem igaz tesztelni nem teszteltem!
Biztos van benne sok hiba,de egy elsore talan megertettem az oop lényegtét!
ok.php

<?php
class adatbazis{//létre hozom az adatbazis osztalyt 
private $kapcsolodas; //letre hozok ketto privat valtozot
private $tabla;

function kapcsolat($host,$felhasznalo,$jelszo,$adatbazis,$tabla){//keszitek egy kapcsolat fuggvenyt

$this->kapcsolodas=mysql_connect($host,$felhasznalo,$jelszo);//itt deklaralom a kapcsolodas valtozot aminek 3 parametert adok
mysql_select_db($adatbazis,$this->kapcsolodas);//kivalasztom az adatbazist
$this->tabla=$tabla;//ra mutatok a tablara
}
function mezomutatas(){//ez magatol ertetodo
return('<form method="POST"> <h3 align="center"> Belepes</h3>
 </br> <input type="text" name="felhasznalo" value="felhasznalonev">
 </br>
 <input type="password" name="jelszo" value="Jelszo">
 </br>
 <input type="submit" name="gomb" value="Belep"> </form>');

}
public function belep($felhasznalo,$jelszo){ //itt letre hozok egy pulikus fuggvenyt amit majd mas osztalyok is lathatnak.
$query="select * from". $this->table . " where felhasznalo='".$felhasznalo."' and jelszo='".$jelszo."'";//le kerdezem a tablabol az adatokat
$ertek=mysql_query($query);
$sorok=mysql_num_rows($ertek);
return !($sorok==0);
}

}


?>


login.php

<?php
include('ok.php');
$obj = new adatbazis;//peldanyositom az adatbazis objektumomat
$obj->kapcsolodas('localhost','root', '','belepes','belepes');//megadom a kapcsolodas
adatait
?>
<html>
<body>
<?php
if(isset($_POST['gomb'])){//magatol ertetendo

if($obj->belep($_POST['felhasznalo'],$_POST['jelszo'])){
echo("<h1 align='center'> belepett</h1>");
}
else{
echo($obj->mezomutatas());
}
}
else(
echo($obj->mezomutatas());
)
?>
</body>
</html>
Mentsegemre szoljon most latok 5x php kodot nem valami nagy durranas de legalab ugy erzem megertettem az oop-t.
Most mar csak bele kell asnom magam a melyebe.
Igaz nem php nyelven,de egesz kis pofas szerkezete van a php nak hasonlit a c-hez.
:):):)
42

Hiba

Pepita · 2013. Már. 24. (V), 21.52
Az ok.php-ben kétféle elnevezése van egy változódnak: $this->tabla; $this->table. Legyél következetes a változók neveiben, vagy angol, vagy magyar, de mindig és mindenütt. Akkor kevésbé nézel be ilyet.

Megjegyzésbe ilyet, hogy //ez magatol ertetodo felesleges írni, csak rontja a kód olvashatóságát. Ha magától értetődő, akkor minek oda komment?

(Itt ugyan nem a biztonság a téma, de semmi védelem nincs a kódban, ovis hacker is feltöri.)
48

Lehet

Szita Szilárd · 2013. Már. 25. (H), 18.49
Szia,Pepita sajnos nem értek a php-hez csak át futottam egy picit a függvény írást és kb ennyiből állt a program megírtam egy két függvényt és kész!!
Pl:Mit lehetne rajta biztonságossá tenni?
Érdekelne a véleményed
49

Biztonság!

Pallosi Péter · 2013. Már. 26. (K), 09.01
Kedves Szilárd!
Két nagyobb hiba is található a rendszerbe.
  • Nem szűrt speciális karakterek

  • Helytelen típuskezelés



Az SQL szintaxisban vannak speciális karakterek amelyeket,ha nem szűrünk nagy károkat okozhatnak a rendszerünkbe pl: Kiírja az adott felhasználó jelszavát..stb

Helytelen típuskezelés!
itt a típus ellenőrzése a nagyon fontos,és hiba van neked titkosítva a jelszód pl MD5 semmit nem fog érni!

Mit tehetünk?
Hát mondjuk tesztelünk!!!
Ha kézzel állítjuk össze az sql lekérdezést akkor mindenképp escapeljük a szöveges beviteli mezőket!
pl: mysql_real_escape_string
50

Ha programozni szeretnél

Hidvégi Gábor · 2013. Már. 26. (K), 09.14
Ha programozni szeretnél megtanulni C#-ban, meg az OOP-t megérteni, egyelőre ne foglalkozz a PHP biztonsági kérdéseivel. Nagy téma, félrevisz, nem lesz időd felkészülni.
33

Tesztelve,de

Szita Szilárd · 2013. Már. 24. (V), 14.32
Tesztelve,de nem működik és sajnos nem tudom mi lehet a gond valami szintaxis hiba a 19.sorba az echo-val van valami T_ECHO nem tudom mi ez!!!
35

Az utolsó else-nek kapcsos

kuka · 2013. Már. 24. (V), 15.05
Az utolsó else-nek kapcsos helyett kerek zárójelei vannak.

Javaslom, hogy tedd a forráskódot olvashatóbbá behúzás használatával.
37

inferno+1, az OOP-t valós

tgr · 2013. Már. 24. (V), 15.59
inferno+1, az OOP-t valós példákon keresztül lehet normálisan megérteni, méghozzá bonyolult valós példákon, mert egyszerű példánál nem használná az ember. Nem kell azon kétségbeesni, ha kezdő programozóként nem érted, valószínűleg nem találkoztál még olyan bonyolult feladattal, ahol hasznos lett volna. Szerintem ne is erőltesd, amíg a procedurális programozás nem megy jól.
38

Igen

Szita Szilárd · 2013. Már. 24. (V), 16.15
Igen értem igaz nem a php-val kezdtem el foglalkozni!
c#
51

Szakítottam időt a témára,

inf3rno · 2013. Már. 26. (K), 15.20
Szakítottam időt a témára, összeszórtam 3 repot az egyszerű bejelentkezős cucchoz, amit kértél:

https://github.com/inf3rno/weblabor-forum-115535-strukturalt

https://github.com/inf3rno/weblabor-forum-115535-tdd

https://github.com/inf3rno/weblabor-forum-115535-framework

A struktúráltan írt kód 5 óra alatt készült el. A refaktorálása 10 óra alatt készült el. Így az összesen 15 óra. A tdd-vel írt kódnál néhány óra elment a phpunit megtanulására, ill. ott teszteket is írtam ellentétben a refaktorált változattal, így az összesen 16 órára jött ki. A TDD-ben készült keretrendszerrel írt kód 2 óra alatt készült el.

Én azt javaslom mindenkinek, hogy érdemes kipróbálni mindegyik módszert egy kisebb feladatnál, mert nagyon tanulságos:
  • A struktúrált hamar megvan, de ahogy nőtt a projekt, egyre kényelmetlenebb lett a használata.
  • A struktúráltan megírt, majd oop-re refaktorált kódból sokkal nehezebb egy átgondolt rendszert csinálni, mint nulláról indulva.
  • A TDD-vel írt rendszer mindkét változatnál sokkal átgondoltabb, és ahogy nőtt a projekt, úgy volt egyre kényelmesebb a használata.
  • A keretrendszerrel írt kód a struktúráltnál is sokkal hamarabb megvolt, körülbelül fele annyi idő alatt, mert nem kellett általános, ismétlődő dolgokra koncentrálni, csak az adott feladatra. Szóval saját keretrendszer írása egy feladatra nagyon időigényes, jobb helyette egy már létezőt használni.


Meg fogom írni ugyanezt olyan keretrendszerekkel, amiket netes keresgetéssel halászok össze: slim, mustache, stb... Kíváncsi vagyok, hogy úgy mennyi időbe telik. Persze meg lehet írni symfony-val, vagy hasonlóval is amiben szinte mindenhez van segítség, szóval akár még azzal is lehet próbálkozni.
52

Gratulálok!

Pallosi Péter · 2013. Már. 26. (K), 20.44
Volt időm és megnéztem a kódot nagyon szép!
Csak gratulálni tudok!
53

Próbáld committok szerint

inf3rno · 2013. Már. 27. (Sze), 08.05
Próbáld committok szerint sorba nézni, hogy mennyire követhető, hátha elkapod a fonalat... Ma megírom TDD-s keretrendszerről kiindulva, meg talán megírom még külső kertrendszerrel is, mondjuk slim-mel.

A TDD-snél csak azokat a dolgokat teszteltem, amikre az oldal épül, magát az oldalt nem. Azt mondják a view-ra nem érdemes unit test-et írni, mert nem térül meg, max végig lehet kattintgatni, hogy minden okés e. A model-re szoktak tesztet írni, azt jobb is leválasztani az alkalmazásról külön REST service-be, vagy csak külön tesztelhető rétegbe... Itt most annyira egyszerű a model, hogy nem láttam értelmét külön teszteket írni rá. Mondjuk ezek a tesztek is nagyon egyszerűek lettek volna, ha úgy vesszük...
62

Gábor, én most visszaváltok kisbetűre ;)

szabo.b.gabor · 2014. Szep. 30. (K), 22.03
vitán felül jobb az OOP. procedurálisnál tisztában kell legyél az egész rendszerrel, fejben kell legyen minden.

OOP-nál megvannak a paramétereid típusai, az IDE meg megmondja, hogy milyen függvényeket használhatsz rajtuk, meg milyen adatok érhetők el.

lehet az OOP-t is szarul használni, de ha jól csinálja az ember, akkor nagyon jó.

procedurális programozáshoz supermennek kell lenned. csapatmunka pedig elképzelhetetlen, pain in the ass.
63

Akkor ezt vegyem úgy, hogy

H.Z. · 2014. Szep. 30. (K), 22.20
Akkor ezt vegyem úgy, hogy engem csak a kryptonit állíthat meg? :D
("procedurális programozáshoz supermennek kell lenned" - COBOL-ban, PL/I-ben dolgoztam valaha, ott nem volt jellemző az OOP ;) )
65

Típusosság

szabo.b.gabor · 2014. Szep. 30. (K), 22.57
javítom magam. csak akkor vagy supermen, ha php-ban programozol procedurálisan, lévén itt nincs típusosság.

tulajdonképpen php-ben a típusosság hiányának hátrányait tudod elfedni OOP-vel. ezen felül természetesen vannak egyéb előnyei is, amik miatt jó használni.
68

Akkor ezt vegyem úgy, hogy

inf3rno · 2014. Okt. 1. (Sze), 00.18
Akkor ezt vegyem úgy, hogy engem csak a kryptonit állíthat meg? :D


Ez így van. Lebuktál Clark! :D
69

vitán felül jobb az OOP.

inf3rno · 2014. Okt. 1. (Sze), 00.29
vitán felül jobb az OOP. procedurálisnál tisztában kell legyél az egész rendszerrel, fejben kell legyen minden.


OO kódban is szép számmal lehet találni procedurális elvek alapján írt kódrészleteket. Csak hogy egy példát írjak, az összes DTO feldolgozása ilyen. Maga a megközelítés nem feltétlen rossz, egyszerűen probléma függő, hogy hol jobb objektumokat használni és hol jobb adatstruktúrákat. Ezt a fejezetet érdemes elolvasni a clean code-ból, sokat lehet tanulni belőle.

Sokan nem veszik észre, hogy ez a két dolog egyáltalán nincs ellentétben. Az OO kiegészíti a procedurális megközelítést olyan helyeken, ahol hátrányos annak használata.

OOP-nál megvannak a paramétereid típusai, az IDE meg megmondja, hogy milyen függvényeket használhatsz rajtuk, meg milyen adatok érhetők el.


Én szerintem procedurálisan írt kódra is simán működik az automatikus kiegészítés. A PHP egy külön kategória, szerintem ne is beszéljünk róla. :D IDE-t nem használni szerintem szimpla szűklátókörűség. Én mindent abból csinálok, amit csak tudok.
77

Válasz a 75-re

Hidvégi Gábor · 2014. Okt. 1. (Sze), 11.57
Ez a 75-ösre egy válasz a két scripttel, a végén pedig kérdésekkel.

OOP:
<?php
  class db {
    private static $peldany;
    private $mysqli;

    public static function letrehoz() {
      if (!isset(self::$peldany)) {
        $c = __CLASS__;
        self::$peldany = new $c;
      }
      return self::$peldany;
    }
    function __clone() {}

    function __construct() {
      $this->mysqli = mysqli_init();
      $this->mysqli->options(MYSQLI_OPT_CONNECT_TIMEOUT, 5);
      $this->mysqli->options(MYSQLI_INIT_COMMAND, 'SET NAMES utf8');
      $this->mysqli->real_connect('localhost', 'root', 'jelszo', 'tigidi_teszt', '3306');
    }

    function lekerdez($_sql) {
      $vege = array();
      $eredmeny = $this->mysqli->query($_sql);
      while ($sor = $eredmeny->fetch_assoc()) {
        $vege[] = $sor;
      }
      $eredmeny->close();
      return $vege;
    }
  }

  class klassz {
    function __construct() {
      $this->db = db::letrehoz();
    }

    function metodus() {
      $sql = "SELECT * FROM nagy_tabla LIMIT 100;";
      $g = $this->db->lekerdez($sql);
    }
  }

  $klassz = new klassz;
  $ido = microtime(true);
  for ($i = 0; $i < 1000; $i++) {
    $klassz->metodus();
  }
  print (microtime(true) - $ido);
  print '<br>' . memory_get_peak_usage();
?>
Procedurális:
<?php
  function lekerdez($_sql) {
    global $link;

    $eredmeny = mysqli_query($link, $_sql);
    while ($sor = mysqli_fetch_assoc($eredmeny)) {
      $vege[] = $sor;
    }
    mysqli_free_result($eredmeny);
    return $vege;
  }

  function fuggveny() {
    $sql = "SELECT * FROM nagy_tabla LIMIT 100;";
    $g = lekerdez($sql);
  }

  $link = mysqli_init();
  mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, 5);
  mysqli_options($link, MYSQLI_INIT_COMMAND, 'SET NAMES utf8');
  mysqli_real_connect($link, 'localhost', 'root', 'jelszo', 'tigidi_teszt', '3306');

  $ido = microtime(true);
  for ($i = 0; $i < 1000; $i++) {
    fuggveny();
  }
  print (microtime(true) - $ido);
  print '<br>' . memory_get_peak_usage();
?>
Kérdéseim:
- mit jelent az, hogy fenntarthatóbb?
- mitől lesz fenntarthatóbb?
- mikortól éri meg újabb absztrakciós szintet bevezetni?
- a konkrét példához: mi az értelme a singletonoknak? Procedurálisan szükség van egy globális linkre, de azt azért nem olyan nehéz megállni, hogy máshol a kódban ne írjam felül.
78

Singleton egyesek szerint az

H.Z. · 2014. Okt. 1. (Sze), 12.01
Singleton egyesek szerint az ördögtől (vagy az őr dögtől?) való ;)
79

Tudom, és persze minden

Hidvégi Gábor · 2014. Okt. 1. (Sze), 12.14
Tudom, és persze minden helyen mást és mást írnak, ember legyen a talpán, aki el tudja dönteni, hogy mit is és hogyan szabad használni az OOP-ből.

A singleton ugye arra jó, hogy abból egynek szabad lennie a teljes kérés során. Tizenöt év tapasztalata alapján, ami alatt 1, azaz egy esetben kellett lecserélni az adatbáziskezelőt, el lehet mondani, hogy az adatbázis egy weboldal esetében elég fix dolog. Van-e értelme ezek után akár singletonnal, akár más módszerrel ebből objektumot gyártani, és pontosan mikor?
80

Köszi

vbence · 2014. Okt. 1. (Sze), 13.09
Maga az OOP nem cél, hanem eszköz. Könnynen belátható, hogy ha 8 véletlenszerűen kiválasztott funkció köré írjuk, hogy class azzal nem nyerünk semmit (maximum dezinformációt, ha jövőbeli önmagunk ellenségei vagyunk).

A cél, hogy minél magasabb rendű logikát tudjunk megfogalmazni. Ehhez elengedhetetlenek a mai eszközök (interfészek, nedajisten annotációk). Az OOP magát az eszközrendszert adja, amivel kifejezhetjük a logikát.


mit jelent az, hogy fenntarthatóbb?

Kevesebb ideig tart (olcsóbb) változtatások végrehajtása a kódon, a kód-minőség romlása nélkül. Később avul el az eredti kódbázis, későbbre tolódik a teljes újraírás szükségessége.

mitől lesz fenntarthatóbb?

Magasabb/több rétű logikai kapcsolatok jelenhetnek meg a kódban. (Pl annotációk révén).

mikortól éri meg újabb absztrakciós szintet bevezetni?

Általában akkor lesz gyanús, ha sok kezd lenni az ismétlődés a kódban. Ez nem feltétlenül copy-paste-et jelent, inkább ismételt logikai lépéseket.

a konkrét példához: mi az értelme a singletonoknak? Procedurálisan szükség van egy globális linkre, de azt azért nem olyan nehéz megállni, hogy máshol a kódban ne írjam felül.

Az utóbbi években ezért sem dívik már a singleton. Jelenleg a "globális állapot" ellen folyik a harc, ebből a szempontból nincs különbség a singleton (vagyis statikus adat) és egy globális változó között.

Amire mostanában törekszünk az, hogy a függőségek explicite le legyenek írva. Vagyis a fenti OO kód kb így nézne ki:
<?php  
  class db {  
    private $mysqli;  
  
    function __clone() {}  
  
    function __construct() {  
      $this->mysqli = mysqli_init();  
      $this->mysqli->options(MYSQLI_OPT_CONNECT_TIMEOUT, 5);  
      $this->mysqli->options(MYSQLI_INIT_COMMAND, 'SET NAMES utf8');  
      $this->mysqli->real_connect('localhost', 'root', 'jelszo', 'tigidi_teszt', '3306');  
    }  
  
    function lekerdez($_sql) {  
      $vege = array();  
      $eredmeny = $this->mysqli->query($_sql);  
      while ($sor = $eredmeny->fetch_assoc()) {  
        $vege[] = $sor;  
      }  
      $eredmeny->close();  
      return $vege;  
    }  
  }  
  
  class klassz {  
    private $db;
    function __construct($db) {  
      $this->db = $db;  
    }  
  
    function metodus() {  
      $sql = "SELECT * FROM nagy_tabla LIMIT 100;";  
      $g = $this->db->lekerdez($sql);  
    }  
  }  
  
  $db = new db();
  $klassz = new klassz($db);  
  $ido = microtime(true);  
  for ($i = 0; $i < 1000; $i++) {  
    $klassz->metodus();  
  }  
  print (microtime(true) - $ido);  
  print '<br>' . memory_get_peak_usage();
Ebben a kódban a későbbiekben két külön db példányt is használhatunk. Példányosíthatjuk az egyik klassz-t az egyikkel, a máikat a másikkal, az egyiken mondjuk átállítjuk a karakterkészletet a másikon hagyjuk az utf8-at stb).

A következő lépes, miután a globális adatoktól való függést eltávolítottuk, hogy ugyanezt tesszük az implementációtól való függéssel:

<?php  

  interface db {
    function lekerdez($_sql);
  }

  class mysql_db implements db {  
    private $mysqli;  
  
    function __clone() {}  
  
    function __construct() {  
      $this->mysqli = mysqli_init();  
      $this->mysqli->options(MYSQLI_OPT_CONNECT_TIMEOUT, 5);  
      $this->mysqli->options(MYSQLI_INIT_COMMAND, 'SET NAMES utf8');  
      $this->mysqli->real_connect('localhost', 'root', 'jelszo', 'tigidi_teszt', '3306');  
    }  
  
    function lekerdez($_sql) {  
      $vege = array();  
      $eredmeny = $this->mysqli->query($_sql);  
      while ($sor = $eredmeny->fetch_assoc()) {  
        $vege[] = $sor;  
      }  
      $eredmeny->close();  
      return $vege;  
    }  
  }  
  
  class klassz {  
    function __construct() {  
      $this->db = db::letrehoz();  
    }  
  
    function metodus() {  
      $sql = "SELECT * FROM nagy_tabla LIMIT 100;";  
      $g = $this->db->lekerdez($sql);  
    }  
  }  
  
  $db = new db();
  $klassz = new klassz($db);  
  $ido = microtime(true);  
  for ($i = 0; $i < 1000; $i++) {  
    $klassz->metodus();  
  }  
  print (microtime(true) - $ido);  
  print '<br>' . memory_get_peak_usage();
Az interfészek bevezetésével függetlenítettük a klasszt a db implementációjától. Így a jövőben készíthetünk egy pgsql_db osztályt, aminek a használatához nem kell változtatni a klassz-on. - Vagyis ha ma általánosan oldjuk meg a feladatot, holnap nem kell majd végigtúrni a kódot a legményebb rétegekig.

A refaktorálás költséges dolog, és ez a költség nem linárisan nő a kód komplexitásával.
81

singleton, globális változó stb.

H.Z. · 2014. Okt. 1. (Sze), 13.18
Ha kerülni akarom, hogy ötven szinten át, paraméterként utaztassak információkat, akkor hogy tudom a globális változókat, singletont, osztály szintű változókat megkerülni?

Régi nyűgöm: parancssori paraméterek. Két módon tudom kezelni őket:
1. Berakom valami globálisan elérhető változóba/osztályba/objektumba és az ezektől függő kódok onnan kérik le.
2. Minden létező objektumnak, függvénynek stb., létrehozáskor, híváskor átadom paraméterként vagy az összes értéket vagy csak a rá vonatkozókat.
Egyik sem tűnik túl jó ötletnek.
84

Sokmindentől függ

vbence · 2014. Okt. 1. (Sze), 14.25
A parancssori kapcsolókat tekinthetjük általánosabban konfigurációnak.

Fix paraméterek

Tételezzük fel, hogy a programod áll néhány szolgáltatásból, és a főprogramból, ami ezeket a szolgáltatásokat létrehozza, bekonfigurálja és összedrótozza egymással.

A főprogram paramétereinek egy része az egyes szolgáltatások konfigurációi lesznek (pl. adatbázis kapcsolat paraméterei), másik részük a szolgáltatások összedrótozására lesz hatással. Ilyen egy modul betöltése, ami alapesetben nem lenne a feldolgozási lánc része (mondjuk egy logger).

Ezek fix paraméterek, amiknek a neve és tipusa bele van égetve a főprogramba.


Dinamikus paraméterek

A legtöbb szolgáltatás használ valamiféle contextet, ahogy kapcsolatba lép a környezetnek az ő számára érdekes részével. A context része lehet egy általános kulcs-érték registry - általános paraméterek számára. Ezek tipikusan a rendszer mélyében fejtiuk ki a hatásukat, és viszonylag ritkán van rájuk szükség. Teljes értékű paraméterként ezek túl nagyra hízlalnák a szolgáltatás külső interfészét.

A context objektum az, ami eljut a szolgáltatás legbelső bugyraiba. Paramétereit a szolgáltatás inicalizálásakor kapja. Ezek a paraméterek névterekbe helyezhetők (meghatározott előtaggal elláthatók), így a főprogram a lehetséges értékek ismerete nélkül is csokorba szedheti őket és továbbíthatja a megfelelő szolgáltatásnak.
101

Kicsit később előszedem a

H.Z. · 2014. Okt. 1. (Sze), 18.36
Kicsit később előszedem a gépem, mobilról macerás... pythonból kiindulva, nálam a namespace is egy globális változó, ezért zavar ez az egész. De később megpróbálom példával illusztrálni, úgy talán érthetőbb lesz, mi bajom.

update: elővettem... :)
Na, szóval ha mondjuk olyat akarok, hogy van egy kapcsoló, aminek hatására többet vagy kevesebbet pofázik kis programom.
Itt viszonylag egyszerűnek tűnik a dolog, mert gyártok egy darab objektumot(????), akinek a feladata, hogy tolja ki magából az üzeneteket és csak neki kell átvennie valahogy, hogy sokat, kevesebbet vagy semmit ne kommunikáljon.
O.K., paraméter kérdése megoldva, de ha ez egyetlen objektum, akkor őt valahol globális változóban kellene tárolnom, hogy minden rendszer alkatrész ugyanazt a példányt tudja elérni.
És itt el is akadtam... akkor most merre tovább?
102

szóval elővettem... :)

H.Z. · 2014. Okt. 1. (Sze), 18.39
... (régebben mintha feljött volna az a topik is, amelyikben hozzászólást szerkesztett valaki. Én emlékszem rosszul? Na mindegy)
130

Régi nyűgöm: parancssori

inf3rno · 2014. Okt. 2. (Cs), 15.35
Régi nyűgöm: parancssori paraméterek. Két módon tudom kezelni őket:
1. Berakom valami globálisan elérhető változóba/osztályba/objektumba és az ezektől függő kódok onnan kérik le.
2. Minden létező objektumnak, függvénynek stb., létrehozáskor, híváskor átadom paraméterként vagy az összes értéket vagy csak a rá vonatkozókat.
Egyik sem tűnik túl jó ötletnek.


Ha nagyon sok szinten át kell utaztatni valamit, akkor elképzelhető, hogy rossz helyen hozod létre, vagy rossz a projekt struktúrája. Régebben én is elkövettem azt a hibát, hogy mindent kiszerveztem container-ekbe meg config fájlokba, aztán csodálkoztam, hogy ugyanígy járok... Ha nem tudsz mit kezdeni a helyzettel, akkor nyugodtan utaztass minden paramétert több szint mélységbe. Még így is könnyebben módosítható ez a megoldás, mint a globális névterezés...
82

Így a jövőben készíthetünk

Hidvégi Gábor · 2014. Okt. 1. (Sze), 13.48
Így a jövőben készíthetünk egy pgsql_db osztályt, aminek a használatához nem kell változtatni a klassz-on.
Akkor most hadd idézzem neked H.Z. kollega hozzászólását: Azért azt tudod, hogy ez "előre optimalizálás"? ;))))

A második kódod nekem hibásnak tűnik a "class klassz"-tól lefele.
87

Ellenkezőleg

vbence · 2014. Okt. 1. (Sze), 14.32
Ez pont az optimalizálás ellenkezője. Igyekszünk a lehető legáltalánosabban megoldani egy problémát - így kerüljük el a fölösleges függőseket, így lesz a lehető leghosszabb életű a kódunk.

Ami hibát találtam az a $db = new db(); - ami new mysql_db(); kéne legyen. De sosem az volt a cél, hogy valaki futtassa aszt a kódot.
88

Szükség van-e a klassz

Hidvégi Gábor · 2014. Okt. 1. (Sze), 14.35
Szükség van-e a klassz __construct() -jára?

Tegyük fel, hogy egy pgsql_db osztály is definiálva van. Kérlek, írj egy példát a használatára a fenti kódon belül.
90

JA, copypaste

vbence · 2014. Okt. 1. (Sze), 14.54
Igen, az első példában még jó... :) - de ugye nincs már edit gomb.
96

És mi van akkor, ha nem

Hidvégi Gábor · 2014. Okt. 1. (Sze), 15.46
És mi van akkor, ha nem térünk át pg-re, sem pedig egyéb más adatbáziskezelőre, mert mondjuk eleve csak MySQL van a tárhelyen, és tökéletesen kielégíti az igényeinket?
97

Igények

vbence · 2014. Okt. 1. (Sze), 16.13
Most lehet hogy kielégíti az igényeket, de nem tudod megjósolni, mit hoz a jövő. És ha ez a projekt kiválóan el van MySQL alapokon, lehet egy új projekted, más környezetben, ahol igen csak jól jönne, ha használhatnád a régen megírt modulodat, de a függőségek nem teszik ezt gazdaságossá.

Igyekszünk olyan szolgáltatásokat (modulokat) írni, amik a lehető legkevesebb függőséggel rendelkeznek (a lehető legáltalánosabban oldalak meg egy problémát), így a jelenlegi rendszerből kiemelve is megállják a helyüket, illetve minimális konfigurációval átilleszthetők egy másikba.

Persze vannak olyan körülmények ahol megéri minimális energia ráfordítással körmölni valamit, ami működik. - De tisztában kell lennünk, hogy ezt a kódot módosítani nem fogjuk, hanem az illető modult kidobjuk, és egy új implementáció fogja átvenni a helyét az első adandó alkalommal.
98

Sosem tudhatod, mit hoz a

Hidvégi Gábor · 2014. Okt. 1. (Sze), 17.14
Sosem tudhatod, mit hoz a jövő.

Ha például egy olyan cégnél dolgozol, amelyik abból él, hogy egy saját CMS-t gyárt, ennek a használati jogát adja el, és az ügyfelek kérhetnek személyre szabott dolgokat, akkor mindig a CMS-t fogod csiszolni, ezért célszerű általánosan elkészíteni bizonyos részeit egy idő után, amikor már látod az ismétlődéseket a kódban, hogy egyszerűen kielégíthesse a felmerülő igényeket. Ebben az esetben elképzelhetőnek tartom, hogy létezik olyan helyzet, amikor az általad vázolt OOP módszerrel érdemes dolgozni, ha a projekt egy bizonyos méret fölé nőtt.

Ha viszont általános szoftverfejlesztéssel foglalkozol, ahol nem tudod megmondani, hogy mi lesz a következő projekt, akkor a legnagyobb hiba, amit elkövethetsz, hogy homályos elképzelésekre alapozva fejlesztesz le általánosan modulokat. "Mi lesz, ha másik adatbázismotort kér a következő ügyfél?", "Mi lesz, ha nem csak relációs, hanem NoSQL adatbázisokat is támogatni kell?" és így tovább.
100

"Egy idő után"

vbence · 2014. Okt. 1. (Sze), 18.07
Igen, létezik túltervezés, ettől még nem húzhatjuk rá az ez ellen szóló érveket minden tervezére.

Már céloztam rá, szerintem nagyságrendekkel alábecsülöd egy komplex rendszer refaktorálásának költégét. Ha egy komponenst nem elég körültekintően tervezel meg, az ő interfésze rossz hatással lesz a vele kommunikáló komponensekre is; az alatta és felette dolgozó rétegekre is, a refaktorálás őket is kell majd érintse.

Nem egy homályos jövőkép alapján kell megtervezni egy modult, én ilyet nem mondtam. Egyszerűen el kell fogadni, hogy a jövő tartogat előre nem látható kihívásokat, ezért arra kell törekedni, hogy az adott feladatot a lehető legáltalánosabban oldd meg (így lesz a kódodon a legkevesebb béklyó).

Perzse, mindent túlzásba lehet vinni. - A végén az adott nyelv primitívei köré is wrappert akarsz majd írni, hogy azoktól se fügj. Kis jó tapasztalat (jó API-k használata) után megtalálható az egészséges arány (szándékosan nem középutat írok).
108

Ha van egy rendszerterv és

Hidvégi Gábor · 2014. Okt. 1. (Sze), 22.06
Ha van egy rendszerterv és egy határidő, az alapján könnyen meg lehet határozni, hogy a rendszerben milyen absztrakciókra van szükség. Enélkül viszont minden általánosítás pusztán spekuláció, és csak a kódot bonyolítja.

Egyszerűen el kell fogadni, hogy a jövő tartogat előre nem látható kihívásokat
Ez pont kimeríti a homályos jövőkép fogalmát. Erre minek és hogyan lehet tervezni előre?

Említetted korábban a globális változókat mint állapotot létrehozó gonosz dolgokat. Egy objektumnak ha van bármilyen saját változója, az pont ekvivalens ezzel, mert ettől neki is lesz állapota, azaz két véletlenszerű időpontban meghívva egy metódusát nem fogjuk ugyanazt az értéket kapni. Ha meg eldobjuk ezeket a belső változókat, pőre függvényeket kapunk, akkor pedig ugyanott vagyunk, mint a procedurális programozás.
109

Enélkül viszont minden

vbence · 2014. Okt. 1. (Sze), 23.35
Enélkül viszont minden általánosítás pusztán spekuláció, és csak a kódot bonyolítja.

Egy jobban szervezett kód egyáltalán nem bonyolultabb, sőt...

Ez pont kimeríti a homályos jövőkép fogalmát. Erre minek és hogyan lehet tervezni előre?

Nem azt a kérdést teszed fel, hogy "Mi lesz ha egyszer át kell térni pgsqlre?".

Egyszerűen észereveszed, hogy a kódod függeni fog a MySQLtől. Ezután a kérdés amit felteszel, hogy "Ésszerű energiaráfordítással megszabadulhatunk-e ettől a függőségtől".

... és a válasz gyakran igen. Ha például egy egyszerű kulcs-érték tárolóra van szükséged, amit MySQLben fogsz megvalósítani, miért ne követelne az interfész egyszerűen csak egy tömböt. A MySQL alapú implementációd pedig lehet egy ArrayAccess-t megvalósító osztály.

Kellemes mellékhatása, hogy ezzel a portolhatóbb kóddal oylan lehetőség is megjelenhetnek amire eddig nem goldoltál, pl működhet egy szimpla PHP-s tömbből, vagy valami shared memory megoldásból egy betü módosítása nélkül.

állapotot létrehozó gonosz dolgokat


Nem az állapot a probléma, a globális állapot az. Addig nincs baj, amíg a szkóp öröklődik, egy osztályon belül ez még kezelhető komplexitás.

A globális állapottal egyrészt az a probléma, hogy szűkíti a lehetőségeket. Ami globális állapotra támaszkodik abból sosem tudsz két (vagy több) példányt egymás mellett futtatni. A másik, hogy ezek a globális függőségek nem derülnek ki egy csomag API-jából. Magába a függvény kódjának forráskódjába kell belenézned, hogy lásd mi mást is kellene inicalizálni mielőtt ezt a dolgot használnád.

Ezt a videó hosszasan magyarázza:
http://www.youtube.com/watch?v=-FRm3VPhseI
111

Egyszerűen észereveszed, hogy

Hidvégi Gábor · 2014. Okt. 2. (Cs), 11.28
Egyszerűen észereveszed, hogy a kódod függeni fog a MySQLtől. Ezután a kérdés amit felteszel, hogy "Ésszerű energiaráfordítással megszabadulhatunk-e ettől a függőségtől".

... és a válasz gyakran igen.
Jelen pillanatban függök a kenyértől, ez éltet, a szeleteléshez vettem egy éles kést. Ha úgy gondolkodnék, mint te, akkor a következő kérdést tenném fel magamban: "Függök a kenyértől, de mi van akkor, ha egyszer jön egy élelmes cég, aki kókuszdiókat kínál? Egymilliárd óceániai lakos nem tévedhet, a kókuszolaj tele van vitaminokkal. Jó lenne beszerezni egy machetét, amivel tudok kókuszdiót felezni és kenyeret vágni!"

Mi van akkor, ha nem jön kókuszos cég? Mi van, ha kiderül, hogy nagyon drágán adja az árut? Van egy hatalmas machetém, amivel nehezebben lehet vékony szeleteket vágni a kenyérből, a régi késem meg már nincs meg, mert eldobtam.

Értem, amit mondasz, és azt is látom, hogy egy általános objektum átadása milyen előnyökkel jár, de egy problémával akkor kell foglalkozni, amikor felmerül. A MySQL-től függ a kódom? Nem baj, meg vagyok vele elégedve. A MySQL helyére bármi más beilleszthető, nevezhetjük adatforrásnak stb.

Singletonnal egyébként olyan globális objektumokat valósítottunk meg, amelyeknek nincs állapota, tipikusan ilyen az adatbáziscsatoló vagy a hibakezelő. A következő tervem, hogy ezeket szimpla függvényekké degradálom, mert szükség van az így nyert plusz sebességre.

Ez alapján általánosságban kijelenteni, hogy a singletonok vagy a goto utasítás rossz, nem lehet.
112

Singletonnal egyébként olyan

Poetro · 2014. Okt. 2. (Cs), 12.04
Singletonnal egyébként olyan globális objektumokat valósítottunk meg, amelyeknek nincs állapota, tipikusan ilyen az adatbáziscsatoló vagy a hibakezelő.

Azért ez nem teljesen igaz. Egy adatbáziscsatolónak is van állapota (csatlakozott az adatbázishoz, a csatoló paraméterei stb.), és ugyanez igaz lehet bármilyen másra is, amit singleton-ként használsz, holott nem gondolsz bele (főleg akkor tud ez fontos lenni, ha az adott singleton órákig, napokig, hetekig fut).
121

Szükséges

Hidvégi Gábor · 2014. Okt. 2. (Cs), 13.40
Az adatbáziscsatoló nélkül nem működne nálunk semmi sem, ezért nem számít, hogy van-e állapota. Ennyi erővel azt is lehetne mindig ellenőrizni, hogy van-e elég memória, az is egy állapot.
129

Ahol te machetét

vbence · 2014. Okt. 2. (Cs), 15.25
Ahol te machetét látsz, én egy svájci bicskát, amiből kifordíthatod a macsetét is ha kell, de amíg csak kenyeret akarsz vágni vele be sem kell csuknod.
133

A machete jó film :D :D :D

inf3rno · 2014. Okt. 2. (Cs), 15.48
A machete jó film :D :D :D
146

Mindig implementációban

BlaZe · 2014. Okt. 2. (Cs), 21.59
Mindig implementációban gondolkodsz, szerintem ezért nem érted az OOP-t. A megfelelő absztrakció itt az étkezés, nem a kenyér felszeletelése, elfogyasztása. Onnantól kezdve tudod cserélgetni az étkezést kenyér evésére, kókuszdió evésére, bármire, és nem fogsz éhenhalni. Ha a kenyértől függsz, akkor valóban csak nagyon nehezen váltasz majd át más kajára, mert komoly költségvonzata lesz. Ilyesmi a laza csatolás, többek között ezért használunk OOP-t.

A singleton általánosan nem rossz dolog, az implementációja okozhat problémákat, pl az általad is vázolt módszer eléggé nehézzé teszi a tesztelést.

A következő tervem, hogy ezeket szimpla függvényekké degradálom, mert szükség van az így nyert plusz sebességre.
Ha ez a sebességcsökkenés valóban ennyire érzékenyen érint, akkor érdemesebb lenne azon gondolkodni, hogy a PHP-t cseréljétek le egy kevésbé lassú nyelvre. Ha már a körültekintő, és szakmailag megalapozott választást szeretnéd reklámozni :)
149

Ha a sebesség lenne a lényeg

inf3rno · 2014. Okt. 2. (Cs), 22.27
Ha a sebesség lenne a lényeg a webalkalmazásoknál, akkor alacsony abszrakciós szintű nyelven - mondjuk C-ben - procedurálisan programozná őket mindenki. Nem ez a helyzet, mindenki magas absztrakciós szintű nyelvet és oo-t választ, és ez egyáltalán nem véletlen. PHP is nem véletlenül tért át az oo használatára. Nyilván ha driver-t akarok írni (nem akarok), akkor meg C-t választom (bár már nodejs-ben is láttam példát ilyesmire).
152

Állapot

Hidvégi Gábor · 2014. Okt. 3. (P), 11.20
Nem az állapot a probléma, a globális állapot az. Addig nincs baj, amíg a szkóp öröklődik, egy osztályon belül ez még kezelhető komplexitás.
Dehogynincs baj az állapottal, mivel minél több belső változója van egy objektumnak, annál nehezebb a debugolás. Ha például az ügyfél gépén/a szerveren hiba történik, úgy tudod csak reprodukálni, ha minden belső változót arra az értékre hozol, ami a hiba bekövetkeztekor volt.

Pontosan ugyanez a probléma a JS alapú alkalmazásokkal, ahol az állapot a kliensen egy változóban van. Nem elég egy url-t elküldeni a hibakereséshez, egy bizonyos sorrendben végig kell kattintgatni a felületet a bogár előcsalogatásához. Aztán a sorrendre vagy emlékszik az ügyfél vagy nem.
154

Más téma

vbence · 2014. Okt. 3. (P), 11.51
Amit te mondasz az egy egészen más téma / probléma.

De legyen...

Ha egy művelet elvégzéséhez 8 változóra van szükség, akkor a hiba reprodukálásához szükségünk van mind a 8-ra. Abban nem látok különbséget, hogy ezek egy funckió bemenő paraméterei (funckionális megközelítés esetén), vagy egy objektum adattagjai (oop).
157

Értem, tehát akkor az állapot

Hidvégi Gábor · 2014. Okt. 3. (P), 13.01
Értem, tehát akkor az állapot tekintetében hibakereséskor mind az OO, mind pedig a procedurális programozás ugyanazokkal a problémákkal küzd.
99

Általános

Hidvégi Gábor · 2014. Okt. 1. (Sze), 17.26
Az általam múltkor beküldött előadásban 12:38-nál hangzik el ~ a következő:
How can we possibly make things reliable that we don't understand? It's very-very difficult. I think professor Sussman made a great point: There's going to be this tradeoff as we make things more flexible and and extensible and dynamic, in some possible futures for some kind of systems we are going to make a tradeoff in our ability to understand their behavior and make sure that they are correct.
94

Csak hogy valami értelme is

inf3rno · 2014. Okt. 1. (Sze), 15.37
Csak hogy valami értelme is legyen a kódodnak...


$teszt = new nagy_tabla_sebessegteszt();
$teszt->futtat(new mysqli_db('localhost', 'root', 'jelszo', 'tigidi_teszt', '3306'));
$teszt->futtat(new pgsql_db('localhost', 'root', 'jelszo', 'tigidi_teszt', '12345'));
//...

class nagy_tabla_sebessegteszt
{

    function futtat(db $db)
    {
		$eredmeny = this->tesztel($db);
		$this->kiir($eredmeny);
    }

    protected function tesztel(db $db){
        $ido = microtime(true);
        for ($i = 0; $i < 1000; $i++)
            $sorok = $db->lekerdez('SELECT * FROM nagy_tabla LIMIT 100;');
		return array(
			'tipus' => get_class($db),
			'idotartam' => microtime(true) - $ido,
			'memoria_hasznalat' => memory_get_peak_usage()
		);
    }

    protected function kiir(array $eredmeny)
    {
        print $eredmeny['tipus'] . ': ' . $eredmeny['idotartam'];
        print '<br>' . $eredmeny['memoria_hasznalat'];
    }
}

interface db
{
    public function lekerdez($sql);
}

class mysqli_db implements db
{
    private $mysqli;

    function __construct($host, $user, $pass, $db, $port)
    {
        $this->mysqli = mysqli_init();
        $this->mysqli->options(MYSQLI_OPT_CONNECT_TIMEOUT, 5);
        $this->mysqli->options(MYSQLI_INIT_COMMAND, 'SET NAMES utf8');
        $this->mysqli->real_connect($host, $user, $pass, $db, $port);
    }

    function lekerdez($_sql)
    {
        $sorok = array();
        $eredmeny = $this->mysqli->query($_sql);
        while ($sor = $eredmeny->fetch_assoc()) {
            $sorok[] = $sor;
        }
        $eredmeny->close();
        return $sorok;
    }
}

class pgsql_db implements db
{
    //...
}

Ezekből a sorokból nagyjából látni, hogy többféle adatbázist akarok összehasonlítani, szóval sok értelme nincs lejjebb lapozni a kódban, hacsak nem érdekel a mérés, vagy lejjebb a lekérés, vagy még lejjebb az adatbázis kapcsolódás mikéntje.
$teszt = new nagy_tabla_sebessegteszt();
$teszt->futtat(new mysqli_db(...));
$teszt->futtat(new pgsql_db(...));
Nyilván a kód messze nem tökéletes, de legalább valami értelme van, amit le lehet írni OO-val, szemben a te kódoddal, ami teljesen értelmetlen volt. Én úgy látom, hogy amíg nem vagy tisztában legalább az OO alapjaival, addig nincs értelme tovább vitázni bármiről. Egyszerűen sajnálok erre órákat rászánni az életemből.
113

Minőségi kódok?

T.G · 2014. Okt. 2. (Cs), 12.08
Elsősorban Hidvégi Gábortól kérdezném, de persze többiek javaslata is érdekel. Tudnátok pl. a GitHub-on, vagy bármely más helyen olyan PHP projektet ajánlani megtekintésnek, amely nagyobb, mint amelyet másfél óra/12 óra alatt le lehet kódolni és nincsenek benne osztályok, ám ennek ellenére a kódja "szépen" néz ki. A szépet szándékosan idézőjelbe tettem, valószínűleg mindenki kicsit másként értelmezi a minőségi kódot, az érdekelne, hogy mik azok a kódok, amelyeket az adott kommentelő jónak tart. Abban az értelemben, amiben ő értelmezi a jót.

(OOP-re számtalan példa lenne, közhely de leírom, hogy, akik nem Symfony-znak, azok is előszeretettel nézegetik a Symfony forráskódját, mert annyira profi, annyira sok best practice van benne, hogy érdemes tanulmányozni. Kíváncsi vagyok, hogy PHP nyelven van-e említésre méltó, mely nem tartalmaz osztályokat?)
114

Drupal

Poetro · 2014. Okt. 2. (Cs), 12.15
Amikor még PHP-ztam, akkor azt mondtam volna, hogy a Drupal kódja szerintem szép, ugyanakkor nem olyan könnyen követhető mint egy OOP kód (mivel rengeteg függvényről van szó, amiket egyszerűen a modul nevével prefixelnek).
116

Érdekes

T.G · 2014. Okt. 2. (Cs), 12.40
Köszönöm, nem is tudtam. Érdekes, tényleg számtalan fájl van, amely függvényeket sorakoztat fel, de azért számtalanban fájlban van osztálydefiníció, akár örökléssel is. pl. https://github.com/drupal/drupal/blob/7.x/includes/batch.queue.inc
Az mondjuk látom, hogy az autoloader-nek nehéz dolga van: https://github.com/drupal/drupal/blob/7.x/includes/bootstrap.inc
132

Ahogy néztem a globális

inf3rno · 2014. Okt. 2. (Cs), 15.42
Ahogy néztem a globális névtérbe is írnak rendesen, ami persze addig nem baj, amíg van koncepció arra, hogy elkerüljék az ütközést. Összességében sokkal használhatóbb, mint amilyen procedurális kódokat eddig láttam. Nem kis erőfeszítés lehetett leprogramozni... Teszteket nem látok, de elméletileg minden függvényt le lehet tesztelni különböző paraméterekkel, vagy a globális változók beállításával...
115

Sajnos nem, a saját kódok nem

Hidvégi Gábor · 2014. Okt. 2. (Cs), 12.36
Sajnos nem, a saját kódok nem publikusak, nagyon nyílt forrású szoftvert meg nem használok. A Poetro által említett Drupalt pont tegnap néztem, és én is csodálkoztam, hogy procedurális.
117

Ne saját kódot!

T.G · 2014. Okt. 2. (Cs), 12.51
Nem arra gondoltam, hogy saját, vagy általad használt kódot mutassál, hanem a miért nem jó valami téma helyett arról is szólhatna a beszélgetés, hogy miért jó valami.

A Drupal annyiból sánta példa, hogy azért az, hogy nincsenek benne osztályok nem egészen állja meg a helyét: https://api.drupal.org/api/drupal/classes Illetve Poetro a régi verziót linkelte be, a utolsó verzió (8.x) Zend Framework alapokon nagyon durván OOP. Azaz a Drupal fejlesztői ezzel a verzióváltással dobták a procedurális megközelítést.
118

C

Hidvégi Gábor · 2014. Okt. 2. (Cs), 12.56
Bocs, az kiment a fejemből, hogy a Drupal 6.0 forrását néztem.

Ha procedurális kódot szeretnél látni, akkor nézd meg bármelyik linuxos lib forrását (ha ismered a C-t), esetleg az OpenBSD-ét (itt az bin, sbin, usr.bin, usr.sbin könyvtárakon belül a fájlok neve melletti verziószámra kell kattintani). A beépített httpd kódja például nagyon jól olvasható és érthető.
119

PHP?

T.G · 2014. Okt. 2. (Cs), 13.04
Értem én, de azért a Weblabor közösségének túlnyomó része webfejlesztéssel foglalkozik. Illetve lehet, hogy tévedek, de a legnépszerűbb itt a PHP. Általában te is kezdő PHP fejlesztőknek adsz itt tanácsot. Emiatt vagyok kíváncsi arra, hogy ha az OOP-t nem használjuk, akkor hová lehetne eljutni?
120

Azt hittem, hogy csak neked

Hidvégi Gábor · 2014. Okt. 2. (Cs), 13.37
Azt hittem, hogy csak neked kell bizonyíték. Olyat sajnos nem ismerek. Egyébként az OpenBSD C forrásai eléggé hasonlítanak a PHP-re, igazából bárki megérti őket, mert a változók és a függvények nevei beszédesek.

Ami szerintem fontos, az a modularitás, arra nagyon ügyeltem a fő munkámban a kód utóbbi legnagyobb refaktorálásakor, hogy a modulok között csak vertikális függőség lehet, horizontális nem, azaz a modulok kölcsönösen ne hívhassák egymást.
122

Tehát nincs vállalható PHP-s példa?

T.G · 2014. Okt. 2. (Cs), 13.54
Jól értem, hogy évek óta a Weblabor-on harcolsz azért, hogy az ide látogatók/az itt kérdést feltevők ne használjanak OOP-t, mert szerinted az felesleges. De ha szeretnék tőled kérni egy szép példát, amely megfelel azoknak az elvárásoknak, amelyeket hirdetsz, akkor nem tudsz ajánlani egyetlen egy konkrét példát sem? Egyetsem? Drupal 6 a Wikipédia szerint 2008 februárában jött ki. Drupal 8 dobta az általad hirdettet módszereket.

Több ismerősöm azért hagyta itt a Weblabor-t, mert komolytalannak érezte, hogy állandóan arról megy a vita, hogy az OOP jó-e vagy sem. Ez nem csak egy személynél fordult elő.

Tényleg úgy hirdeted a nézeteidet, hogy nincsen egy vállalható példa?
124

Persze

Hidvégi Gábor · 2014. Okt. 2. (Cs), 14.44
A saját bő tíz éves tapasztalatom mind ezt mutatja, továbbá a hivatkozott C-ben írt könyvtárak és operációs rendszerek is, hogy lehet procedurálisan működő, nagy, jól strukturált és moduláris kódot írni.

Az, hogy valamiben sokan hisznek, nem jelenti azt, hogy igaz is. A középkorban máglyán égették el az eretnekeket, akik például nem ismerték el Isten létezését vagy azt állítotották, hogy a Föld nem lapos. Mindenhol ezt tanították és mindenhol ezt hitték. Az utóbbi állítás azóta bebizonyosodott, hogy hamis, mégis sokakat hurcoltak meg miatta.

inf3rno kódjából és a fenti, C nyelvű példákból világos, hogy vannak esetek, ahol a procedurális átláthatóbb, karbantarthatóbb és egyszerűbb kódot eredményez. A libek és operációs rendszerek fejlesztői áttérhettek volna akár C++-ra is, de nem tették. Emellett a 2009-ben, a Google által patronált Go nyelvben tudatosan nincs típushierarchia és öröklődés (sem kivételkezelés). Aki ezek után komolytalannak tartja, hogy azon megy a vita, hol és mikor érdemes OOP-t használni, az tudatlan vagy tapasztalatlan a témában.

Egy fontos kérdést tettem fel, amit eddig még senki sem válaszolt meg: mikortól éri meg az OOP eszközei által nyújtott flexibilitást választani a procedurális megközelítés helyett?
125

Vicces...

T.G · 2014. Okt. 2. (Cs), 15.00
Vicces, hogy egy informatikai portálon a publikusan elérhető példák helyett középkori hasonlatokkal találkozhatunk. :) Mert, akárhogy nézzük, azok a nézetek, amiért ma a Weblabor az ami, az nem szól másról, mint ne használj OOP-t és akkor olyan kódot tudsz írni, mint mások írtak hat és fél évvel ezelőtt. Azok, akik azóta már egészen másként kódolnak.
127

Re: C-ben írt könyvtárak és operációs rendszerek

complex857 · 2014. Okt. 2. (Cs), 15.09
Ha már C meg nagy méretű projectek, érdemes lehet elolvasni az LWN ezen sorozatát:
Object-oriented design patterns in the kernel part1, part2.
Esetleg tanulmányozni a GLib által használt konvenciókat ahogy struktúrák neve köré szervezett makrók és funkció nevekkel dolgozik, pl.: GObject.
GLib a GTK project része amin a fél opensource desktop világ ül.

Mindezzel csak azt akarom mondani, hogy önmagában pro vagy kontra példák félek nem fognak sokat segíteni a másik fél (akármelyik oldalon is érvel az ember) meggyőzésében.
148

A c egy nagyon jó nyelv.

BlaZe · 2014. Okt. 2. (Cs), 22.22
A c egy nagyon jó nyelv. Alacsonyszintű, gépközeli, annak teljesítményét a legmesszemenőbbekig kihasználó, nagyon kis erőforrásiényű feladatok implementálására, illetve ilyen blokkok beágyazására. Mint pl kernel, driver írás, alacsony szintű messaging protocol stb készítése. Ezt senki nem is tagadta soha. Viszont már nem nagyon írnak benne komoly üzleti logikát megvalósító rendszereket, főleg nem olyat, aminek a fejlesztési ciklusa olyan rövid, mint ami manapság szokott lenni a continuous delivery és társai világában. Az ügyfél a lehető legrövidebb befektetéssel (idő és anyagiak) és kockázattal (bugmentes) szeretne számára pénzt hozó alkalmazásokat futtatni. Ezekben a tulajdonságokban a c nagyon komolyan lemarad egy magasabb szintű nyelvhez képest, mint például a ma nagyon menő Java és C#. Ennek a magasabb absztrakciós szintnek természetesen van egy költsége, de ez már messze nem olyan nagy, hogy ne lenne érdemes megfizetni. Sőt, a mai okos JIT compilerek világában már tudnak meglepő eredmények is születni.
126

Absztrakció

Hidvégi Gábor · 2014. Okt. 2. (Cs), 15.05
Külön ajánlanám figyelmedbe azt, amit Linus Torvalds ír a C++-ról (a lényeg a ... után):
C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes:
(...)
- inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app
A tanulság, hogy nagyon meg kell gondolni, miből csinálunk absztrakciót.
131

Én még mindig a PHP-ről beszélgetnék...

T.G · 2014. Okt. 2. (Cs), 15.41
Én nagyra becsülöm Linus Torvalds-t, ahogy Bjarne Stroustrup-ot is. És, hogy a témánál maradjunk Rasmus Lerdorf-ot is. Ám azt nem látom, hogy mindez hogy jön ide? Minden nyelvnek megvan a maga közege, értelmetlen a C értékrendjébe beleerőszakolni a PHP-t. Mert nem ugyanarra hozták létre a két nyelvet.

Jól értem, hogy azt mondod, hogy mert a C-ben nincs OOP, azért nem kell a PHP-ben OOP szerint programozni? De ha ez így is lenne, akkor rajtad kívül ezt más miért nem tudja? Én a 113-ban arra gondoltam, hogy számtalan kétes projektet fogsz linkelni. Arra nem gondoltam volna, hogy azt fogod írni, hogy nem tudsz PHP-s példát írni. Csak akkor tényleg nem értem, hogy miért beszélünk egyáltalán erről. Ha nulla példa van az egyik verzióra és végeláthatatlan a másik verzióra, akkor miért is hangos a Weblabor a nulla verziós módszertanról?
134

Ám azt nem látom, hogy mindez

Hidvégi Gábor · 2014. Okt. 2. (Cs), 16.03
Ám azt nem látom, hogy mindez hogy jön ide?
A 126-os bejegyzésem címének azt adtam, hogy "Absztrakció". Utána az első mondat végén zárójelbe odaírtam, hogy a lényeg a ... után van. Ezt a lényeges dolgot itt most megismétlem:
inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app
vbence is írt a túltervezésről, de azt nem, hogy mikortól következik ez be. Ebből következik az, amit írtam, hogy
A tanulság, hogy nagyon meg kell gondolni, miből csinálunk absztrakciót.
És az, hogy minél kevesebb absztrakciót használunk, annál jobb.

Jól értem, hogy azt mondod, hogy mert a C-ben nincs OOP, azért nem kell a PHP-ben OOP szerint programozni?
Rosszul érted, nem tudom, mi alapján jutottál erre a következtetésre. A C-ben írt szoftvereket azért hoztam fel, hogy bizonyítsam: van helye a procedurális programozásnak.

Ha nulla példa van az egyik verzióra és végeláthatatlan a másik verzióra, akkor miért is hangos a Weblabor a nulla verziós módszertanról?
Mert az "Egymilliárd légy nem tévedhet" elv nem racionális, hanem érzelmi alapú, és ezzel engem nem lehet meggyőzni.
135

Mert az "Egymilliárd légy nem

inf3rno · 2014. Okt. 2. (Cs), 16.28
Mert az "Egymilliárd légy nem tévedhet" elv nem racionális, hanem érzelmi alapú, és ezzel engem nem lehet meggyőzni.


Csak úgy kíváncsiságból, téged mivel lehet meggyőzni?

- Megtanulni nem vagy hajlandó.
- Megbeszéltük, hogy elméletben miért éri meg oo-t használni, teljes mértékben ignoráltad.
- Rámutattunk, hogy renteget profi programozó használja akár 30+ év tapasztalattal a háta mögött, és PHP-ben szinte csak olyan projektek rendelkeznek minőségi kóddal, amelyek használják. Nyilván ezt is ignorálod.

Gondolom nehéz beismerni, hogy "egymilliárd légy" helyett Hidvégi Gábor az, aki téved...
136

Mellébeszélés

T.G · 2014. Okt. 2. (Cs), 16.41
Tehát még egyszer, hogy a mondandóm lényege ne vesszen el: évek óta attól hangos a Weblabor, hogy ne használjunk OOP-t. Kértem példákat olyan projektekre, amelyek megfelelnek ennek az ajánlásnak, de nem kaptam. Egy darabot sem. Nem csak, hogy nem kaptam, hanem a jelenlegi fórumhozzászólások alapján nincs is. Kivéve egy hat és fél évvel ezelőtt projekt, amely azóta már jelentősen megváltott.

A fentiek fényében én minden mást mellébeszélésnek érzek. A nulla és a rengeteg közti különbséget nem lehet elintézni szerintem annyival, hogy az egymilliárd légy elve miatt ez semmit sem számít.

Nem az a kérdés, hogy melyik módszert lehet hibásan használni, mert mindegyiket lehet. A kérdés az, hogy helyes használat mellett mit lehet kihozni belőle? Negatív példát mindenre lehet hozni, a legjobb dolgokban is lehet hibát találni, ha az ember célja az, hogy hibát találjon benne. Ezért sajnálom, hogy nem kaphatunk pozitív példákat.
137

Ne ess túlzásokba, ez csak

H.Z. · 2014. Okt. 2. (Cs), 17.07
Ne ess túlzásokba, ez csak Gábor "mániája", meg néha én szoktam értetlenkedni e témában. Hogy ettől lenne hangos az oldal...
138

Túlzás?

T.G · 2014. Okt. 2. (Cs), 17.59
És az ilyen vélemények is csak véletlenek?

https://twitter.com/tikaszvince/status/496360999000477696
139

full off

H.Z. · 2014. Okt. 2. (Cs), 18.29
Nem vagyunk egyformák. Én egyetlen, nekem nem tetsző fórum tag miatt nem hagynék ott (kivéve, ha ... de ezt inkább hagyjuk! :) ) egy fórumot. Ha nincs más megoldás, akkor greasemonkey szkript, oszt jónapot.
Hogy nem nagyon van érdemleges társalgás a weblaboron, az nagyobb probléma szerintem.
Na mindegy, ebbe nem akarok belemenni, mert csak flame-et generál, másra nem jó ez a téma.
140

Én egyetlen, nekem nem tetsző

inf3rno · 2014. Okt. 2. (Cs), 18.46
Én egyetlen, nekem nem tetsző fórum tag miatt nem hagynék ott egy fórumot.


Lehet én emlékszem rosszul, de mintha ... :D

Hogy nem nagyon van érdemleges társalgás a weblaboron, az nagyobb probléma szerintem.


Ez szerintem érdemleges társalgás volt. Remélem egyszer és mindenkorra sikerült lezárni ezt az oo vs procedurális témát, mert már lassan az agyamra megy. Maradt 99 ;-)
142

Megírnád privátban, hogy

H.Z. · 2014. Okt. 2. (Cs), 19.01
Megírnád privátban, hogy kire/mire emlékszel?
Emlékeim szerint egyetlen tag miatt még soha. Vagy ha mégis az 8-10 éve lehetett...
(Egyetlen és tag - nem tulajdonos, nem főmufti etc.)
143

Ja az más. Azt hittem a

inf3rno · 2014. Okt. 2. (Cs), 19.02
Ja az más. Azt hittem a főmufti is tagnak számít...
144

Azért nem mindegy, hogy a

H.Z. · 2014. Okt. 2. (Cs), 19.05
Azért nem mindegy, hogy a vendég hülye vagy a házigazda.
145

Ezek a viták pár hetente

bamegakapa · 2014. Okt. 2. (Cs), 19.18
Ezek a viták pár hetente lezajlanak (a téma attól függ, Gábor épp minek megy neki), mindig elhangzanak kb. ugyanazok az érvek. Annyiból lehet érdemleges, hogy szakemberek megnyilvánulnak, és mondjuk ezúttal OOP témában csöpögtetnek kicsit tudásukból, de nem hiszem, hogy erre ez a legproduktívabb mód.

Szerintem baromi unalmas, és a Weblaboron tényleg nincs más szinte, csak ezek. Minden más kikopott.

Mondhatnád, hogy senki se kötelez, hogy megnyissam az oldalt. Jogos lenne.
147

Szerintem baromi unalmas, és

inf3rno · 2014. Okt. 2. (Cs), 22.08
Szerintem baromi unalmas, és a Weblaboron tényleg nincs más szinte, csak ezek. Minden más kikopott.


Azért nem minden más, néha van 1-2 jó blogmark. Bár ennyi erővel twitter-en is mehetne az egész...

Szerintem az egyedüli plusz, amit ez az oldal adhat bármelyik külföldihez képest, hogy magyar. Erre koncentrálva a magyar nyelvű cikkeket, blog bejegyzéseket kellene előtérbe helyezni. Én jelenleg abban látom a legnagyobb problémát, hogy a publikálás nem működik (ill. baromira megnehezített) az oldalon, így nincs friss tartalom, nincs miről beszélni, és nincs miért ide jönni. A Gábor által újra és újra előhozott témák szerintem csak ennek a tünetei. Ha nem lennének, valószínűleg már rég teljesen kihalt volna az oldal, így meg azért néha idegyűlnek az emberek a zajra...
150

Tudom, hogy nem te

zzrek · 2014. Okt. 3. (P), 08.44
Tudom, hogy nem te vagy a kompetens a témában, de mivel a te hozzászólásoddal kapcsolatban jutott az eszembe, itt kérdezem meg:

Ha mondjuk látok egy jó cikket angolul, és lefordítom, az megjelenhet cikk formájában itt, a Weblaboron? Nem ismerem az újságírás szabályait, de ha nem nehézkes engedélyt kérni az eredeti cikk készítőjétől, akkor én szívesen fordítanék le egy pár olyan cikket, amit érdekesnek tartok (ha már elolvastam, miért is ne fordítanám le), ha ezzel a Weblabort támogatom. (Annyira nem tartom magam profinak, hogy önálló cikket írjak, de ez simán beleférne)
153

Talán két éve kérdeztem,

bamegakapa · 2014. Okt. 3. (P), 11.48
Talán két éve kérdeztem, akkor azt a választ kaptam, hogy ez nem tartozik a profilba.

Azóta persze változhatott :).
174

Én is úgy emlékszem, hogy

inf3rno · 2014. Okt. 3. (P), 18.48
Én is úgy emlékszem, hogy Ádám nem szeret fordításokat megjelentetni, inkább a saját cikkeket támogatja. Egyébként nem annyira nehéz összefoglalót írni egy vagy több angol cikk alapján. Nekem inkább az szokott gondot okozni, hogy mindig baromi hosszú és túl részletes lesz. Most próbálok változtatni ezen, és nem annyira kibontani egy-egy témát, inkább csak a lényegre koncentrálni.
155

A néhány jó blogmark miatt

bamegakapa · 2014. Okt. 3. (P), 12.11
A néhány jó blogmark miatt írtam bele a "szinte" szót a mondatba. De azért ez valóban édeskevés egy szakmai oldaltól. Hiába van magyarul, ha nem közvetít értéket. Mi is csak azért vagyunk itt, mert ideszoktunk egyszer.

Én jelenleg abban látom a legnagyobb problémát, hogy a publikálás nem működik (ill. baromira megnehezített) az oldalon

Miért írna bárki cikket bármiről, ha úgyis szét lesz trollkodva az egész azzal, hogy az egész web szar ahogy van, minden programozó nyálcsorgató divatbirka, az OOP a háttérhatalom propagandája, stb. Jobb helyeken az ilyeneket kimoderálják egy idő után. És nem azért, mert más a véleménye, vagy mert szembemegy a trendekkel, azzal semmi baj.

A Gábor által újra és újra előhozott témák szerintem csak ennek a tünetei

Én is hajlottam erre, de a mellékelt ábra azt mutatja, sokan azok közül, akik alkalmasak lennének a tartalom készítésére, pont miatta léptek le innen. Akik itt maradtak, azoknak sincs már gusztusa ide tartalmat gyártani.

Ha nem lennének, valószínűleg már rég teljesen kihalt volna az oldal, így meg azért néha idegyűlnek az emberek a zajra

Őszinte leszek: szerintem ez hullagyalázás. Vagy hagyjuk elmenni, vagy üssük ki és élesszük újra. Utóbbi egy radikális beavatkozás.
159

Miért írna bárki cikket

Hidvégi Gábor · 2014. Okt. 3. (P), 13.26
Miért írna bárki cikket bármiről, ha úgyis szét lesz trollkodva az egész azzal, hogy az egész web szar ahogy van, minden programozó nyálcsorgató divatbirka, az OOP a háttérhatalom propagandája, stb.
Légyszi mutass már pár cikket, ahol ez történt! Köszönöm.

de a mellékelt ábra azt mutatja, sokan azok közül, akik alkalmasak lennének a tartalom készítésére, pont miatta léptek le innen
Sokan? Nem is gondoltam, hogy ekkora hatalmam lenne : )

Vagy hagyjuk elmenni, vagy üssük ki és élesszük újra.
Sok sikert kívánok, senki sem fog vissza, hogy készíts egy alternatívát.
164

Gábor, szerintem azért

Joó Ádám · 2014. Okt. 3. (P), 13.48
Gábor, szerintem azért gondolkozz el ezeken a visszajelzéseken.
165

Jó.

Hidvégi Gábor · 2014. Okt. 3. (P), 13.55
Jó.
166

Ha érdekel, olvass utána. Nem

bamegakapa · 2014. Okt. 3. (P), 13.59
Ha érdekel, olvass utána. Nem hiszem, hogy neked feltűnik, mivel te csinálod :).

Olybá tűnik, mintha a személyes blogodként tekintenél erre az oldalra.

Például itt ez a téma, ami arról szólna, ki hogy értette meg az OOP-t (ha jól látom a címből). Már korábban is felhívtam a figyelmedet, hogy azért, mert az OOP-ről beszélgetnek emberek, nem jelenti azt, hogy szerencsétlenek csak arra várnak, hogy megjelenjen az igazság fanatizált harcosa, aki felvilágosítja őket tévedéseikről.

Sokan? Nem is gondoltam, hogy ekkora hatalmam lenne : )

A hatalom nem jó szó. A buszról is sokan leszállnak inkább, ha valakivel nem szívesen utaznak együtt különféle okokból.

Sok sikert kívánok, senki sem fog vissza, hogy készíts egy alternatívát.

Alternatívát mire?
169

Ha érdekel, olvass utána. Nem

Hidvégi Gábor · 2014. Okt. 3. (P), 14.20
Ha érdekel, olvass utána. Nem hiszem, hogy neked feltűnik, mivel te csinálod :).
Így nem több, mint egyszerű lejáratás, ami nem engem minősít.

Alternatívát mire?
Fuss neki még egyszer, hogy ezt mire válaszoltam.
176

Nem lejáratni akarlak, mivel

bamegakapa · 2014. Okt. 3. (P), 19.57
Nem lejáratni akarlak, mivel a tevékenységed mindenki számára látható, nyilvános.

Én az szeretném, ha abbahagynád a trollkodást. Vagy ásd bele magad a témába, tanulmányozd át végre egyszer rendesen, amit a többiek ezerszer leírtak, vagy hagyd az egészet a fenébe, fejlessz, ahogy szerinted jó, csak ne prédikálj.

Vagy jelentsd ki, hogy ez itt mostantól a HidvégiLabor, és itt csak az lesz, ami neked tetszik.

Fuss neki még egyszer, hogy ezt mire válaszoltam.

Okkal kérdeztem.
177

Nagy tevedes

Pepita · 2014. Okt. 3. (P), 22.36
Rosszul gondolod, hogy Gábor saját oldalaként használná a WL-t. Talán a legtöbb értékes tartalmat küldi be, de mindenképp nagyon sokat.
Más kérdés, hogy kissé szokatlan véleménnyel van az OOP-ről és ennek időnként hangot ad - és nem lehet meggyőzni. Ő ilyen, de ettől még jó srác.
Ha te is inkább értékes tartalmak írásával foglalkoznál, kevésbé zavarna. Ehelyett sajnos inkább lehurrogni szeretsz másokat.

Akkor most ki is a troll?...
178

Nem az a problémám, hogy

bamegakapa · 2014. Okt. 3. (P), 23.17
Nem az a problémám, hogy szokatlan véleménye van, és az se lenne probléma, ha időnként hangot adna neki. De ezt is már többször elmondtam én is, mások is. Nem érdekel, hogy amúgy jó srác-e, nem is értem, hogy jön ez ide. Mint emberrel, nyilván semmi bajom vele, nem is lehet, mivel nem ismerem.

Ha te is inkább értékes tartalmak írásával foglalkoznál, kevésbé zavarna.

Nyilván ha egész nap maláj kurvákkal szórakoznék, akkor se zavarna. Megint nem értem, hogy jön ez ide.

Ki ír itt értékes tartalmakat egyébként? Több hónapos/éves nem ér.

Ehelyett sajnos inkább lehurrogni szeretsz másokat.

Remek emberismerő vagy, gratulálok. Lelepleztél. Lehurrogni szeretek másokat, és viszályt szítani, bárhol járok. Le a kalappal. De ettől még jó srác vagyok, tényleg.

Meg kell hajoljak furmányos érveid előtt, tényleg nagy tévedésben voltam! Remekül vezetted le.
186

Minden relatív :)

Pepita · 2014. Okt. 5. (V), 16.03
időnként
Szerinted nem? Ha valami visszatérő, ismétlődő, akkor mindenképp időnként fordul elő. :)
Ki ír itt értékes tartalmakat egyébként?
Ez igaz, hogy mostanában szinte senki. De épp Gábor küld be legalább jó blogmarkokat.
Lehurrogni szeretek másokat, és viszályt szítani, ...
Én nem sarkítottam ki ennyire, de ahogy gondolod. Mindenesetre időnként előfordul, ami szerintem zavaróbb, mint OOP-ről vitatkozni.
187

A blogmarkokat azért ne

bamegakapa · 2014. Okt. 6. (H), 13.05
A blogmarkokat azért ne vegyük már teljesítménynek egy szakmai oldaltól. Jó mellékes tartalom lehet, de beküldeni egy blogmarkot nem igényel különösebb energiabefektetést, és nincs hozzá szükség egy külön weboldalra.

Én nem sarkítottam ki ennyire, de ahogy gondolod. Mindenesetre időnként előfordul, ami szerintem zavaróbb, mint OOP-ről vitatkozni.

Igyekszem akkor komolyan venni, amit mondasz és így reagálni. Szerintem összekevered a kritizálást a lehurrogással. A szándékaim konstruktívak. Ha zavar a tevékenységem, adj neki hangot nyugodtan, és szívesen meghallgatom a közösség véleményét ezzel kapcsolatban. Eddig nem kaptam negatív visszajelzést, csak azoktól, akiket kritizálni mertem. Nem félek majd megtenni a szükséges lépéseket, ha kiderül, hogy destruktív vagyok az oldalra/közösségre nézve. Megsértődni sem fogok.
188

Szerintem inkább pozitív

Pepita · 2014. Okt. 8. (Sze), 17.42
Szerintem inkább pozitív hozzászólásokra lenne szükség.
Tőled ilyet ritkán látni, ha a szándékod konstruktív is, sokszor nem ez jön le a hozzászólásaidból.
De ez az én véleményem, és nem akartam személyeskedni.
189

Semmi gond a

bamegakapa · 2014. Okt. 8. (Sze), 19.15
Semmi gond a személyeskedéssel, van, amikor annak is helye van.
190

Igen

Hidvégi Gábor · 2014. Okt. 8. (Sze), 19.45
Ha elfogytak az észérvek.
191

Na ez jó volt így a nap

bamegakapa · 2014. Okt. 8. (Sze), 23.14
Na ez jó volt így a nap végére ;).
192

Személyeskedés

Hidvégi Gábor · 2014. Okt. 9. (Cs), 08.43
193

Megragadnám az alkalmat, hogy

bamegakapa · 2014. Okt. 9. (Cs), 12.38
Megragadnám az alkalmat, hogy ismét belinkeljem ezt a remek posztert, ha már így előhoztad az érvelési hibákat.

Két dolog.

Egyrészt, mielőtt számonkéred valakin ezeket, nézz körül a saját házad táján. Különben sok értelme nincs, sőt maga az érvelési hibák emlegetése is érvelési hibává válik. És ezt most nem azért mondom, mert "nem is, hanem te vagy a hülye". Hátha segít.

Másrészt, ezeket racionális, észérvekre épülő, professzionális vitákban van értelme alkalmazni, illetve számon kérni. Egy kocsmai verekedésben például helye van az ököl használatának, még ha úriember nem is verekszik. A megfelelő eszközt a megfelelő helyen, megfelelő időben kell használni.
194

Rossz kifogás

Hidvégi Gábor · 2014. Okt. 9. (Cs), 13.48
Szakmai oldalon minden nem racionális vita teljesen fölösleges és káros, ugyanígy észérvek helyett strómankodni és személyeskedni is, mert ez mindenképp megakadályozza a normális társalgást. Az, hogy valaki nem ért meg valamit, és kérdéseket tesz fel, még nem halálos bűn, és voltak egypáran, akik tudtak normálisan érvelni, válaszolni. Rengeteg más paradigma és eszköz áll a rendelkezésünkre, innentől kezdve pedig semmiképp sem állja meg a helyét, ha valaki egyoldalúan egyvalami mellett érvel.

Az, hogy te ezt kocsmai verekedésnek véled, és szétoffolod és személyeskedsz, lejáratsz, még nem jelenti azt, hogy ez így is van és más is kíváncsi rá.
195

Tehát van az a pont, amikor

bamegakapa · 2014. Okt. 9. (Cs), 14.02
Tehát van az a pont, amikor már te is alkalmazod? Nincs vele bajom, csak érdeklődöm. Vállalok mindent, amit írtam, gondolkozz el rajta az ellentámadás helyett.

Ha már csak birkózni és magyarázkodni akarsz, abban nem kívánok részt venni.

Továbbra is tartom, hogy a normális társalgást és a racionális vitát már rég ellehetetlenítetted, mire én megérkeztem. És nem csak ebben a topikban.
196

Tehát van az a pont, amikor

Hidvégi Gábor · 2014. Okt. 9. (Cs), 14.06
Tehát van az a pont, amikor már te is alkalmazod?
Ezt mi alapján kérded?

Továbbra is tartom, hogy a normális társalgást és a racionális vitát már rég ellehetetlenítetted, mire én megérkeztem. És nem csak ebben a topikban.
Ezt támaszd alá, mert anélkül továbbra is csak személyeskedés és lejáratás.
197

Abbahagyni

Poetro · 2014. Okt. 9. (Cs), 14.33
Szerintem ezt itt ezen a ponton kéretik abbahagyni.
198

Rendben

Hidvégi Gábor · 2014. Okt. 9. (Cs), 14.34
Részemről vége.
199

+1

Pepita · 2014. Okt. 10. (P), 15.42
...
163

Vagy hagyjuk elmenni, vagy

Joó Ádám · 2014. Okt. 3. (P), 13.46
Vagy hagyjuk elmenni, vagy üssük ki és élesszük újra.


Én inkább a transzplantációt vélem találó képnek, mert egy működésképtelen szervezetet hiába ütsz ki, úgyis leáll újra. Tény, hogy a műtét hosszú, a hozzátartozók pedig tűkön ülnek a váróban, de attól még ez a megfelelő eljárás.
167

Valóban jobb hasonlat.

bamegakapa · 2014. Okt. 3. (P), 14.00
Valóban jobb hasonlat.
151

évek óta attól hangos a

Hidvégi Gábor · 2014. Okt. 3. (P), 09.25
évek óta attól hangos a Weblabor, hogy ne használjunk OOP-t. Kértem példákat olyan projektekre, amelyek megfelelnek ennek az ajánlásnak
Kaptál elég komoly példákat. Az, hogy nem ismered a C és a PHP közti hasonlóságot, nem az én problémám. Mint ahogy az sem valós érv, hogy ha én nem ismerek olyan nyílt forrású, php-s, procedurális projektet, akkor ilyen nem is létezik, és emiatt nekem nincs igazam.

Nem az a kérdés, hogy melyik módszert lehet hibásan használni, mert mindegyiket lehet. A kérdés az, hogy helyes használat mellett mit lehet kihozni belőle?
inf3rno két kódján keresztül – ha hajlandó bárki is megnézni – (számomra) egyértelmű, hogy a procedurális rövidebb, egyszerűbb, könnyebb karbantartani. Igaz, hogy egy feladatot tud, bejelentkeztetni egy felhasználót, de annak maradéktalanul megfelel. Ezzel szemben az OOP kód jóval összetettebb, szétszórtabb – bár előnye, hogy jóval rugalmasabb lehet. Viszont az eredeti feladatkiírásban sehol sem szerepelt, hogy ennek a követelménynek mennyire kell megfelelnie.
156

Komoly példák?

T.G · 2014. Okt. 3. (P), 12.19
Hidd el, nem fogom a C programozói portálon az ottani emberektől számon kérni, hogy miért nem OOP-t használnak. Pedig biztos jó flame-t lehetne indítani ezzel ott is. :) Ismerem a hasonlóságokat, ahogy a különbségeket is. Azt viszont tényleg nem látom, hogy egy C-hez készített példa miért lenne magyarázat egy PHP-s kérdésre.

És, hogy valamiben igazat adjak neked, illetve legyen egy közös pont. Én is mindenkit arra biztatok, hogy C-ben ne OOP szerint programozzon, az ott tévútra viszi az embert. Ellenben PHP esetén már más a véleményem.

Az a baj, hogy az általad nem tetszett elvekre állandóan negatív példákat hozol, mert képtelen vagy egy darab pozitív példával is előállni, ami alátámasztaná, hogy van-e bármi jogalapja azoknak az irányelveknek, amelyeket mantraként ismételsz.

Nem is az a kérdés, hogy létezik-e megtekinthető procedurális projekt PHP nyelven, hanem az, hogy az állításaidat egyáltalán nem tudod alátámasztani. Nem a saját érveidet véded, hanem a másik érveit támadod. Szerintem ez rendkívül rossz vita stílus.

Vegyük sorba, hogy én milyen érveket nem fogadtam el: egy móricka projekt, egy hat és fél évvel ezelőtti projekt és egy nem az adott nyelven készült projekt. Vége a listának. Szerintem szakmailag felelőtlenség csupán ilyen érvek mellett arról beszélned, hogy az OOP-vel bármilyen gond lenne.

Éppen a Drupal a legjobb válasz erre az értelmetlen vitának a lezárására. Igen, hét évvel ezelőtt PHP nyelven sokkal kevesebben használtak osztályokat. Lehetett használni, de kevesebb kényelmi funkció állt rendelkezésre, mint ma. Ám ma a 8-as Drupal teljes mértékben OOP.
158

Azt viszont tényleg nem

Hidvégi Gábor · 2014. Okt. 3. (P), 13.20
Azt viszont tényleg nem látom, hogy egy C-hez készített példa miért lenne magyarázat egy PHP-s kérdésre.
Az világos, mint a nap, hogy nem értetted meg. Csak azt próbáltam meg szemléltetni, hogy mind PHP, mind pedig C nyelvben lehet procedurálisan fejleszteni. Mivel ma is van rengeteg aktívan fejlesztett C projekt, ebből következik, hogy a procedurális programozásnak van helye – PHP-ben is.

Az a baj, hogy az általad nem tetszett elvekre állandóan negatív példákat hozol, mert képtelen vagy egy darab pozitív példával is előállni, ami alátámasztaná, hogy van-e bármi jogalapja azoknak az irányelveknek, amelyeket mantraként ismételsz.
Tudom, hogy már eléggé elburjánzott a téma, de azért próbáld meg elolvasni, amit írtam. A kedvedért idézem az idei első hozzászólásomat, aminek a mondanivalóját utána megismételtem legalább egyszer:
A végső OOP-s megoldás 15 kilobájt és 27 fájlból áll. Minden modulja cserélhető (munkamenet, állandó tár kezelése, hasítékfüggvény stb.), minden érték változóból jön. Ez nyilván ott előny, ahol szükség van a különböző részek cseréjére, mert nem elégedettek valamelyikkel, vagy pedig több módszert használnak.


Ám ma a 8-as Drupal teljes mértékben OOP.
És ebből az következik, hogy ez jobb? Honnan tudod, hogy nem csak a közösségi nyomás miatt tértek át rá? Korábban egy rakat érvet hoztak fel az OOP ellen.

Más: örülnék annak, ha befejeznéd a személyeskedést, és valódi érveket hoznál fel. vbencében azt becsülöm, hogy ő észérveket használ.
160

A C-ben és a PHP-ban annyi a

BlaZe · 2014. Okt. 3. (P), 13.39
A C-ben és a PHP-ban annyi a közös, hogy a PHP is C syntaxot használ. És itt vége is, a PHP mindenben teljesen más. Értelmetlen felhozni ezt a hasonlatot, mert nem létezik, amiről beszélsz.

Kódminőséget LOC-ra mérni pedig az egyik legnagyobb butaság, ami létezik. Ne csodálkozz, hogy erre senki nem csapott a homlokára :)

Szerintem tök igaza van amúgy, én is úgy érzem, hogy egy épkézláb érvet sem tudsz hozni valójában, csak üres frázisokat puffogtatsz. Ezért vonul ki mindenki ebből a vitából, mert értelmetlen és szakmaiatlan. Látszik, hogy nem ismered azt, amit támadsz, így azért nehéz ebből tartalmas vitát kihozni.
161

Szerintem az egyik fő baj az,

bamegakapa · 2014. Okt. 3. (P), 13.42
Szerintem az egyik fő baj az, hogy Gábor úgy gondolja, jól érvel, és észérveket használ. Ezért aztán nincs is értelme az egésznek.
168

Procedurális paradigma

Hidvégi Gábor · 2014. Okt. 3. (P), 14.09
Procedurális paradigma szempontjából nincs eltérés a kettő között, a memóriamenedzsment, a fordítás időpontja itt irreleváns.

A kevesebb kód könnyebben átlátható és karbantartható.
170

Procedurális paradigma

BlaZe · 2014. Okt. 3. (P), 14.37
Procedurális paradigma szempontjából nincs eltérés a kettő között, a memóriamenedzsment, a fordítás időpontja itt irreleváns.
Elég nagyvonalúan elmentél amellett, hogy melyik nyelv mire való :) Pedig az a lényeg. Ilyen alapon szinte minden nyelv ugyanolyan, hisz a legtöbben van váltózó, lehet függvényt írni, paramétereket átadni... Ennyi a közös a C-ben és a PHP-ban kb.

A kevesebb kód könnyebben átlátható és karbantartható.
Ez egy téves állítás.
171

Paradigma

Hidvégi Gábor · 2014. Okt. 3. (P), 14.50
Programozási paradigma – itt egy szó nincs arról, hogy egy nyelv mire való. Nem is értem, hogy miért gondolod ezt relevánsnak?
172

Fentebb írtam. Azért, mert

BlaZe · 2014. Okt. 3. (P), 15.15
Fentebb írtam. Azért, mert azzal próbálod alátámasztani az álláspontod, hogy de hát a C még mindig megy. Megy, de hol. Kernelek, driverek, alacsony szintű libek, toolok stb készülnek benne, amire a felhasználói, vagy business értéket szállító megoldások ráépülnek. Manapság szinte kizárólag erre használják. Teljesen más dinamikájú fejlesztéseket végeznek benne. Amellett, hogy az alkalmazási területein kiemelt fontosságú, hogy a megoldás a lehető leggyorsabb, és legkisebb erőforrásigényű legyen, ezért a gép felől nézve csak egy adott absztrakciós szint felett van valós alternatívája. Ez egy nagyon jelentős különbség. Azon az absztrakciós szinten, ahol mi dolgozunk, már vannak nagyon erős alternatívái, amikkel szemben a C már nem állja meg a helyét. Tehát amit van értelme vizsgálni, ha nyelvet (vagy akár paradigmát) akarsz választani, az a felhasználás. Nem véletlenül PHP-ban dolgozol C helyett. Azért teszed, mert magasabb absztrakciós szintet nyújt. Ezért mondtam, hogy nincs értelme összehasonlítani őket, mert semmi közös nincs bennük. Annyi valóban van, amennyit az előbb írtam, de ez igaz pl az OO paradigmára is. Mégse mondjuk azt, hogy a Java olyan, mint a C. Pedig a Java is alkalmazza a procedurális paradigma minden elemét.
175

Annyit hozzátennék, hogy egy

inf3rno · 2014. Okt. 3. (P), 19.00
Annyit hozzátennék, hogy egy keretrendszer használatával eleve még magasabb absztrakciós szintről indulsz, és így nyilván még könnyebb összekötni a megrendelő igényeit - amiket magas absztrakciós szinten fogalmazott meg valamilyen emberi nyelven - a kóddal. Ezért van az, hogy egy magas absztrakciós szinten megfogalmazott problémát sokkal könnyebb és gyorsabb magas absztrakciós szintű eszközökkel megoldani (pl php, oo, symfony), mint alacsony absztrakciós szintű eszközökkel (pl c). Ennek teljesítményben általában van valamekkora ára, de pénzügyileg sokkal jobban jön ki a megrendelő, ha fizet egy PHP fejlesztőnek, hogy csinálja meg a projektet symfony-ban x nap alatt, mintha fizet egy C fejlesztőnek, hogy csinálja meg a projektet x hónap alatt baromi gyorsra, valószínűleg jóval magasabb órabérért...

Gábor, csak egy kérdés, tudod, hogy mi az, hogy magas meg alacsony absztrakciós szint? (Anélkül ui. nem lehet megérteni, amit itt összehordunk.)
162

Drupal

bamegakapa · 2014. Okt. 3. (P), 13.43
Az adott cikkben épp arról van szó, hogy bár nem használnak classokat (akkoriban még a PHP-ban gyerekcipőben járt a támogatás), de OOP szerint fejlesztenek. Később át is tértek ugye classokra, amikor a PHP felnőtt az ő magas elvárásaikhoz.
180

Az idézett dokumentum T.G.

pp · 2014. Okt. 4. (Szo), 02.01
Az idézett dokumentum T.G. állításait támasztja alá.

"És ebből az következik, hogy ez jobb?"

Nem, ebből azt következik, hogy ha az egyik legnagyobb nemzetközi PHP-s fejlesztő közösség meghoz egy ilyen döntést, akkor érdemes lehet elgondolkodni azon, vajon miért tethették ezt.

Persze ez csak lehetőség, ha valaki nem akar, akkor nem él vele.

pp
181

Szembesítés

T.G · 2014. Okt. 4. (Szo), 08.13
Miután az elmúlt években mindenféle észérvet figyelmen kívül hagytál nehéz úgy újabb érvet felhozni, hogy az ne érintse a személyeskedést.

Én valóban ledöbbentem, amikor azt írtad, hogy nem tudsz PHP-s példát hozni, nem ismersz olyan nem általad írt kódot, amely megfelel azoknak az elvárásoknak, amiket itt hirdetsz.

Véleményem szerint ez annyira abszurd, annyira döbbenetes, hogy ha másként nem, akkor szembesítéssel kell erre felhívni a figyelmedet.

Azt gondolom, hogy mielőtt valaki megkérdőjelezhetetlenül harcol egy álláspont mellett, akkor előtte tájékozódik, a lehetőségekhez képest minél több véleményt begyűjt, majd azok vizsgálata után kialakítja a saját álláspontját.

De nekem úgy tűnik, hogy jelen esetben ez kimaradt. Mivel nem ismersz olyan projektet, amelyet az előtt néztél volna meg, hogy a saját véleményedet ennyire határozott véleménnyé formáld, így mi másra gondolhatnék, mint hogy a véleményed kialakítása előtt nem tájékozódtál?

Nehéz ezt személyeskedés nélkül minősíteni, a politikai korrektséget turbó fokozatba kapcsolva, azt kell mondanom, hogy függetlenül az adott témától, függetlenül az itt lévő emberektől, nagyon nagy általánosságban az a véleményem, hogy bármely témában, akár informatikában, akár az életnek bármely más területén, ha az ember megfelelő tájékozódás nélkül harcol a saját igazáért, akkor az nagy mértékű szakmaiatlanság.

Mielőtt persze sorolnál nagy felfedezőket, feltalálókat, hogy ők is a saját korukban meglepő állításaikkal döbbenetet váltottak ki, majd az idő végül őket igazolta, akkor azért gyorsan meg kell jegyeznem, hogy az a nézet, hogy használjuk a tíz évvel ezelőtti módszereket az nagyon messze van a forradalmi újítástól.

UFF
182

Van személyes ismerősöm

H.Z. · 2014. Okt. 4. (Szo), 09.35
Van személyes ismerősöm (egykori munkatársam), aki saját bevallása szerint pokolba kívánja az összes OO nyelvet, pedig nagyon nem hülye.
Megtanulták, használják, mert ez egy ilyen világ, ahol elvárás, hogy minden objektum orientált legyen, de szinte csak a hátrányait látják.
Az is igaz, hogy neki (k) nem az OO elvekkel van gondjuk, hanem a performanciára gyakorolt hatásával.

Félre ne értsen senki: nekem e témában nincs igazán véleményem, nincs elég gyakorlatom benne, csak azt akartam jelezni, hogy vannak még páran, akik nem szeretik igazán az objektumokat :)

Az mellékesen jutott eszembe valamelyik hozzászólásról, hogy a tapasztalataim szerint aki nem a piacra, sok ügyfélnek fejleszt, hanem egyedi megrendelésre, vagy pláne ha belső fejlesztést végez, akkor nagyon ritka az adatbázis motor cseréje a szoftver életében.
Egykori munkahelyemen az adatbázis cseréje, teljes újraírás nem fordult elő.
183

Az adatbázis cseréje téma

inf3rno · 2014. Okt. 4. (Szo), 09.53
Az adatbázis cseréje téma elég érdekes. Amíg nincs rá lehetőséged, hogy könnyen megtegyed, addig általában eszedbe sem jut. Nagyobb rendszereknél CQRS + event sourcing esetében viszont szabadon lehet kísérletezni, hogy milyen adatbázist választasz query céljára. Szóval abban az esetben én teljesen életszerűnek tartom, hogy gyorsan cserélődnek az adatbázisok és sokat kipróbálsz, hogy megnézd melyikkel gyorsabb 1-1 query. Ha már performanciáról van szó, 1-1 lekérés sebessége nagyban befolyásolja azt is.

Találtam egy idézetet arról, hogy miért jött létre a C++:
In C++ you can define something, call it a matrix, you define a subscript operator. If you don’t want rectangular matrixes you can get pentadiagonal matrices, triangular matrices that’s the kind of stuff that people... the expert in that field are interested in. And you build that set of concepts and then you program it directly. It’s easier to program, it’s easier to debug and sometimes it’s even easier to optimize for performance when you are expressing the notions at the higher level, at the level where an expert in the field operates, rather than trying to have the expert in the field, say the physicist, also be an expert in dealing with the hardware, with the computer. There are fields still where you have to have a physicist and a computer scientist to get the work done, but we would like to minimize those because the skill sets are not the same. So you want to lift from the hardware towards the human level.

why-the-programming-language-c-is-obsolete

Nagy vonalakban arról volt szó, hogy a nem kifejezetten programozó szakemberek is le tudjanak könnyen programozni bármit.

Ezt a wikipedia is alátámasztja:
The formal programming concept of objects was introduced in the 1960s in Simula 67, a major revision of Simula I, a programming language designed for discrete event simulation, created by Ole-Johan Dahl and Kristen Nygaard of the Norwegian Computing Center in Oslo.[13] Simula 67 was influenced by SIMSCRIPT and C.A.R. "Tony" Hoare's proposed "record classes".[11][14] Simula introduced the notion of classes and instances or objects (as well as subclasses, virtual methods, coroutines, and discrete event simulation) as part of an explicit programming paradigm. The language also used automatic garbage collection that had been invented earlier for the functional programming language Lisp. Simula was used for physical modeling, such as models to study and improve the movement of ships and their content through cargo ports. The ideas of Simula 67 influenced many later languages, including Smalltalk, derivatives of LISP (CLOS), Object Pascal, and C++.


A Simula előtt az MIT-n meg a mesterséges intelligencia csoportot mondják a fő ötletadónak. Helyesbítek, a Simula volt az első oo nyelv: http://www2.latech.edu/~box/ase/tp/Per%20Kjeldaas%20Research%20Paper%20.pdf a feltalálói pedig Turing díjat kaptak. Elég érdekes a szöveg, valami katonai nukleáris számításokat akartak egyszerűbben megoldani vagy mi a szösz :D Nekem az jön le, hogy kezdetben nem is igazán fogták fel sem ők, sem a szakma, hogy általánosan használható bármilyen probléma modellezésére ez a fajta megközelítés. Kellett 3 év amíg lecsapódott a dolog, és kijött a Smalltalk nyelv...
184

OOP performancia

BlaZe · 2014. Okt. 4. (Szo), 14.42
Az is igaz, hogy neki (k) nem az OO elvekkel van gondjuk, hanem a performanciára gyakorolt hatásával.
Valójában ez is egy jó vitaalap :) Az OOP alapvetően 2 ponton tud performancia problémákat okozni.

Az egyik az, hogy a sok objektum (akár) elszórva (is) található a memóriában, és az objektumgráf bejárása (az objektumok egymásra hivatkozása) cache missekben jelentkezik. Ez valóban nagyon komoly dolog tud lenni. Pl egy 1G memóriaterületet lineárisan és teljesen random bejárva a különbség egészen elképesztő: lineárisan kb 12G/s, random esetén ez az érték csupán 0,5G/s (saját laptopomon mértem, mezítlábas c-vel egy szép nagy long tömböt bejárva). Akit bővebben érdekel a téma, az érdekes találatokat kaphat pl memory mountain-re keresve. Szóval ez egy valós probléma lehet. De ez minden olyan adatszerkezetre igaz, ahol pointerekkel mutogatunk dinamikusan allokált blokkokra. Ennek a problémának az eltüntetése mély tudást igényel a programozótól mind a CPU (pl cache, prefetcher), mind az oprendszer működését tekintve (memória allokáció, page kezelés). (Google: cache locality) Tény, hogy ezen ismeretek birtokában egyszerűbb dolga van az embernek egy alacsony szintű nyelven hatékonyabb programot írni, mint egy magasabb szintűben, ahonnan by design nincs rálátás pl az architektúra szintű dolgokra (pl Java, PHP, Python stb). Ami pl Javanál az ilyen problémákon akár segíteni is tud, az - irónikus módon - a garbage collection. Mivel az a referenciák mentén járja be az objektumgráfot, a young gc az ide-oda másolgatással akár csökkenteni is tudja a cache missek számát. Gil Tene (ő az Azul agya, az ő találmánya az Azul parallel gc algoritmusa) egyik előadásában mondott olyat, hogy a memóriafoglalás leghatékonyabb módja a gc. Érdekes gondolat, és van is benne valami :)

A másik fekete bárány a sok virtual call a polimorfizmus miatt. Ez ugye arról szól, hogy nem directben egy megadott (rögzített) címen lévő függvényt, metódust hívunk meg, hanem egy pointeren keresztül egy indirekt hívást valósítunk meg. Az interface mögé bújtatott és felülírt metódusok mind ilyenek. Ez a CPU szintjén egyrészt egy plusz dereference-ként jelenik meg, de ez a kisebb probléma. A nagyobb, hogy a CPU szeret előre dolgozni, és megpróbálja kitalálni merre fog folytatódni a program futása (branch prediction). És ha van rá kapacitása, végre is hajtja előre az utasításokat. Ha jól tippelt, ez sokat javíthat a teljesítményen. Ha nem, akkor sajnos az egész pipelinet el kell dobni, és nulláról kell végrehajtania az utasításokat, ami természetesen komoly érvágás a teljesítmény szempontjából. Az indirekt hívások ebben a tippelgetésben értelemszerűen nem sokat segítenek, mert legrosszabb esetben mindig egy másik helyen lévő kódot kell végrehajtani, mint amire a proci számít (ez azért nem túl valószínű). Az Intel pl pont az OOP programok terjedése miatt sokat fejlesztett a branch prediction algoritmusain, manapság elég hatékonyan tud tippelni. Illetve itt a dinamikus (JIT) compilerek komoly előnyben vannak a static compilerekkel szemben a futás közbeni context infók megléte miatt. A compiler látja, hogy milyen elérhető implementációi léteznek pl egy interface-nek, és a virtual callokat ki tudja cserélni direkt hívásokra, vagy akár be is tudja inline-ozni a teljes metódust, ha szerencsénk van (és ha rövid metódusokat írunk a spagettikód helyett). És ezt még tudja bonyolítani. Ezek Javaban léteznek, de biztos más hasonló elven működő runtime esetén is hasonlóan működnek. Van egy javaban írt háttérrendszer, amihez az általunk írt rendszer kapcsolódik. Ők nap elején kb 5ms válaszidőt, az időben előre haladva pedig ennek kb a felét garantálják. És azért nem a legegyszerűbb dolog, amit művelnek. Szóval kicsit bonyolultabb már a helyzet annál, minthogy kijelentsük, hogy az OOP, Java, vagy akármilyen komolyabb magasszintű nyelv lassú.

Én összességében 2 ponton látom a performancia problémák okát. Első helyen a performance tesztek hiányában, vagy azok szakszerűtlen értelmezésében, megvalósításában. Ha ez nincs, akkor értelmetlen lassúságról, gyorsaságról beszélni. Nagy általánosságban persze, vannak dolgok, amik természetesen teszt nélkül is nyilvánvalóak. Második helyen pedig a programozók tudásában. Ha ezek a helyükön vannak, akkor utána lehet azon vitatkozni, hogy az OOP bottleneck-e, vagy sem.
185

Nem tudok érdemben

H.Z. · 2014. Okt. 4. (Szo), 15.43
Nem tudok érdemben hozzászólni, max. a saját elképzeléseimről tudnék beszélni, de az meg nem feltétlenül egyezik a valósággal.
Amikor utoljára ilyesmit boncolgattam, az még a Turbo Pascal 5.5 idején volt. Annak a kódján elég jól látszott a plusz kód, ami az osztályok miatt keletkezett.
Azóta eleve nem jellemző a bináris kód, mint kimenet, inkább valami interpreteres izé + JIT, ott meg...
270

Én valóban ledöbbentem,

inf3rno · 2015. Feb. 13. (P), 08.56
Én valóban ledöbbentem, amikor azt írtad, hogy nem tudsz PHP-s példát hozni, nem ismersz olyan nem általad írt kódot, amely megfelel azoknak az elvárásoknak, amiket itt hirdetsz.


Én közben találtam olyan projektet, ami szinte teljesen procedurálisnak tűnik. A jQuery az :D Külsőre ez nem látszik, de úgy nézem, mintha egyetlen prototípusba tuszkolnának bele mindent. Így a fluent interface-nél nincs problémájuk, mert az gyakorlatilag magától megy. A kód átláthatóságot úgy oldották meg, hogy modulokra bontották szét az egészet, mindegyik modul ugyanazt a prototípust bővíti (meg magát az osztályt is statikus dolgokkal). A motor alatt tehát nagyon sok minden procedurális megközelítéssel van megírva. Csak egy példa, ami a prototípusba ír:

	find: function( selector ) {
		var i,
			len = this.length,
			ret = [],
			self = this;

		if ( typeof selector !== "string" ) {
			return this.pushStack( jQuery( selector ).filter(function() {
				for ( i = 0; i < len; i++ ) {
					if ( jQuery.contains( self[ i ], this ) ) {
						return true;
					}
				}
			}) );
		}

		for ( i = 0; i < len; i++ ) {
			jQuery.find( selector, self[ i ], ret );
		}

		// Needed because $( selector, context ) becomes $( context ).find( selector )
		ret = this.pushStack( len > 1 ? jQuery.unique( ret ) : ret );
		ret.selector = this.selector ? this.selector + " " + selector : selector;
		return ret;
	},
	filter: function( selector ) {
		return this.pushStack( winnow(this, selector || [], false) );
	},
	not: function( selector ) {
		return this.pushStack( winnow(this, selector || [], true) );
	},
	is: function( selector ) {
		return !!winnow(
			this,

			// If this is a positional/relative selector, check membership in the returned set
			// so $("p:first").is("p:last") won't return true for a doc with two "p".
			typeof selector === "string" && rneedsContext.test( selector ) ?
				jQuery( selector ) :
				selector || [],
			false
		).length;
	}
Baromi furcsa oo-s szemmel megnézni, ettől függetlenül befutott projekt. Nem véletlen, hogy sosem szerettem a kódjában turkálni szemben a prototype.js-el, ami teljesen oo volt (most nem tudom mi van vele).

Úgy került látókörbe, hogy most én is fluent interface-el kínlódok, leginkább azzal, hogy a collection-ön és az item-en is ugyanazokat a metódusokat meg lehessen hívni, és ne kelljen ehhez egyedi collection-öket definiálni minden class-hez. Vegyes gyűjteményeknél fogalmam sincs, hogy mit csináljak: vagy error-t dobok, vagy nem hívom meg az olyanokat, amiknél nincs meg az adott feature. jquery az utóbbit követi ha jól tudom.
272

Prototípusba?

zzrek · 2015. Feb. 13. (P), 20.53
Én nem nézegettem a JQuery kódját, de az itt miből látszik, hogy ez a példa a prototípusba ír?
273

Ami körülötte van az egy

inf3rno · 2015. Feb. 14. (Szo), 03.00
Ami körülötte van az egy jQuery.fn.extend, ahol a jQuery.fn a prototípus az extend meg kiegészíti ezekkel. (Lehet, hogy ez a rész éppen statikusba ír, passz, nem fogom most előkeresni.) Összességében nagyjából annyi történik, hogy definiálnak egy sereg nem feltétlen összetartozó függvényt, amit beszórnak a prototípusba. De teljesen ugyanezt a hatást elérhetnénk úgy is, hogy külön definiáljuk őket, aztán `fn.call(selection, p1, p2, ...)`-al hívjuk meg, csak akkor a selection-t nem tudnánk fluent interface céljára használni. A jQuery az oo programozás meggyalázása szerintem egy hatalmas god object-el, amit csak azért hoztak létre, hogy a fluent interface meg legyen támogatva. Egyébként a maga módján zseniális.
274

Kösz

zzrek · 2015. Feb. 14. (Szo), 18.35
OK, már azt hittem nem értek valamit, de így már oké. Szerintem egy kicsit túl maximalista vagy. Vagyis le a kalappal előtted, hogy ilyen maximalista vagy :-)
280

Á annyira nem. Egyébként

inf3rno · 2015. Feb. 19. (Cs), 13.48
Á annyira nem. Egyébként semmi bajom a jquery-vel, ki van tesztelve, jó, használom én is, és értem, hogy miért válaszották ezt az utat. Mondhatjuk azt, hogy jogosan is tették. Egyszerűen egy procedurális lib, és a fluent interface-t így volt a legegyszerűbb ráheggeszteni. Oo szempontból finoman szólva nem a legszebb megoldás, de mivel nem oo lib, mindössze egy osztály van benne, ezért ennek semmi jelentősége sincsen.
271

Találtam egyet neked, a

Hidvégi Gábor · 2015. Feb. 13. (P), 16.18
Találtam egyet neked, a népszerű PHPMailert, ez egy tipikus procedurális kód.
275

Tipikus procedurális kód?

T.G · 2015. Feb. 15. (V), 09.23
A tipikus procedurális kódra mennyire jellemző, hogy tele van private/protected/public kulcsszavakkal? Igaz, abban egyetértünk, hogy erre a kódra erőltetett lenne azt mondani, hogy tipikus OOP kód, illetve az is biztos, hogy a clean code elveit messziről kerüli.

Számomra ez az a kód, amit akármennyire is hasznosnak tartunk, tipikus ellenpéldája annak, amit én szeretnék előállítani. Szerintem ez a kód nagyon messze van a széptől. Kíváncsi lennék, hogy a fejlesztőnek mi a véleménye a clean code-ról?
276

Szerinted attól lesz egy kód

Hidvégi Gábor · 2015. Feb. 15. (V), 09.41
Szerinted attól lesz egy kód OOP, hogy szerepelnek benne a private/protected/public/class kulcsszavak?
277

Fordítva!

T.G · 2015. Feb. 15. (V), 10.17
Azért, mert használsz láthatósági megkötéseket még a kódod nem lesz OOP kód.
Ám, ha használsz láthatósági megkötéseket, a kódod már nem tipikus procedurális kód.
278

A C-ben is használhatsz

Hidvégi Gábor · 2015. Feb. 15. (V), 11.02
A C-ben is használhatsz láthatósági megkötéseket, mégis írhatsz benne tisztán procedurális kódot. Az ne zavarjon meg, hogy PHP-ban nincs lehetőség hasonlóra, attól még lehet class-okkal procedurális, és class-ok nélkül OOP kódot írni (két függvénynek nem lehet ugyanaz a neve).
279

Mindegy...

T.G · 2015. Feb. 15. (V), 11.20
Mindegy... én tartom magamat ahhoz, hogy a PhpMailer-nek a kódja rossz és még csak nem is tipikus procedurális kód, de nem szeretnélek meggyőzni ezek ellenkezőjéről.
281

Ez egy gányolt oo kód, nem

inf3rno · 2015. Feb. 19. (Cs), 13.58
Ez egy gányolt oo kód, nem procedurális.
141

+1, C-ben vannak profik, pl

inf3rno · 2014. Okt. 2. (Cs), 18.56
+1, C-ben vannak profik, pl zeromq-t is inkább újraírta a srác c++ helyett c-ben: nanomsg. Alacsony szintű dolgokhoz nyilván az a megközelítés a jó, mert közelebb áll a géphez... A webalkalmazások, webszolgáltatások tipikusan magas absztrakciós szintű dolgokról szólnak, mert embereknek találták ki őket (legalábbis nagy részüket). A webes nyelvekhez - mint pl a PHP - így nyilvánvalóan jobban illik az oo.
179

Csak, hogy teljes legyen a

pp · 2014. Okt. 4. (Szo), 01.41
Csak, hogy teljes legyen a kép:

https://www.drupal.org/node/547518

"Although Drupal does not make thorough use of the native OOP features of PHP, the Drupal code base and API does reflect some principles found in object-oriented programming and design."

"This page is about Drupal 7's (and prior versions') architecture. Drupal 8 changed a great deal and now uses actual OOP practices."

pp
(btw google-ba beírtam "Drupal OOP" és az első találat ez volt.)
200

...

ydsMo9gx · 2014. Okt. 14. (K), 15.39
Szita Szilárd kérdésére válaszolva: én OOP programozás közben értettem meg az OOP-t. Csináltam, és közben gondolkodtam rajta. Azon, hogy pontosan mi történik a program futása során. Azután azon, mit csinál a fordítóprogram. Később azon, miért úgy alkották meg a(z éppen akkor általam használt) nyelvet. Eleinte nevetségesen túlbonyolítottnak tűnt az egész, hamarosan rájöttem az előnyeire is, de csak jóval később vált világossá az OOP lényege. Ha csak a lényegére kíváncsi valaki, ugorjon A lényeg című bekezdésre.

Háttérinfók:

Az, amit OOP alatt értenek, valójában legalább 3 különböző fogalomkört takar. Az objektumorientált programozási nyelveket, az objektumorientált programozást (ez az OOP) és az objektumorientált szemléletet. Ezek összefüggenek, de nem ugyanazt jelentik. A nyelvek adják az eszközöket, a programozás a megvalósítás része, a szemlélet a fejlesztők fejében alakul ki. Ahány nyelv, annyiféle eszköztár alakult ki, a gyakorlatban sokféleképp használják ugyanazt az eszköztárat is, a teoretikusok pedig mind-mind egyéni módon alakították ki a véleményüket az objektumorientáltságról.

Fentiekből ered a zűrzavar a fejekben.

Történetileg nézve az objektumorientáltság fogalma a Simula nyelvvel vált ismertté, a Smalltalk nyelvvel terjedt el szélesebb körben, onnantól pedig számtalan különböző nyelvbe, eszközbe és módszertanba vettek át elemeket a korábbi nyelvekből, eszközökből és módszertanokból. Hab a tortán, hogy előszeretettel nevezték el ugyanazokat az elemeket másképpen, illetve ugyanazokat az elemeket más képességekkel látták el és másképp használták.

Az eredmény: ma nincs két nyelv, módszertan vagy szakértő, amelyben/aki ugyanazt értené(k) objektumorientáltság alatt. Csak egyetlen példa: jelenleg a Java a legelterjedtebben használt objektumorientált nyelv. Emiatt sok más nyelven a javás megoldásokat kérik számon az objektumorientált elemek vizsgálatakor, persze tévesen. Időnként előkerül egy-egy Smalltalk-hívő, és nyilvánosan siránkozik más nyelvek objektumorientálttá nyilvánítása miatt, merthogy a "Smalltalk valóban objektumorientált", a többi pedig nem. Nos, a Smalltalk valóban velejéig objektumorientált, de ettől még az objektumorientáltság lényege nem az, hogy valami minden ízében objektumorientált.

A lényeg

Az objektumorientáltság lényege a programbeli változók és az őket kezelő programrészek szoros egymáshoz rendelése. A tisztán funkcionális nyelvekben például nincsenek változók (legalábbis szemantikailag). A tisztán imperatív nyelvekben a (globális) változók és az őket kezelő rutinok (függvények) szinte bárhol lehetnek, akár egymástól távoli modulokban szétszórva is.

Az objektumorientált nyelvekben vannak változók, és szorosan hozzájuk rendelve adhatjuk meg az őket kezelő programrészeket (a "metódusokat"). Ennek legvilágosabb, legegyszerűbb és leghatékonyabb megvalósítása az Oberon nyelvben látható. Ha valaki könnyen, gyorsan és alaposan meg akarja érteni az objektumorientáltságot, próbálja ki az Oberont. Elég rá egy hétvége... de tényleg. Aki pedig fanatikus híve az objektumorientáltságnak, az ne adja alább a Smalltalknál :), mert minden más csak halovány utánzata.

Érdemes tisztázni néhány félreértést.

Akár assemblyben is lehet objektumorientáltan programozni. Nem érdemes, de lehet.

Az objektumorientált nyelvek egyes objektumorientált jellemzőit fölösleges számonkérni más nyelveken. Az objektumorientált nyelvek spektruma nagyjából az Oberontól a Smalltalkig terjed, a kettő között mindenféle árnyalattal és ízzel.

Az objektumorientált szemléletek és módszertanok pedig... nos, szerintem túl vannak bonyolítva. Objektumorientált programozással jól megfogható a problémák többsége, de nem mindenható, sőt, olykor nem is igazán alkalmas a probléma megoldására. Ezért olyan kényelmesek a keverten imperatív-objektumorientált nyelvek, például a Python és a Go.

Az objektumorientáltságot utólag nehéz beleötvözni egy meglévő nyelvbe. A kötetlen szintaxisú nyelvek, például Forth simán bővíthető objektumorientált elemekkel, de a nyelvek többsége csak nehézkesen teszi ezt lehetővé, ha egyáltalán. A PHP például azelőtt is trágyahalom volt, hogy objektumorientált elemekkel bővítették, talán ezért nem tűnik fel annyira, hogy újabb, immár "objektumorientált" kupacok tornyosulnak a halom tetején.

Szerintem a következő utat érdemes követni:

1. Töltsd le az XDS-x86 Oberon-2 fordítóját (http://www.excelsior-usa.com/xdsx86.html). Egykor kereskedelmi szoftver volt, ma már ingyenes. Kényelmes IDE-vel, Windows és Linux alatt is használható. Az Oberon nyelv definicíója kb. 20 oldalas, könnyű és élvezetes olvasmány, sok helyről letölthető, kölönféle változatokban (Oberon, Oberon-2, Oberon-07 stb.). Magyarul talán az ELTE-s leírás (http://nyelvek.inf.elte.hu/leirasok/Oberon/) a legjobb. Nem tudom, mennyire felel meg az XDS-x86 Oberon-2-höz, de utóbbihoz a teljes dokumentációt mellékelik (angolul, és talán oroszul is).

2. Használd az XDS-x86 Oberon-2-t. Elég, ha egyszerű példaprogramokkal foglalkozol, módosítod és bővítgeted őket. Próbáld megérteni, pontosan mi történik a programok futása során. Gondold át, mit csinál a fordítóprogram. Azt, hogy miért úgy alkotta meg Wirth az Oberon nyelvet. Wirth lángész. Az XDS-x86 Oberon-2 nagyon elavult, komoly munkára aligha alkalmas, de tanulásra kiváló.

3. Az Oberon után bármelyik objektumorientált nyelvbe beleharaphatsz, az alapokat jól megértve már könnyű lesz átlátni, miben tér el a nyelv az Oberontól. A fogalmi zűrzavar sem fog annyira zavarni.
201

Kicsit visszaolvasgattam...

ydsMo9gx · 2014. Okt. 14. (K), 16.50
...a hozzászólásokat.

Mint az előbb írtam, az OOP nem mindenható. Példákat bőven találhatunk arra, hogy elegánsabb, tömörebb kódot tesz lehetővé, de arra is, hogy fölöslegesen elbonyolítja a dolgokat. Például a Java és az Eiffel tisztán objektumorientált, mindent osztályokba kell szervezni. (Oberonban jól látszik, hogy az "osztályok" valójában rekordtípusok, hozzájuk rendelt "metódusokkal", azaz rutinokkal.) Emiatt néha kifejezetten körülményes megírni egyszerű dolgokat is bennük. Eiffelben legalább a szerződések haszna ellensúlyozza ezt, Javában szerintem semmi.

Nagyobb lélegzetű szoftverek fejlesztésében az OOP óriási segítséget nyújthat. Nem divat. Nem oldja meg a problémákat helyettünk, csak segít kifejezni a megoldást. Hozzáértő kezekben roppant hasznos szerszám. Egyszerű, pici feladatoknál is jól jöhet, de nagy, bonyolult szoftverrendszereknél is előfordulhat, hogy van nála jobb megközelítés, például valamelyik funkcionális nyelv vagy egy doménspecifikus nyelv. Szóval még a méretek sem igazítanak el abban, mikor érdemes használni.

Úgyhogy nem érdemes 20-50 soros példákkal dobálózni, mert ezek alig bizonyítanak bármit is. Objektumorientáltan általában jobban megfogható egy nagy probléma, mint imperatív ("procedurális") módon, de ez akkor érezhető igazán, ha valóban végiggürcöltük a megoldást mindkét módon, még ha nem is pont ugyanazt a feladatot megoldva. Tehát ennek megítéléséhez már jól kell ismerni mindkét látásmódot.

Azzal sem érdemes példálózni, miért írták ezt vagy azt a közismert szoftvert imperatív vagy objektumorientált nyelven. A MySQL jókora része C++, a PostgreSQL tisztán C. De a végeredmény minősége (bármit is gondoljunk erről a két adatbázis-kezelőről) nem a két nyelvre jellemző, hanem az adatbázis-kezelők fejlesztőire. Nem sorolok további példákat. Legtöbb esetben személyi, szervezeti okok alapján dől el, hogy milyen eszközökkel fejlesztenek. És általában meglévő szoftvert gyúrnak tovább, nem választhatnak szabadon nyelvet, de még fordítóprogramot vagy értelmezőt sem. Csak "zöldmezős", egyéni fejlesztésnél szabad a pálya, ilyen pedig ritka, mint a fehér holló. Egy jó kis hétvégi oberonozás pont ilyen :).

Az Oberont tanulmányozva rájöhettek, hogy az objektumorientáltságnak semmi köze a hatékonysághoz. Pont olyan gyors és tömör, avagy lassú és kövér kódot lehet írni, illetve generálhat egy objektumorientált programból a fordítóprogram vagy értelmező, mint egy imperatívból. Bizonyos méret fölött általában előnybe kerül az objektumorientált kód, mert kevesebb paramétert kell átadni a rutinhívásoknál, jobban átlátható a kód és ennek köszönhetően tisztább felépítésű rendszert építhetünk, de ha valaki már eleve utálja az OOP-t, akkor aligha képes kihasználni az előnyeit. Ha ki tudjuk használni, akkor akár hatékonyabb is lehet a végeredmény, mint OOP nélkül. Az viszont biztos, hogy gyorsabban állítjuk elő és átláthatóbb lesz, könnyebb lesz módosítani, továbbfejleszteni.

A dinamikus memóriafoglalás és szemétgyűjtés nem kötődik az OOP-hez. Egyes nyelvek egyes fordítóprogramjaihoz igen, de akár assemblyben is lehet OOP-zni, akár heap és szemétgyűjtés nélkül is. Az objektumok szétszórtságának mértéke is a fordítóra és a linkerre jellemző, nem a nyelvre, még kevésbé a nyelv irányultságára. A virtuális függvények ugyebár valójában rutinváltozók, és nem objektumorientált nyelvekben is előfordulnak. A polimorfizmus csak egyes objektumorientált nyelvek rákfenéje, de aki Javával vagy C++-szal együtt ismeri meg az OOP-t, az aligha tudja ezt.

Az OOP ismerete ma már szakmai alapkövetelmény. Aki utálja, vagy nem ismeri, az kitol magával és a munkatársaival. Esetleg beágyazott rendszereket fejleszt C-ben, vagy hasonló piaci résben éldegél :). Magyarországon a többség PHP-ben, Javában vagy C/C++-ban kénytelen programozni. Ezek az objektumorientáltság szempontjából pont a legnyomorultabb nyelvek. Egyetlen előnyük az elterjedtségük.
202

Végre, egy egész objektív

Hidvégi Gábor · 2014. Okt. 14. (K), 18.03
Végre, egy egész objektív írás, de ez is több kérdést vet fel.

1, Te pontosan mit értesz objektumorientált programozáson?
2, Többször is említed az OOP-vel együttjáró bonyolultságot, például: "Eleinte nevetségesen túlbonyolítottnak tűnt az egész". A bonyolultság az érthetőség, átláthatóság, karbantarthatóság és a sebesség ellensége.
3, az 2-es pont után felvetődhet, hogy hogyan lehet jól OOP-ben fejleszteni:
a, az alapelveket betartva
b, alapelvek + SOLID
c, alapelvek + SOLID + Dependency Injection?
4, Növelik vagy csökkentik a komplexitást az újonnan bevezetett elvek (3/b, 3/c)?

Úgyhogy nem érdemes 20-50 soros példákkal dobálózni, mert ezek alig bizonyítanak bármit is.
Igazad van abban, hogy rövid példán nem lehet az előnyeit bemutatni, bár annak a demonstrációjára mindenképp jó, hogy lássuk, mennyi boilerplate keletkezik - ami az objektumok számával arányosan nő.

Azzal sem érdemes példálózni, miért írták ezt vagy azt a közismert szoftvert imperatív vagy objektumorientált nyelven.
Igen, ezt beláttam.

Aki utálja, vagy nem ismeri, az kitol magával és a munkatársaival.
Ez talán így van, talán nem. De nem az a kérdés, hogy ki mit szeret és mit nem, hanem hogy hol érdemes OOP-t használni, mert egy egzakt válasz nélkül nem lehet jó döntést hozni a paradigma és/vagy programozási nyelv kiválasztásakor.
203

Te pontosan mit értesz

ydsMo9gx · 2014. Okt. 14. (K), 23.47
Te pontosan mit értesz objektumorientált programozáson?

A lényeg című szakaszban írtam: Az objektumorientáltság lényege a programbeli változók és az őket kezelő programrészek szoros egymáshoz rendelése. Pontosabb lett volna így: Az objektumorientáltság lényege a programbeli változókat kezelő programrészek szoros hozzárendelése a változókhoz. Szerintem ennyire szűkíthető a lényeg. Ha egy nyelv támogatja ezt, akkor könnyebb megvalósítani az OOP-t. Ha nem támogatja, akkor "kézzel" is megvalósítható, ilyen az "objektumorientált" assembly vagy "objektumorientált" C. (A lényeg című szakasz további részét nem idézem ide.)

Többször is említed az OOP-vel együttjáró bonyolultságot, például: "Eleinte nevetségesen túlbonyolítottnak tűnt az egész". A bonyolultság az érthetőség, átláthatóság, karbantarthatóság és a sebesség ellensége.

Igen, túlbonyolítottnak tűnt, de hamar megváltozott a véleményem. Nem akartam részletezni, most is csak néhány részletet sorolok. Az első C++ fordítók idején találkoztam az OOP-vel. Ezek előfordítók (precompiler) voltak, C forráskódra fordították a C++ forráskódot. A C kód és a végtermék minőségét talán el tudjátok képzelni... És utánanézve még elborzasztóbbnak tűnt az egész. Smalltalkban ugyebár két egész szám összeadása úgy zajlik, hogy a két egész szám valójában két objektum, az összeadáshoz pedig az egyik üzenetet küld a másiknak... közben páros lábbal ugrál a hatékonyságon.

Csakhogy a C++ az eleve púpos C imperatív nyelv további toldozásával-foldozásával született meg, az előfordítós megvalósítását pedig csak ismerkedésre, kísérletezésre szánták (noha komoly fejlesztésekbe is belefogtak így, de aligha jutottak messzire). Szóval ez fals képet adott az OOP-ről.

És Smalltalkban ugyan az az összeadás szemantikája, amit írtam, viszont ma már egész hatékony kódot is képes generálni egy jó Smalltalk fordítóprogram. Ugyanakkor olyan csodákra képesek a Smalltalk környezetek, amit más nyelven talán sosem oldanak meg (nem azért, mert lehetetlen, hanem mert nem is próbálják meg, annyira körülményes lenne megvalósítani). A Smalltalk pont a legmélyéig hatoló objektumorientáltságnak köszönhetően teszi elérhetővé ezeket a csodákat. (Nem részletezem, akit érdekel, nézzen utána.)

Azt, hogy az OOP nemcsak egyszerűsíthet, hanem bonyolíthat is a helyzeten, a Java és az Eiffel példájával támasztottam alá. Ha egy egyszerű műveletsort muszáj objektumokkal megvalósítani, noha épelméjű fejlesztő nem lát objektumot a probléma elemzése során, akkor a Java és az Eiffel tervezői valamit elszúrtak... És tapasztalatom szerint a problémák elsöprő többsége felemás, vagyis jókora darabjaikhoz nem érdemes OOP-t bevetni, más részleteiknél nagyon sokat segít az OOP, a maradéknál pedig ízlés, tapasztalat, egyebek alapján hol így, hol úgy választ az ember eszközt. Hirtelenjében a Python alapkönyvtára jut eszembe, nézzétek meg, milyen kényelmesen vált a kód hol objektumorientált stílusra, hol imperatívra. Tisztán imperatív nyelvet ma már nem érdemes létrehozni. Oké, ez csak a komolyabb nyelvekre igaz, ha valaki mondjuk új shell-nyelvet tervez, akkor elpöföghet OOP nélkül is.

felvetődhet, hogy hogyan lehet jól OOP-ben fejleszteni:
a, az alapelveket betartva
b, alapelvek + SOLID
c, alapelvek + SOLID + Dependency Injection?

Ó, ennek könyvtárnyi irodalma van... És nyelvenként, esetenként fordítónként is változik a kép. Sok szoftverfejlesztési alapelv az OOP-től függetlenül is igaz, és OOP esetén is. Ezek a legfontosabbak, és ha ezeket megsértik, netán nem is ismerik, akkor az OOP nem sokat ér. DRY, YAGNI, KISS, ezek is betűszavak, de van még néhány hasonló "ősi" alapelv. És a tervezés meg a kódolás csak két fázis a szoftverfejlesztés során, ha már a követelményeket is rosszul határozzák meg, akkor ott nem a kódolás során dől el a fejlesztés sorsa... Kell ugye még verziókövető rendszer, kellő tesztelés (netán TDD), megfelelő dokumentáció (eldobható kódhoz semennyi, de komolyabb rendszernél nem elég az öndokumentáló forráskód, noha az is fontos, pedig eddig nem említettem) stb. stb. stb. Ezek nem OOP-s dolgok, és ezek az alapok sokkal fontosabbak, mint az OOP.

A SOLID csak hab a tortán, az egészséges OOP gyakorlat része. Ha nem ismered, nem tragédia. Ha ismered, de nem alkalmazod, mert csak ismerkedsz a problémával, és úgyis újraírod a kódot, akkor se ess kétségbe, ha nem követed a SOLID alapelveit. A dependency injection már erősen nyelvfüggő, sok helyen nincs rá szükség. A Liskov-féle helyettesítési elv pedig olyan, mint adatbázis-tervezésnél a harmadik, negyedik és ötödik normálforma (talán már továbbiak is vannak): ha ismered, az jó, ha nem, az se tragédia, és a gyakorlatban úgyse fogsz agyalni rajta.

Növelik vagy csökkentik a komplexitást az újonnan bevezetett elvek

Ha a csapat tagjai közül egyesek nem ismerik őket, mások pedig a hajukat tépik emiatt, akkor nem a komplexitással lesz gond... Ha kereskedelmi célú libraryt vagy API-t tervezel egy komoly rendszer kiegészítéseként, akkor minden használható tervezési elvet érdemes megfontolni, többségüket be is vetni, szigorúan ellenőrizni a betartásukat, különben később szívsz. A kódolás során is sokkal szigorúbban érdemes eljárnod. Ugyanez az aggályos hozzáállás őrületbe fog kergetni mindenkit egy adatbázis módosításához egyszeri lefutásra szánt patch készítése során.. tehát nem a komplexitás a sarokkő.

Az S (Single responsibility principle) alapvető. Az O (Open/closed principle) könnyen túlzásba vihető, Javában egész kultusza alakult ki. Az L (Liskov substitution principle) szerintem csak elméletileg fontos, a mixin-alapú objektumorientált nyelvekben semmi értelmét nem látom, a többiben se sokat. Az I (Interface segregation principle) is-is eset, lásd az O-t. A D (Dependency inversion principle) a dependency injection szülőanyja, szerintem nyelvfüggő.

Igazad van abban, hogy rövid példán nem lehet az előnyeit bemutatni, bár annak a demonstrációjára mindenképp jó, hogy lássuk, mennyi boilerplate keletkezik - ami az objektumok számával arányosan nő.

Ez is nyelvfüggő. Az általad belinkelt hello world-ös példa nem demonstráció, hanem kifigurázás. Nézd meg, milyen kód kell hozzá Windowsban C, illetve Borland C++ esetén (ősi példa kb. 20 évvel ezelőttről). Linket sajnos nem tudok adni ehhez, de emlékszem, hogy anno jó érv volt a Borland C++-hoz adott OWL alapkönyvtár mellett.

Az osztályok (class) számának növekedése ugyan a szoftver bonyolultságának velejárója, de a mértéke már a tervezéstől függ, és a kellően bonyolult problémákat OOP nélkül általában sokkal nehezebb megoldani. (Az objektumok száma itt alighanem elírás részedről.)

Javában elkerülhetetlen a boilerplate. Jobb nyelvekben minimális, vagy nincs. Tehát nem az OOP velejárója, hanem rosszul megtervezett nyelvek púpja. A lassú fordítás is ilyen, leesett az állam, amikor órákig tartó buildekről hallottam még pár évvel ezelőtt is (Java, C++). Valószínűleg azóta se javult a helyzet.

nem az a kérdés, hogy ki mit szeret és mit nem, hanem hogy hol érdemes OOP-t használni, mert egy egzakt válasz nélkül nem lehet jó döntést hozni a paradigma és/vagy programozási nyelv kiválasztásakor.

Nincs egzakt válasz. Ez nem matematika, de még ott is lehet több megoldása egy problémának. Másodfokú egyenlet: 0, 1 vagy 2 gyöke is lehet. Az alapos diszkusszió ott általában lehetséges, a szoftverfejlesztésben ehelyett ott a klasszikus háromszög.

De ha egyszerű választ vársz, íme: ha jól ismered az OOP-t, akkor szinte ránézésre tudni fogod, milyen problémához érdemes bevetni és milyenhez nem. Amíg nem ismered az OOP-t, addig nem ez a gond, hanem az, hogy nem ismered és ezért nem tudod használni. Szánj rá egy-két hétvégét az Oberonra vagy a Góra, és csak az OOP-s programocskáidhoz szükséges részeiket ismerd ki. A Go OOP-s elemeit szerintem az Oberonból emelték át, és nagyon jól tették. Az külön tetszik, hogy az OOP-s tudorok mennyire fújnak rá emiatt :). A Go tervezői Wirth szellemiségét követik (puritán egyszerűség, kőkemény precizitás, villámgyors fordítás), talán be is vallják ezt, nem tudom. Konkrét nyelvi elemekben jól felismerhetők a nyomai.

Ha választhatsz programnyelvet a munkád során, akkor jó, ha minél többfélét ismersz jól. De általában nem választhatsz.

Zárszóként: webfejlesztés során szerintem ritkán kell az OOP. PHP-s library vagy keretrendszer írásához jól jöhet, de ezek használatához már aligha érdemes saját osztályokat készíteni (cáfoljatok meg, ha tévedek, én csak a 4-es PHP-t használtam, de sosem az OOP-t hiányoltam a PHP-ből). Banki website hátteréhez nyilván kell, a közelébe sem engednek, ha nem értesz az ott használt OOP nyelvhez (Java, C#). Ha a keretrendszered osztályokbeli metódusokhoz továbbítja a HTTP-s lekérdezéseket, akkor a használatához szintén kell OOP, de saját osztályokat nem kell írnod ehhez. És számtalan példa mutatja, hogy imperatív stílusban is leképezhetők a HTTP-s lekérdezések, azaz metódusok helyett rutinok (függvények, eljárások) is fogadhatják azokat.
204

Zárszavadra

Pepita · 2014. Okt. 14. (K), 23.52
Mai webalkalmazásokhoz szinte mindig kell az OOP. (Megj., hogy nem láttam, hogy említetted volna az öröklődést, tulajdonságok, metódusok láthatóságát, ami fontosabb, mint a változók és az őket használó programrészek szoros kapcsolata. Vagy nem jól fogalmaztad meg - szerintem.)

Mindegy, hogy csak 4-es PHP-t használtál, ott is ugyanúgy fontos pl. a keretrendszer felhasználásakor is a láthatóság, öröklődés.
Banki website hátteréhez nyilván kell
Biztos? Én nagy mobilszolgáltatóról hallottam, hogy 0 OOP, és úgy gondolom, nem hazudott, aki mondta...
Ha a keretrendszered osztályokbeli metódusokhoz továbbítja a HTTP-s lekérdezéseket, akkor a használatához szintén kell OOP, de saját osztályokat nem kell írnod ehhez.
Ezt keretrendszere válogatja, amit én jónak tartok, abban bizony minden egyes controllered és modeled egy-egy osztály, amit te írsz meg.
Rajtad múlik az is, hogy mennyire bontod szét feladatonként az osztályaidat, simán lehet örökíteni is, stb. És ez a jó megoldás ma.
És számtalan példa mutatja, hogy imperatív stílusban is leképezhetők a HTTP-s lekérdezések, azaz metódusok helyett rutinok (függvények, eljárások) is fogadhatják azokat.
Persze, csak máris összefolyik az MVC (vagy inkább CMV lenne helyes), lőttek az adatok biztonságának, nincs átláthatóság, ...
Egy pároldalas, adatbázist nem is használó, max 10 oldalas weblap esetén még talán-talán, de akkor mihez kell a program(ozás)?
207

Az öröklődés...

ydsMo9gx · 2014. Okt. 15. (Sze), 22.05
..., a tulajdonságok és a metódusok láthatósága nyelvfüggő. Csak a változók és az őket használó programrészek szoros kapcsolata a közös metszet a különféle objektumorientált megvalósítások között. Tehát ennyi az OOP alapja, a többi csak ráadás, ráadásul sokféle megvalósítással. Nem véletlenül folyt annyi vita ezekről a részletekről. És pont a méltatlanul elfeledett Oberon mutatta meg, mennyire kevés kell a jó OOP-hez.

Mindegy, hogy csak 4-es PHP-t használtál, ott is ugyanúgy fontos pl. a keretrendszer felhasználásakor is a láthatóság, öröklődés.

Erről azt írtam, hogy ehhez aligha érdemes saját osztályokat készíteni. Tehát az OOP-s alkotói képesség elsajátítására nincs szükség, nem kell foglalkozni a SOLID-dal és a többi hasonló finomsággal, elég a fogyasztói alapállás. Objektumok létrehozásához, metódusok meghívásához nem kell ismerni az elméleti hátteret. Az OOP roppant felületes ismerete is elég. (De tévedhetek, mint írtam.) Ha komolyabb keretrendszert vagy libraryt készítesz, ahhoz szerintem nagyon is jól jön. Általában minden nagyobb szoftverhez. (Kivétel itt is van: a funkcionális és a logikai nyelvekben nincs OOP. Kivételek a kivételben: Scala, F#.)

Egész konkrétan: a láthatósággal és az öröklődéssel kapcsolatos tudásra hol van szükség egy OOP-s keretrendszer használatakor?

Én nagy mobilszolgáltatóról hallottam, hogy 0 OOP, és úgy gondolom, nem hazudott, aki mondta...

Én meg nyugati bankokról olvastam szakmai beszámolókat, miszerint még a HTTPS-t sem használja mindegyikük. (Igaz, kisebb bankokról, és pár évvel ezelőtt, de akkor is...) Szóval nem lepne meg, ha egyesek még kőbaltával dolgoznának. Egyébként pont telekommunikációban viszonylag elterjedt az Erlang, az pedig nem OO, hanem funkcionális, és kiváló eszköz erre a területre.

Ezt keretrendszere válogatja, amit én jónak tartok, abban bizony minden egyes controllered és modeled egy-egy osztály, amit te írsz meg.

Mert? Erről többet is írhatnál. Ugye keretrendszerből tengersok van, jóból sincs hiány. Hirtelenjében a pythonos Django és web2py jut eszembe, ahol sima függvények a controllerek, és mindkettő a legjobb pythonos keretrendszerek közé sorolható.

Rajtad múlik az is, hogy mennyire bontod szét feladatonként az osztályaidat, simán lehet örökíteni is, stb. És ez a jó megoldás ma.

Rajtam múlik, és simán lehet. De egyszerű esetekben nincs rá szükség, sőt, fölösleges. (Úgy látom, hogy így Gábor oldalára sodródok, pedig inkább a másik felé hajlok...)

Persze, csak máris összefolyik az MVC (vagy inkább CMV lenne helyes), lőttek az adatok biztonságának, nincs átláthatóság, ...

Na ne. Az MVC-nek ehhez semmi köze. Az adatbiztonságnak sincs. Az átláthatóság sem ettől függ.

Nagyon nagy, nagyon biztonságos rendszereket is simán lehet fejleszteni OOP nélkül. Megfelelő területen, megfelelő nyelvvel, megfelelő módszerekkel, hozzáértő fejlesztőkkel. Ha ez a kérdés, írhatok példákat. Fejből néhány:

A klasszikus Adában nincs OOP, ellenben kifejezetten segíti a biztonságos programozást. A Haskell és az Erlang tisztán funkcionális, mindkét nyelv pont ennek köszönhetően nagyon alkalmas biztonságos és elegáns szoftverek készítésére. A klasszikus Prologban sincs OOP, de úgy rémlik, később azt is kiegészítették vele. A Lisp-családra sem jellemző az OOP. És ezek mind jól megtervezett nyelvek, még sikeres is akad köztük, és néhányban kifejezetten nagy és biztonságos rendszereket is fejlesztettek már.
211

(Kivétel itt is van: a

Poetro · 2014. Okt. 16. (Cs), 08.48
(Kivétel itt is van: a funkcionális és a logikai nyelvekben nincs OOP. Kivételek a kivételben: Scala, F#.)

Ezek alapján a JavaScriptet például hova sorolod? OOP vagy funkcionális?
213

JS

Hidvégi Gábor · 2014. Okt. 16. (Cs), 09.01
A JS szerencsére több paradigmát támogat.
215

jo pap is holtig tanul...

Pepita · 2014. Okt. 16. (Cs), 13.21
Melyik oo nyelvben nincs private?

Sosem art ha tudod mi ez es az oroklodes. Pl a controllereden belul is csinalhatsz privat fv-t amit a publikus fv-ek hivnak. Orokiteni altalaban modelt erdemes.

Egyebkent en a codeignitert preferalom leginkabb. Abban mindezt megteheted megis kicsi es egyszeru fw.
Igaz hogy jelenleg nem fejlesztik de nem leven benne felhasznalokezeles (sem), ez nem jelent egyelore biztonsagi problemat.

Megfelelo terulet, nyelv: itt leginkabb php oop-rol van szo. Ami nem is tul jo oop, mert nem tipusos stb.

Bizony az adatok biztonsaganak nagyon is sok koze van mvc-hez. Gondolj bele: ki se jut view-ba ami nem kell. Ezt leginkabb oop kornyezetben tudod megoldani.
217

Javascriptben például nincs

bamegakapa · 2014. Okt. 16. (Cs), 13.31
Javascriptben például nincs private.

Az MVC lehet, hogy javít(hat) a biztonságon, de az MVC-nek szerintem semmi köze az OOP-hez. Meg lehet valósítani OOP használatával, de meg lehet sima függvényekkel is.
219

Sok nyelvben

Poetro · 2014. Okt. 16. (Cs), 14.39
Python-ban és Lua-ban sincs. Ruby-ban és Smalltalk-ban pedig minden tulajdonság private.
223

js

Pepita · 2014. Okt. 16. (Cs), 15.28
A js szerintem nem is igazi oop.
224

Nem?

Hidvégi Gábor · 2014. Okt. 16. (Cs), 15.43
Miért is nem?
226

szemlelet

Pepita · 2014. Okt. 16. (Cs), 18.04
Mert nem tipusos, nincsenek osztalyok, az objektumok csak tömbök, stb...

Nem az igazi szerintem.
227

A típusosságnak nincs köze

bamegakapa · 2014. Okt. 16. (Cs), 19.27
A típusosságnak nincs köze hozzá, az egyértelmű. Osztályok sem szükségesek feltétlenül az OOP-hez. És épphogy a tömbök objektumok Javascriptben, és nem fordítva.
228

Ez így nem teljesen igaz: az

Joó Ádám · 2014. Okt. 16. (Cs), 19.45
Ez így nem teljesen igaz: az objektumorientáltság alapja a polimorfizmus, a polimorfizmus lényege az interfészek használata, az interfészek típusok. Az, hogy mindezt – rendkívül rossz teljesítménnyel és biztonsággal – lehet utánozni hashtáblákkal, még nem jelenti azt, hogy ez jó.
229

Akkor itt most lehet volt egy

bamegakapa · 2014. Okt. 16. (Cs), 20.08
Akkor itt most lehet volt egy kis zavar részemről a típusosság értelmezését illetően. Ha jobban átgondolom, a Javascript típusos nyelv, bár ezeket a fogalmakat össze-vissza használja a szakma (amennyire én tudom).

Az interfészek, mint nyelvi elem, hiánya valóban fájó, de ez nem jelenti azt, hogy a Javascript ne lenne OOP nyelvnek tekinthető.
230

Végső soron típusok nélkül

Joó Ádám · 2014. Okt. 16. (Cs), 20.45
Végső soron típusok nélkül nem lehet (nincs értelme) programozni, de ettől a JavaScript nem lesz „típusos” (akármit is jelentsen ez így).

Az én véleményem az, hogy az erős, statikus típusrendszer olyan segítség a fejlesztés során, aminek – szabad választásból történő – nélkülözése erősen megkérdőjelezi egy fejlesztő szakmai hitelességét, főleg, ha közben arról prédikál, hogy unit tesztek nélkül nem lehet minőségi kódot produkálni.

A fentiek szellemében a JavaScriptet természetesen lehet OOP nyelvnek tekinteni, csak véleményem szerint elég gyengének.
232

Az egyik definíció szerint az

bamegakapa · 2014. Okt. 16. (Cs), 21.07
Az egyik definíció szerint az assembly-nél magasabb szintű nyelvek mind típusosak. Szokták arra is használni a "típusos" kifejezést, ha egy nyelv "statically typed", ez esetben a Javascript nem típusos, mivel "dynamically typed".

Legalábbis amennyire én erre emlékszem, a CS elmélet nem az erős oldalam :).

A véleményedet adom, nagyobb rendszerek fejlesztésénél az erős, statikus típusrendszer valóban előnyt jelenthet. Persze Javascriptben is lehet unit teszteket írni, és jelentősen javítják a minőséget.
239

Ha típusosságról beszélünk,

Joó Ádám · 2014. Okt. 16. (Cs), 21.44
Ha típusosságról beszélünk, akkor általában két egymástól független dimenzióban gondolkodunk: az egyik a statikus–dinamikus tengely, a másik az erős–gyenge.

A statikus nyelvek esetében minden kifejezéshez futásidő előtt típus rendelhető, ami egyrészt egy egzakt garancia az ilyen jellegű hibák hiányára, másrészt jól optimalizálhatóvá teszi a kódot, szemben a dinamikus nyelvekkel, ahol a kifejezések típusa nincs előre ellenőrizve.

Az erősen típusos nyelvek esetén egy értékkel csak a típusának – derüljön ez ki bár futásidő előtt vagy után – megfelelő műveleteket lehet végezni, minden más hibát eredményez, míg egy gyengén típusos nyelv széleskörű implicit konverziót tesz lehetővé, ezzel általában elfedve a hibákat.

Statikus és erős típusrendszere van a Javának vagy a Haskellnak; dinamikus és erős a Pythonnak vagy a Smalltalknak; statikus és gyenge a C-nek; dinamikus és gyenge a PHP-nek és a JavaScriptnek.
248

Igen, ez így OK. Most kicsit

bamegakapa · 2014. Okt. 16. (Cs), 23.58
Igen, ez így OK. Most kicsit utánanéztem, vannak "untyped" nyelvek is, amik nem típusosak egyáltalán, tehát ilyen szempontból a Javascript típusos. Persze dinamikus és gyenge, ahogy te is írod.
251

Én úgy gondolom, hogy az

Joó Ádám · 2014. Okt. 17. (P), 00.17
Én úgy gondolom, hogy az „untyped” nyelvek a leggyengébb (dinamikus) típusosság képviselői: a fejlesztő ugyan itt is típusok mentén dolgozik, a nyelv azonban ezek között korlátlan implicit konverziót tesz lehetővé. Ez persze már térdig filozófia.
262

Érdekes

Pepita · 2014. Okt. 17. (P), 15.09
Az egyik definíció szerint az assembly-nél magasabb szintű nyelvek mind típusosak.

- Az assembly nem típusos? (Byte, word, dword,...)
- Valójában minden nyelv típusos, de jó OOP-hez statikus, erősen típusos nyelv a jó. Persze ez is nézőpont kérdése (is), de ha belegondolsz: csak ott van típuskonverzió, ahol leprogramozod.
233

Végső soron típusok nélkül

Poetro · 2014. Okt. 16. (Cs), 21.10
Végső soron típusok nélkül nem lehet (nincs értelme) programozni

Akkor a legtöbb programozási nyelvnek nincsen értelme, mert nem szigorúan típusos, illetve csak futásidőben van típusellenőrzés?
235

Attól, hogy egy nyelv nem

Joó Ádám · 2014. Okt. 16. (Cs), 21.20
Attól, hogy egy nyelv nem nyújt támogatást hozzá, programozni máshogy nem tudsz, mint típusokat használva. Ha közvetlen gépi kódot írsz, akkor is típusokat használsz (egész szám, karakter, szín stb.), csak ezt rajtad kívül senki nem ellenőrzi. Ezt értem az alatt, hogy típusok nélkül nem tudsz, mert értelmetlen, programozni.
249

Csak innentől már ingoványos,

bamegakapa · 2014. Okt. 17. (P), 00.00
Csak innentől már ingoványos, mert ha azt mondjuk, hogy assemblyben vannak típusok, akkor azt is mondhatjuk, hogy Javascriptben vannak interface-ek, mivel meg lehet oldani, "csak ezt rajtad kívül senki nem ellenőrzi".
252

Így van, ezért is írtam azt,

Joó Ádám · 2014. Okt. 17. (P), 00.21
Így van, ezért is írtam azt, hogy tekinthető OOP nyelvnek a JavaScript, csak pocséknak, mivel a különböző objektumorientált paradigmák alkalmazásához igen kevés eszközt biztosít.
254

Nem mondom, hogy az OOP

bamegakapa · 2014. Okt. 17. (P), 00.54
Nem mondom, hogy az OOP császára vagyok, de Javascriptben még mindig szívesebben csinálom, mint mondjuk PHP-ben. Mostanában főleg frontenden dolgozom, úgyhogy volt időm barátkozni vele, az egyszerűsége nyűgöz le leginkább. Nem ad sok nyelvi eszközt OOP-hez, az igaz, interface-ek meg kellenek, de ezt még áthidalja az ember.
256

Szó se róla, gondolkodás

Joó Ádám · 2014. Okt. 17. (P), 02.56
Szó se róla, gondolkodás nélkül választom a JavaScriptet, ha a PHP az alternatíva.
263

+1

Pepita · 2014. Okt. 17. (P), 15.11
Így van, ezért is írtam azt, hogy tekinthető OOP nyelvnek a JavaScript, csak pocséknak, mivel a különböző objektumorientált paradigmák alkalmazásához igen kevés eszközt biztosít.
Kb pont ezt akartam mondani a szál elején...
238

A fentiek szellemében a

inf3rno · 2014. Okt. 16. (Cs), 21.41
A fentiek szellemében a JavaScriptet természetesen lehet OOP nyelvnek tekinteni, csak véleményem szerint elég gyengének.


Ezzel teljes mértékben egyetértek, az interface-ek hiánya js-ben nagyban lerontja a kódbiztonságot.
237

"a Javascript típusos nyelv"

inf3rno · 2014. Okt. 16. (Cs), 21.40
"a Javascript típusos nyelv" - szerintem minden alkalommal kimarad egy szó: "erősen/gyengén". Típusok nélkül elég nehéz lenne programozni...
240

Ehhez lásd feljebb a 239-est.

Joó Ádám · 2014. Okt. 16. (Cs), 21.56
Ehhez lásd feljebb a 239-est.
231

Polimorfizmus

Poetro · 2014. Okt. 16. (Cs), 21.01
A polimorfizmusnak elég sok definíciója van. És nem feltétlen interfészekre vonatkozik.
A subtyping, vagy inclusion polymorphism. Ezt a JavaScript kb. teljesíti is. Még ha interfécek nélkül is, mivel csak gyengén típusos. De le tudjuk ellenőrízni az adott változó típusát (typeof), sőt azt is, hogy példánya-e egy prototípusnak (instanceof).
234

Én továbbra is tartom, hogy a

Joó Ádám · 2014. Okt. 16. (Cs), 21.13
Én továbbra is tartom, hogy a polimorfizmus lényege, hogy interfészeket programozol. Az, hogy ezek explicitek-e, egy más kérdés. De cáfolj meg.
261

Van

Pepita · 2014. Okt. 17. (P), 15.03
A típusosságnak nincs köze hozzá, az egyértelmű
De van, mint Ádám is kifejtette.
Osztályok sem szükségesek feltétlenül az OOP-hez.
Akkor hogyan, milyen rendszer mentén írod le az objektumaidat? Hogyan örökíted? Stb..
És épphogy a tömbök objektumok Javascriptben, és nem fordítva.
Anno azt olvastam, hogy az "objektumok" tárolódnak statikus tömbökként. Szóljatok, ha rosszul tudom.
265

Nem ártana definiálni, hogy

bamegakapa · 2014. Okt. 17. (P), 15.35
Nem ártana definiálni, hogy miről beszélünk :). Hogy az OOP-re alkalmas nyelv, az szerintem egyértelmű. Én erről beszéltem. Ehhez nem szükséges sem erős típusosság, sem osztályok. Hogy vannak bizonyos hiányosságai, az sem kétséges. Ti erről beszéltetek, és igazatok van.

Anno azt olvastam, hogy az "objektumok" tárolódnak statikus tömbökként.

Ez implementációs kérdés, nem tudok róla, hogy a specifikáció ezt meghatározná, és azt se tudom, hogy működnek a ma népszerűbb implementációk.
236

Nem hiszem, hogy szükséges

inf3rno · 2014. Okt. 16. (Cs), 21.37
Nem hiszem, hogy szükséges lenne a ppp ahhoz, hogy valamit oop-nek tekintsünk. Ez inkább csak kényelmi funkció, ami biztosítja, hogy nem nyúlunk bele belső használatú változókba kívülről. Ugyanezt biztosítani lehet, ha egyáltalán nem nyúlunk bele példányváltozókba, hanem gettereket és settereket (vagy constructor injectiont) használunk minden esetben. Nyilván lesz egy kis boilerplate, de abba nem halunk bele.

Én egyet tudok érteni "ydsMo9gx"-vel (bármi is legyen az igazi neve) abban, hogy "Az objektumorientáltság lényege a programbeli változókat kezelő programrészek szoros hozzárendelése a változókhoz.". Nem hiszem, hogy ennél jobban le lehetne szűkíteni a dolgokat, mert a rendelkezésre álló oo eszközök teljesen nyelv függő dolgok.
241

A public-private

Joó Ádám · 2014. Okt. 16. (Cs), 22.07
A public-private megkülönböztetés az interfész-implementáció elkülönítés szempontjából fontos.

YdsMo9gx definíciójával azért nem tudok egyet érteni, mert C-ben is nagyon szépen összerendelhetőek struktúrák és őket manipuláló függvények.

Egy objektumorientált nyelv (bár már sok helyen jeleztem, hogy használhatatlanul tág fogalomnak tartom az objektumorientáltságot) annyival tud többet, hogy típushierarchiák (és ezzel interfészek) kialakításával lehetővé teszi a futásidejű polimorfizmus használatát.
242

Költői kérdés

Hidvégi Gábor · 2014. Okt. 16. (Cs), 22.52
Nem véletlenül tettem fel a kérdést, hogy szerinte mi az OOP. Lehet-e olyasvalamiről érdemben vitatkozni, amin mindenki mást ért?
243

Szerintem nem. De leginkább

Joó Ádám · 2014. Okt. 16. (Cs), 22.57
Szerintem nem. De leginkább te kezdeményezed a vitát, és az OOP-ről, nem típusokról, polimorfizmusról, adatrejtésről, öröklésről, hanem OOP-ről.
244

Akkor rövid úton le lehetett

Hidvégi Gábor · 2014. Okt. 16. (Cs), 22.59
Akkor rövid úton le lehetett volna zárni.
245

Mit, hogyan?

Joó Ádám · 2014. Okt. 16. (Cs), 23.18
Mit, hogyan?
250

Vagy el se kezdeni :).

bamegakapa · 2014. Okt. 17. (P), 00.05
Vagy el se kezdeni :).
264

Minek?

Pepita · 2014. Okt. 17. (P), 15.16
Egész érdekes vitaszálak lettek belőle. Szerintem egyáltalán nem gond, hogy részfogalmak is előkerültek (típusosság, stb.).
220

(Úgy látom, hogy így Gábor

Hidvégi Gábor · 2014. Okt. 16. (Cs), 15.21
(Úgy látom, hogy így Gábor oldalára sodródok, pedig inkább a másik felé hajlok...)
Nem érdemes. A Sötét Oldal kis számú, de annál hangosabb Eretnekjeit tűzzel-vassal üldözik, ha a középkorban élnénk, engem már rég felnégyeltek és megégettek volna, és végül megetettek volna a disznókkal : )
222

na na

Pepita · 2014. Okt. 16. (Cs), 15.27
Annyira nem uldoznek teged szerintem.
Nincs is miert, szokatlan meglatasod van, de pont ezert sokfele szemszog megszolal.
Ezzel szerintem semmi gond.

Szerk. Azert en a felnegyelest stb visszahoznam de nem miattad v oop miatt... ;)
225

Üldöz téged a franc :).

bamegakapa · 2014. Okt. 16. (Cs), 15.51
Üldöz téged a franc :). Egyszerűen aki folyton csak kiabál, azt néha leütik. Sötét oldalnak meg eretneknek azért elég kevés vagy :).
205

Köszönöm

Hidvégi Gábor · 2014. Okt. 15. (Sze), 09.20
Impresszív, hogy valaki felül tud emelkedni a dolgokon, és semlegesen tud válaszolni.

Az objektumorientáltság lényege a programbeli változókat kezelő programrészek szoros hozzárendelése a változókhoz
Nem igazán értem, hogy ez milyen előnnyel jár. Korábban írtam egy példát:
Vegyünk egy adattömböt, amiben a site struktúrája fel van sorolva egy lekérdezés eredményeképp. Ezt két helyen is felhasználhatjuk: 1, legenerálunk belőle egy menüt, 2, elkészítjük belőle a navigációs sávot (címlap -> cikkek -> cikk). Mit és hogyan zárjunk egységbe? Legyen egy objektumban az egész? Feleljünk meg a single responsibility elvnek? - Legyen egy class a nyers adatoknak, és egy-egy a menünek és a navigációs sávnak? Vagy mi lenne, ha valahol lenne egy tömböm az adatokkal, máshol vannak függvényeim, aztán aki akar, olvasgat a tömbből
Erre a következő válasz érkezett:
A példádra egyébként a megoldás az, hogy több interface-en (nézet) keresztül teszed elérhetővé a belső reprezentációdat (esetedben tömböt). Akkor nem kell sok másolatot csinálni az adatból, ráadásul a felhasználási helyen egyértelmű, hogy mit kell vele csinálni, nem csak van egy nyers adathalmaz, aztán találd ki mit kezdj vele.
Ezzel nem értek egyet, egy adatforrás szerintem bőven elég, és megjelenítéskor pedig mindenképp szükséges másolatot készíteni az adatokról. Te mit gondolsz erről?

Más. A Gót ismerem, programoztam benne, igaz, ott is csak procedurálisan, mert pontosan tudtam, mire volt szükségem. Nagyon érett nyelvnek tartom, fölösleges sallangok és különösebb kompromisszumok nélkül. Viszont veled ellentétben a PHP-t nagyon szeretem, minden hibája ellenére, mert rendkívül hatékonyan lehet benne programozni (továbbra is procedurálisan).

webfejlesztés során szerintem ritkán kell az OOP
Ezt elfelejtetted kiemelni ; )

A nevedet igazán megadhatnád az adatlapodon.
208

...

ydsMo9gx · 2014. Okt. 15. (Sze), 22.23
Ezzel nem értek egyet, egy adatforrás szerintem bőven elég, és megjelenítéskor pedig mindenképp szükséges másolatot készíteni az adatokról. Te mit gondolsz erről?

Ha OOP-s megoldást választasz, akkor a neked válaszoló megoldása tűnik jónak. Azt viszont nem látom, ehhez a problémához miért lenne szükség OOP-re... legalábbis első esetben. A 2., de legkésőbb a 3. esetben már végiggondolnám, hogyan oldható meg általánosabban a feladat, és ehhez már jó eséllyel OOP-s megoldást választanék.

veled ellentétben a PHP-t nagyon szeretem, minden hibája ellenére, mert rendkívül hatékonyan lehet benne programozni

Én örülök, hogy elkerülhetem. Szerintem már csak ott van létjogosultsága, ahol 1) meglévő PHP-s rendszert tartanak karban, vagy 2) osztott tárhelyen muszáj elhelyezni a site-ot, vagy 3) a csapat többsége nem akar másra váltani. A 2) esetnél megfontolandó a VPS-re váltás, a 3)-nál a munkahely váltása.
218

Részemről köszönöm a

bamegakapa · 2014. Okt. 16. (Cs), 13.51
Részemről köszönöm a hozzászólásokat, üdítő volt olvasni.
246

Én is köszönöm...

ydsMo9gx · 2014. Okt. 16. (Cs), 23.27
..., hogy itt lehetek :). Évekig csak olvasgattam errefelé, ha alkalom adódott rá. A Weblabor jövőjéről folyó vita különösen érdekelt, és amikor egy időre bezárt ajtó mögött folytattátok, akkor gyorsan regisztráltam, hogy tovább követhessem. Aztán valahogy elsodortak az események, de ez a OOP-ről folyó vita megint megragadta a figyelmemet.
221

Alternatíva?

Hidvégi Gábor · 2014. Okt. 16. (Cs), 15.24
Jó, de akkor mit használsz/ajánlasz PHP helyett? A támogatottsága kiváló, gyorsan lehet benne fejleszteni. A Go nagyon jó nyelv, de egy új projektnél, ahol még minden alakul, a statikus típusosság inkább hátrány, mint előny.
247

Most éppen Gót

ydsMo9gx · 2014. Okt. 16. (Cs), 23.41
(Egy évvel ezelőtt még Pythont ajánlottam volna.)

Nem kampányolok a PHP ellen, sok esetben még mindig a legjobb választás lehet, leginkább akkor, ha nincs idő másra váltani. És ritkán választhatjuk meg, mivel és kinek dolgozunk. De aki nem fejlődik tovább, maga ellen vét. A PHP szerintem zsákutca.

A Go ellen leginkább a kész építőelemek kínálatának szűkössége szól. De ami van, az legalább többnyire jó minőségű. Gyorsan változó környezetben egyébként pont előny a statikus típusosság. Nekem legalábbis sokat segít a Go szigora, mert nagyon trehány vagyok.
253

A Go nagyon jó nyelv, de egy

Joó Ádám · 2014. Okt. 17. (P), 00.27
A Go nagyon jó nyelv, de egy új projektnél, ahol még minden alakul, a statikus típusosság inkább hátrány, mint előny.


Ezt az állítást már sok helyen olvastam, de még soha senki nem támasztotta alá semmilyen érvvel.

Ahogy YdsMo9gx írja, a statikus típusrendszer éppenhogy megkönnyíti a kísérlezetést, mert egy refaktorálás során sokkal nehezebb hibákat bevezetni.
268

Egy új projektnél, ahol egyik

Hidvégi Gábor · 2014. Okt. 19. (V), 20.52
Egy új projektnél, ahol egyik nap ezt, másik nap azt, harmadik nap amazt kérnek, sokkal gyorsabban lehet olyan gyengén típusos nyelvekkel dolgozni, többdimenziós tömböket létrehozni, mint a JS vagy a PHP. Ennek természetesen ára van, de egy átlagprojektnél ez szerintem elhanyagolható.
269

Dolgoztam és néha kénytelen

Joó Ádám · 2014. Okt. 19. (V), 21.42
Dolgoztam és néha kénytelen lévén máig dolgozom dinamikus nyelvekkel, de én nem látom, hogy miben könnyítené ez meg a munkát. Sokkal inkább nehezíti, hogy csak a(z általában hiányos) dokumentációra (vagy a forráskódra) hagyatkozhatok annak tekintetében hogyan működik valami, ahelyett, hogy a fordító jelezné, ha valamivel baj van.
206

Jó látni néhány friss

inf3rno · 2014. Okt. 15. (Sze), 14.43
Jó látni néhány friss gondolatot a témában. Én csak magasabb szintű nyelveket ismerek, és óhatatlanul ezekhez társítottam az OOP-t...

A PHP például azelőtt is trágyahalom volt, hogy objektumorientált elemekkel bővítették, talán ezért nem tűnik fel annyira, hogy újabb, immár "objektumorientált" kupacok tornyosulnak a halom tetején.

PHP-s library vagy keretrendszer írásához jól jöhet, de ezek használatához már aligha érdemes saját osztályokat készíteni (cáfoljatok meg, ha tévedek, én csak a 4-es PHP-t használtam, de sosem az OOP-t hiányoltam a PHP-ből).


Érdemes megnézni az 5.5 feletti PHP-ket, egészen alkalmas lett a nyelv oo programozásra a 4.x-es verziók óta...

webfejlesztés során szerintem ritkán kell az OOP


Ez így egy elég "bold statement". Szoftvert fejlesztünk, nem webet... ;-) Bármelyik szoftvernél kellhet az OOP. Pl DDD esetében csinálsz egy domain model-t, amiben (nem feltétlen, de általában) objektum orientált módon írod le a problémát, amit meg szeretnél oldani. Ez a fajta modellezés teljesen független attól, hogy min (web, asztali) keresztül érik majd el az alkalmazásodat. Azt aláírom, hogy nem minden probléma megoldásához kell ilyen szintű tervezés, de ez a probléma bonyolultságától, és nem a prezentáció módjától függ.

Ugyanígy bármilyen általános jellegű keretrendszer írásánál kell az OOP, hogy cserélhető legyen az implementáció. Ez sem web függő...

És tapasztalatom szerint a problémák elsöprő többsége felemás, vagyis jókora darabjaikhoz nem érdemes OOP-t bevetni, más részleteiknél nagyon sokat segít az OOP, a maradéknál pedig ízlés, tapasztalat, egyebek alapján hol így, hol úgy választ az ember eszközt.


Szerintem az OOP csak egy extra "réteg" az imperatív programozás felett, amin keresztül absztraktabb (ha úgy tetszik magasabb szintű) dolgokat sokkal jobban ki lehet fejezni. Természetesen ha úgy találod, hogy nem éremes absztrakciókat kiemelni egy-egy kódrészletnél (sokszor nincs rá szükség), akkor semmi akadálya az imperatív megközelítés használatának. Szerintem komplexebb problémák esetében könnyíti az átláthatóságot, ha tisztán absztrakciókkal tudunk dolgozni ahelyett, hogy lépten nyomon belefutnánk a megvalósítás részleteibe, ezért gondolom úgy, hogy nagyobb lélegzetű projekteknél érdemes OOP-t használni. Nyilván mindenkinél más a határ, aminél már úgy érzi, hogy tisztább lenne objektum orientáltan megközelíteni az adott problémát. Elég széles a skála... Egy általános jellegű kódnál (pl keretrendszer) nyilvánvalóan jóval többször van szükség absztrakciókra, mint egy nagyon probléma specifikus kódnál (pl hello world).
209

...

ydsMo9gx · 2014. Okt. 15. (Sze), 22.43
Ez így egy elég "bold statement". Szoftvert fejlesztünk, nem webet... ;-) [...] Azt aláírom, hogy nem minden probléma megoldásához kell ilyen szintű tervezés, de ez a probléma bonyolultságától, és nem a prezentáció módjától függ.

Teljesen egyetértek veled. A "webfejlesztés" fogalmát pont ezért leszűkíteném a megjelenítéshez kötődő rétegekre, tehát a kliensoldalra és az azt közvetlenül kiszolgáló szerveroldali részre. És ezeken a helyeken általában csak meglévő, korábban kifejlesztett OO eszközök használatára van szükség. Nem is lehet másképp: amit érdemes általánosabb formában megvalósítani, az már korábban belekerült a felhasznált library(k)be vagy keretrendszer(ek)be, az egyszeri rendszer felépítésekor már csak használjuk ezeket.

Ellenpélda nyilván ezer van. Kicsit komolyabb feladatnál már megéri alaposan tervezni, és hamar előjöhetnek az OO módszerek előnyei.

Ugyanígy bármilyen általános jellegű keretrendszer írásánál kell az OOP, hogy cserélhető legyen az implementáció. Ez sem web függő...

Az első mondatoddal itt is egyetértek. A másodikat nem értem, érvelési botlásnak tűnik.

Az utolsó bekezdésedet viszont én is írhattam volna :).
210

A funkcionális programozásról

inf3rno · 2014. Okt. 16. (Cs), 06.09
A funkcionális programozásról tudnál írni egy rövid összefoglalót! Próbáltam nekifutni többször is a témának, de az én szempontomból nem tartom túl fontosnak, és így a kezdeti definíció értelmezésénél mindig megtörik a lelkesedésem...
212

Funkcionális

Hidvégi Gábor · 2014. Okt. 16. (Cs), 08.49
Emlékeim szerint te dolgoztál már XSLT-vel, ugye? Na, az funkcionálisszerű gondolkodást igényel, lásd <xsl:variable>, rekurzió.
214

Azt írják, hogy hiányoznak

inf3rno · 2014. Okt. 16. (Cs), 12.37
Azt írják, hogy hiányoznak belőle a funkcionális nyelvek bizonyos jellemzői, de egyébként olyasmi. Nem szerettem, mondjuk ez inkább a debug teljes hiánya miatt volt. Most nyilván beszórnék egy IDE plugint, ami megoldja a problémát. Akkor nem jutott eszembe, vagy nem létezett ilyen, csak kényelmetlen megoldások. Összességében XSLT-vel szerzett tapasztalataim alapján nem szeretném megítélni ezt a paradigmát.
216

ne is

Pepita · 2014. Okt. 16. (Cs), 13.28
Ne is itelj xslt alapjan.
Szerintem neked egy regebbi nyelv kiprobalasa lenne jo, amiben egyaltalan nincs oo de fvek igen.
255

funkcionális programozásról egy rövid összefoglaló

ydsMo9gx · 2014. Okt. 17. (P), 01.40
Írni éppen tudnék, de nem vagyok elég járatos ezen a területen.

Idén tavasszal másodszor futottam neki a Haskellnek, és újra beletört a bicskám. És már nem is látom értelmét, mert ugyan nagyon ígéretes, de szerintem mindig mellékutca marad. Járható, de a forgalom máshol zajlik. Annyira szokatlan a látásmódja, a fogalomkészlete, minden. Cserébe nem nyújt eleget, legalábbis nekem. Akit érdekel, annak a Haskellhez ezt az online is olvasható könyvet ajánlom. És folyamatos, mindennapi előrehaladást, gyakorlást, különben sosem tud belejönni. Már jó webes keretrendszerek is vannak Haskellhez, én a Yesodot próbálgattam. Komolyabb munkához IDE is kell (nekem), az FP Haskell Center Community kiadása ingyenes, a Personal is olcsó. A Haskellről éppenséggel tudnék írni, de Magyarországon sosem ereszt gyökeret. Amit érdemes leírni róla, azt az ELTE-sek már nagyrészt megírták, sajnos szokás szerint roppant szárazon. Az előbb ajánlott angol nyelvű könyvecske pont azért jó, mert a Haskell amúgy is nyögvenyelős, nagyon jó, ha valami segít lecsúsztatni.

Az ELTE az Erlangról is készített már leírást. Erről nem tudok többet, nem olvastam. Ehhez is angol nyelvű, online könyvet használtam most. Évekkel ezelőtt már próbálgattam az Erlangot, de használható webes keretrendszer nem volt hozzá, árva gyereknek éreztem magamat. Idén tavasszal újra beleharaptam, már van hozzá keretrendszer, szerintem a Zotonic a legjobb. Egy ideig most is gyűrtem az Erlangot, aztán feladtam. Addig jutottam, hogy nem találtam kézreálló IDE-t, és Windowson csak virtuális gépben tudtam futtatni a Zotonicot. Rájöttem, hogy az Erlang még pont nem érte el a kellő érettséget ahhoz, hogy erős kötöttségek nélkül lehessen használni. Akik már ismerik, azoknak ez kevésbé gond, de addig el kellene jutnom, és sajnáltam rá az időt és energiát.

A Lisp-vonulatból az OCaml tetszett meg, már évekkel ezelőtt. Most már jó könyvet is találtam hozzá, anno ez volt az egyik fő akadály. Windowsos IDE is van, új nyelv tanulásában a debugger óriási segítség! Itt a keretrendszernél akadtam el, az Ocsigent próbálgattam, de hol ez, hol az okozott problémát. Főleg az adatbázis-kezeléssel kínlódtam, aztán ezt is feladtam.

Az F# erősen kötődik a Windowshoz. A .NET ugyan már Linuxon is elérhető a Mono révén, de én sosem kötődtem a .NET-hez, ezért nekem ez nem örömhír. Szerverre Linux kell és kész. Ha pedig már Linuxra termelünk, akkor miért választanánk ehhez egy Microsoft által is alig támogatott félvér alapot?! ASP.NET Linuxon... felejtős.

Még annyit tennék hozzá a fentiekhez, hogy aki Magyarországon funkcionális nyelvben fejleszt, az vagy nagyon szerencsés, mert talált hozzá céget, társakat, vagy magányos farkas. Én idén tavasszal szántam erre másfél hónapot, és egy életre lezártam a témát. A Go mellett döntöttem, és eddig nem bántam meg.

Ha mégis érdekelnek a funkcionális nyelvek, akkor az OCamlt ajánlom, éppen azért, mert nem tisztán funkcionális, használhatod imperatívan és OOP-ra is jó.
257

Én Erlang-ot látom sokszor

inf3rno · 2014. Okt. 17. (P), 05.28
Én Erlang-ot látom sokszor SO-n, meg általános kérdéseket funkcionális programozással kapcsolatban. Inkább csak olyan szinten érdekel, hogy mégis tudjam miről van szó, nem szeretnék új nyelvekbe belefolyni, nem lenne rá időm... A legtöbb problémát én abban érzem, hogy egy jól működő fejlesztőkörnyezetet belőjek egy új nyelvre, ill. hogy összeválogassam a keretrendszereket, amiket használni szeretnék. Sokszor még PHP és nodejs esetében is megküzdök ezekkel. Nekem egyébként semmi bajom nincsen a PHP-vel, amire nekem kell, arra pont jó. Go-val valószínűleg fogok foglalkozni a későbbiekben, eddig csak jót hallottam róla...
259

Csak hogy rosszat is halljál:

Joó Ádám · 2014. Okt. 17. (P), 11.08
Csak hogy rosszat is halljál: nincs benne generics és method overloading, és szerintem neked a kivételkezelés és öröklés is hiányozna. Én az első kettő miatt hagytam ott.
258

Scala

T.G · 2014. Okt. 17. (P), 07.47
Régebben volt egy Prezis előadás, ahol szóba került a Scala is, illetve a funkcionális nyelvek előnye. Többek között azt emelte ki az előadó, hogy rendkívül jól skálázható, némi túlzással, ha a feladat egy gépen megoldható 10 óra alatt, akkor az 10 gépen 1 óra alatt készen lesz. És ehhez nekik semmi bűvészkedésre nincs szükségük, a paradigma adottsága ez. Az Amazon felhőiben megoldható az, hogy a gépeket akár órákra béreljék ki, így a skálázhatóságot különösen ki tudják használni. (az előadásnak ez csak egy kis része volt, azt emelték ki, hogy mindenre azt a megoldást használjuk, ami a legjobban odaillik, az persze érdekes, hogy ők PHP-t semmire sem használják:)

Annakidején elvégeztem a Coursera Scala tanfolyamot, számomra érdekes volt, igaz nem kevés időt elvett, így csak azoknak ajánlanám, akiket komolyabban érdekel a téma. Sok feladatnál éreztem azt, hogy egy egyszerű for ciklussal mennyivel könnyebb lenne megoldani az egészet, valószínűleg egy számítógépen biztosan lassabb megoldást is készítettem így. Ám nem biztos, hogy a funkcionális nyelveknél az egy számítógépes környezetre kell elsősorban gondolni.
260

Én elég komolyan fogadtam a

Joó Ádám · 2014. Okt. 17. (P), 11.14
Én elég komolyan fogadtam a Scalára, és szégyenszemre visszatértem a Java 8-hoz most, hogy van lambda. Az oka egy nagyon komplex és nagyon gyorsan változó nyelvhez társuló hiányos dokumentáció, a fájdalmasan lassú fordítás és a gyomorforgató „reactive programming” hype.
266

Sajnos...

ydsMo9gx · 2014. Okt. 17. (P), 23.58
...nem ennyire szép a funkcionális menyasszony. Legegyszerűbb példa: ha egy két lépésből álló műveletnél a 2. lépésnek szüksége van az 1. lépés eredményére, akkor a 2. elindításához meg kell várni az 1. lefutását, emiatt az 1. és a 2. lépés nem párhuzamosítható (nem futhat egyidejűleg). A problémák többsége ilyen nem párhuzamosítható elemeket is tartalmaz. Amdahl törvénye és Gustafson törvénye pontosan megadja a párhuzamosítással elérhető gyorsítás elméletileg elérhető korlátait. A ProHardveren röviden bemutatják mindkettőt magyarul is: Amdahl, Gustafson.

Ezeket a korlátokat csak megközelíteni lehet, elérni még funkcionális nyelvekkel sem lehetséges. És ugyanúgy megközelíthetők imperatív, objektumorientált stb. nyelvekkel is. Csak nehézkesebb lesz a párhuzamosan futó szálak vagy folyamatok összehangolása, több a hibalehetőség, meredeken emelkedhet a programok bonyolultsága. A funkcionális nyelvek ezt az összehangolást könnyítik meg. Ahogy a Go is, pedig nem funkcionális, csak átvettek bele egy kiváló megoldást erre a célra.

Webszervereknél a könnyű párhuzamosíthatóság elméleti előnye alig érezhető. A lekérdezések kiszolgálása legtöbb nyelven simán párhuzamos, általában csak az adatbázis zárolásaival kell törődni. A Weblaboron úgy látom, az elmúlt évben nem merült fel a téma, régebben is csak elvétve, viszont már 2003-ban ígérték itt a PHP 5 szálbiztossá tételét, a kiegészítőkre vonatkozóan is. A további fejleményeket nem ismerem.

Röviden: a funkcionális nyelvek említett rendkívül jó skálázhatósága inkább csak elvi előny. Fontos viszont, hogy könnyebb kihasználni ezt a skálázhatóságot. Ennek, és a szigorú fordítási idejű típusellenőrzéseknek köszönhetően sokkal biztonságosabb programok készíthetők velük. Ez a fő előnyük. Repülőgépek és tengeralattjárók fedélzeti rendszereit, atomerővek vezérlését és hasonlókat érdemes megírni bennük. Az alap OCaml sajnos nem konkurens, tehát pont nehezen skálázható, cserébe kellően gyors.

A prezis előadásban bizonyára több processzormagról beszéltek, nem több gépről. A több gépre szétosztható feladatoknál a funkcionális nyelven írt programok párhuzamosíthatósága alig jobb, mint a többi nyelvnél. A sokmagos CPU-k kihasználása válik könnyebbé.
267

Ez a téma a jelenkor egyik

BlaZe · 2014. Okt. 18. (Szo), 01.36
Ez a téma a jelenkor egyik legnagyobb tévedése. Pedig teljesen logikus, hogy (nagyon) nem lehet lineárisan skálázni. A szinkronizáció nincs ingyen. Se termek, se gépek, se processzorok, se processzormagok között. Mindnek megvan a maga nem kis költsége. Amiért megéri párhuzamosítani az a throughput, nem a végrehajtási idő. Ezek igen nagy részben gyakorlatilag fordított arányban állnak egymással. Vagyis a párhuzamosításnak többek között a lassulás lesz az ára. Gépen belül is. A socketek közötti kommunikáció, de még a core-ok közötti kommunikáció is baromi drága, a processzor rengeteg utasítást végre tud hajtani amíg odaküzdi magát egy cache line a másik core-ról. És mivel abba a funkcionális nyelvekben by design nem nagyon tudsz beleszólni, hogy mi pontosan hol fusson és ki kivel hogy kommunikáljon, érzésem szerint ezen a ponton valójában kevésbé lesz hatékony, mint egy nem funkcionális nyelv esetében (ahol nyilván egy hozzáértő tud finomhangolni). Szóval szerintem nem ez az előnye. Hanem az, hogy a skálázhatóság a programozó részéről nem kíván olyan komoly erőfeszítést, mert a nyelv, a paradigma adja. Szemben egy sima procedurális, vagy objektum-orientált nyelvvel, ahol egyébként már szintén vannak rá egész jó alternatívák, lásd pl reactive programming (bocs Ádám :)). Az igazi, felülmúlhatatlan előnye viszont az, hogy nincs állapot, legalábbis elméletben. Én ide tenném a sok felkiáltójelet :) Ezen kívül az összes többi megoldható nem funkcionális nyelvekben is (immutability, transactional memory, message passing stb), adott esetben sokkal hatékonyabban. De ott van állapot, az pedig bugforrás.