Ti,hogy értettétek meg az oop-t?
Ü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?
■ Ezért elkezdtem a c# és beleolvastam az oop be,de nem igazán értem.
Ti,hogy értettétek meg az oop-t?
Az objektumot úgy lehet
Thinking in Java
Sajnos
Jó ötlet
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.
Belenézek
Szerencse angol tudásom eléggé jó koromhoz képest.
Lehet valami angol nyelvű szakirodalom lesz belőle!
Vagy ténylegesen egy tanár!!!!
Ha Delphi
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.
Én sokat olvastam, és egy idő
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...
Példákból tanulok
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
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!
Nem biztos, hogy jobb az
:)
Na ez elfelejtődött. Az oop
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...
Úhh
Úristen egy szót nem értek belőle :) TDD SPR
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. :)
Nem is kell még
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.
https://github.com/inf3rno/we
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.
ez igen
Csatlakozom
Ja, ez már beteges,
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
OOP?
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.
Nekem ennek a projektnek a
- 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.)
Szerintem jól átlátható a
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.
Nem csak évek múlva
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.
Az OOP változatban legalább
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.
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.
Á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.
Lehet, hogy az, fogalmam sincsen. Régóta nem foglalkoztam a témával.
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.
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.
»Az OOP változatban legalább
Ezek mérési adatok, vagy fogadjam el bemondásra?
Nem tudom, hogy ezeket milyen adatok alapján írod, nekem teljesen ellentétesek a tapasztalataim.
Még mindig itt tartunk?
Miért van az, hogy a Weblabor ma egyenlő azzal, hogy mit miért ne használjak?
Még mindig
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?
Komolyan?
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.
+1
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?
+1 +1
Viszont jelenleg elsősorban Ádámon múlik, hogy mi lesz, lesz-e "Nagy Találkozó" (és mikor...).
Fentebb számokkal
É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.
Fentebb számokkal
Vannak olyan helyzetek, amikor nekem is kikerekednek a szemeim. :D
Véleményes...
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.
Amit írsz a hatezer soros
Nekem az a tapasztalatom,
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.
Gábornak is
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...
Szimpla matek. A procedurális
Nem fogadtam szkeptikusan, mérnök vagyok, nem szeretem, ha hasraütésre mondanak dolgokat.
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.
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.
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.
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...
Tesztek: nézd meg a
Itt
https://github.com/inf3rno/weblabor-forum-115535-framework/commits/master
Nekem ez akárhogy is nézem 1 óra és 54 perc.
Nem értem ez az egész hogyan jön ide.
Akkor nem értem, miért írtál
Erre a következőt írtam:
Egyébként meg nagyon nem tudod másképp megcsinálni, ha meg szeretnél felelni az SRP-nek és egyéb elveknek.
Középút
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 jó keretrendszer alatt. Akkor nem is (vagy sem) kell annyi felé darabolni.
Nem
Én nem mondom, hogy tökéletes
Lehetséges..
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
oop
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.
Ez hibás hozzáállás! Az
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...)
Az objektum orientált
Biztos, hogy ugyanazt értjük
Újrahasznosíthatóság
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.
És ezt a laza csatolást OO
Nyilván meg lehet, hiszen a
Nem. Én csak azt vitatom,
Senki nem mondta, hogy
Kötexem
(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 :) )
vastag idézőjel
szerintem
Igen, egyrészt a
KISS
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.
Az öröklődés, polimorfizmus
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 :)
Fontos és kimaradt
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.
Az ilyen beszúrt (include)
- 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.
$menu = new Menu(); $menu->beolvas();, vagy pedigmenu_beolvas();parancsokat adunk ki.Ez hogy jött már megint? :)
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.
Érdekes egyébként látni, hogy
Ó 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...
Ó ez egyáltalán nem csak
Az a csont messze nincs még
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.
a kompozíció teljesen ismert
A composite pattern szerinted micsoda?!
Az iskola célja, hogy olyan
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.
Lassú
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.
Megnézném
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.
Nekem erről csak az jut
Nekem erről csak az jut
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.
Csak saját véleményem: mire
Csak saját véleményem
A procinak semmit sem jelent
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 ú. ;)
Az utolsó gondolatról volt
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.
Én is kb erre jutottam, ezért
Kész!
Biztos van benne sok hiba,de egy elsore talan megertettem az oop lényegtét!
ok.php
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.
:):):)
Hiba
$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.)
Lehet
Pl:Mit lehetne rajta biztonságossá tenni?
Érdekelne a véleményed
Biztonság!
Két nagyobb hiba is található a rendszerbe.
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
Ha programozni szeretnél
Tesztelve,de
Hibakeresés
Az utolsó else-nek kapcsos
Javaslom, hogy tedd a forráskódot olvashatóbbá behúzás használatával.
inferno+1, az OOP-t valós
Igen
c#
Szakítottam időt a témára,
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:
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.
Gratulálok!
Csak gratulálni tudok!
Próbáld committok szerint
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...
Gábor, én most visszaváltok kisbetűre ;)
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.
Akkor ezt vegyem úgy, hogy
("procedurális programozáshoz supermennek kell lenned" - COBOL-ban, PL/I-ben dolgoztam valaha, ott nem volt jellemző az OOP ;) )
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.
Akkor ezt vegyem úgy, hogy
Ez így van. Lebuktál Clark! :D
vitán felül jobb az OOP.
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.
É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.
Válasz a 75-re
OOP:
- 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.
Singleton egyesek szerint az
Tudom, és persze minden
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?
Köszi
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.
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.
Magasabb/több rétű logikai kapcsolatok jelenhetnek meg a kódban. (Pl annotációk révén).
Á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.
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:
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:
A refaktorálás költséges dolog, és ez a költség nem linárisan nő a kód komplexitásával.
singleton, globális változó stb.
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.
Sokmindentől függ
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.
Kicsit később előszedem a
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?
szóval elővettem... :)
Régi nyűgöm: parancssori
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...
Így a jövőben készíthetünk
A második kódod nekem hibásnak tűnik a "class klassz"-tól lefele.
Ellenkezőleg
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.
Szükség van-e a klassz
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.
JA, copypaste
És mi van akkor, ha nem
Igények
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.
Sosem tudhatod, mit hoz a
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.
"Egy idő után"
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).
Ha van egy rendszerterv és
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.
Enélkül viszont minden
Egy jobban szervezett kód egyáltalán nem bonyolultabb, sőt...
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.
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
Egyszerűen észereveszed, hogy
... és a válasz gyakran igen.
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.
Singletonnal egyébként olyan
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).
Szükséges
Ahol te machetét
A machete jó film :D :D :D
Mindig implementációban
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.
Ha a sebesség lenne a lényeg
Állapot
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.
Más té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).
Értem, tehát akkor az állapot
Általános
Csak hogy valami értelme is
Minőségi kódok?
(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?)
Drupal
Érdekes
Az mondjuk látom, hogy az autoloader-nek nehéz dolga van: https://github.com/drupal/drupal/blob/7.x/includes/bootstrap.inc
Ahogy néztem a globális
Sajnos nem, a saját kódok nem
Ne saját kódot!
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.
C
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ő.
PHP?
Azt hittem, hogy csak neked
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.
Tehát nincs vállalható PHP-s példa?
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?
Persze
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?
Vicces...
Re: C-ben írt könyvtárak és operációs rendszerek
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.
A c egy nagyon jó nyelv.
Absztrakció
(...)
- 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
Én még mindig a PHP-ről beszélgetnék...
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?
Ám azt nem látom, hogy mindez
Mert az "Egymilliárd légy nem
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...
Mellébeszélés
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.
Ne ess túlzásokba, ez csak
Túlzás?
https://twitter.com/tikaszvince/status/496360999000477696
full off
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.
Én egyetlen, nekem nem tetsző
Lehet én emlékszem rosszul, de mintha ... :D
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 ;-)
Megírnád privátban, hogy
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.)
Ja az más. Azt hittem a
Azért nem mindegy, hogy a
Ezek a viták pár hetente
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.
Szerintem baromi unalmas, és
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...
Tudom, hogy nem te
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)
Talán két éve kérdeztem,
Azóta persze változhatott :).
Én is úgy emlékszem, hogy
A néhány jó blogmark miatt
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.
É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.
Ő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.
Miért írna bárki cikket
Gábor, szerintem azért
Jó.
Ha érdekel, olvass utána. Nem
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.
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.
Alternatívát mire?
Ha érdekel, olvass utána. Nem
Nem lejáratni akarlak, mivel
É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.
Okkal kérdeztem.
Nagy tevedes
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?...
Nem az a problémám, hogy
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.
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.
Minden relatív :)
A blogmarkokat azért ne
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.
Szerintem inkább pozitív
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.
Semmi gond a
Igen
Na ez jó volt így a nap
Személyeskedés
Megragadnám az alkalmat, hogy
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.
Rossz kifogás
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á.
Tehát van az a pont, amikor
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.
Tehát van az a pont, amikor
Abbahagyni
Rendben
+1
Vagy hagyjuk elmenni, vagy
É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.
Valóban jobb hasonlat.
évek óta attól hangos a
Komoly példák?
É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.
Azt viszont tényleg nem
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.
A C-ben és a PHP-ban annyi a
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.
Szerintem az egyik fő baj az,
Procedurális paradigma
A kevesebb kód könnyebben átlátható és karbantartható.
Procedurális paradigma
Paradigma
Fentebb írtam. Azért, mert
Annyit hozzátennék, hogy egy
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.)
Drupal
Az idézett dokumentum T.G.
"É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
Szembesítés
É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
Van személyes ismerősöm
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ő.
Az adatbázis cseréje téma
Találtam egy idézetet arról, hogy miért jött létre a C++:
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:
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...
OOP performancia
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.
Nem tudok érdemben
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...
Én valóban ledöbbentem,
É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:
Ú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.
Prototípusba?
Ami körülötte van az egy
Kösz
Á annyira nem. Egyébként
Találtam egyet neked, a
Tipikus procedurális kód?
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?
Szerinted attól lesz egy kód
Fordítva!
Ám, ha használsz láthatósági megkötéseket, a kódod már nem tipikus procedurális kód.
A C-ben is használhatsz
Mindegy...
Ez egy gányolt oo kód, nem
+1, C-ben vannak profik, pl
Csak, hogy teljes legyen a
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.)
...
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.
Kicsit visszaolvasgattam...
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.
Végre, egy egész objektív
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)?
Te pontosan mit értesz
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.)
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.
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.
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ő.
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.
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.
Zárszavadra
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.
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.
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)?
Az ö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 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.
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ó.
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...)
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.
(Kivétel itt is van: a
Ezek alapján a JavaScriptet például hova sorolod? OOP vagy funkcionális?
JS
jo pap is holtig tanul...
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.
Javascriptben például nincs
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.
Sok nyelvben
js
Nem?
szemlelet
Nem az igazi szerintem.
A típusosságnak nincs köze
Ez így nem teljesen igaz: az
Akkor itt most lehet volt egy
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ő.
Végső soron típusok nélkül
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.
Az egyik definíció szerint az
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.
Ha típusosságról beszélünk,
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.
Igen, ez így OK. Most kicsit
Én úgy gondolom, hogy az
Érdekes
- 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.
Végső soron típusok nélkül
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?
Attól, hogy egy nyelv nem
Csak innentől már ingoványos,
Így van, ezért is írtam azt,
Nem mondom, hogy az OOP
Szó se róla, gondolkodás
+1
A fentiek szellemében a
Ezzel teljes mértékben egyetértek, az interface-ek hiánya js-ben nagyban lerontja a kódbiztonságot.
"a Javascript típusos nyelv"
Ehhez lásd feljebb a 239-est.
Polimorfizmus
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).Én továbbra is tartom, hogy a
Van
Nem ártana definiálni, hogy
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.
Nem hiszem, hogy szükséges
É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.
A public-private
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.
Költői kérdés
Szerintem nem. De leginkább
Akkor rövid úton le lehetett
Mit, hogyan?
Vagy el se kezdeni :).
Minek?
(Úgy látom, hogy így Gábor
na na
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... ;)
Üldöz téged a franc :).
Köszönöm
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).
A nevedet igazán megadhatnád az adatlapodon.
...
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.
É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.
Részemről köszönöm a
Én is köszönöm...
Alternatíva?
Most éppen Gót
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.
A Go nagyon jó nyelv, de egy
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.
Egy új projektnél, ahol egyik
Dolgoztam és néha kénytelen
Jó látni néhány friss
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...
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ő...
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).
...
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.
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 :).
A funkcionális programozásról
Funkcionális
<xsl:variable>, rekurzió.Azt írják, hogy hiányoznak
ne is
Szerintem neked egy regebbi nyelv kiprobalasa lenne jo, amiben egyaltalan nincs oo de fvek igen.
funkcionális programozásról egy rövid összefoglaló
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ó.
Én Erlang-ot látom sokszor
Csak hogy rosszat is halljál:
Scala
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.
Én elég komolyan fogadtam a
Sajnos...
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é.
Ez a téma a jelenkor egyik