IDEs Are a Language Smell
Ha a hatékony programozáshoz nagy és sok funkciót biztosító IDE szükséges, akkor ott gondok lehetnek a nyelvvel
■ H | K | Sze | Cs | P | Szo | V |
---|---|---|---|---|---|---|
25 | 26 | 27 | 28 | 29 | 30 | 1 |
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 | 1 | 2 | 3 | 4 | 5 |
Egyetértek azokkal, akik
Amit elolvastam belőle, annak alapján komplett hülyeség az egész.
Ennyi?
Miféle érvekre számítasz
Senki sem kötelez IDE használatára.
Ha használod, azért teszed, mert kényelmesebb, mint nélküle, nem azért, mert az épp használt nyelvet nem lehet egy vim szintű szövegszerkesztővel használni.
Akit zavar, az fejlesszen assembly-ben, ott viszonylag kevés segítséget nyújt egy IDE.
Ő sem azt írja, hogy az
De ennek mi köze a nyelvhez?
Írja a cikk
Tehát ha egy nyelven nem, vagy csak nehezen lehet IDE-ket (is) használva fejleszteni, az nem feltétlenül az IDE hibája. Lehet, hogy a nyelv rossz, vagy te csinálsz valamit rosszul. Mindkettőn érdemes elgondolkodni.
Hogy valamit én csinálok
De ez itt nem egészen azt jelenti, amit te írsz.
Szerintem ez arról szól, hogy "... ha szükséged van IDE v. egyéb, komolyabb eszközre a fejlesztéshez, ... akkor vagy te csinálsz valamit rosszul vagy a nyelvvel van gond". Ezzel viszont nem igazán tudok egyetérteni.
Főként azért nem mert, a kódon belüli navigációhoz szükséges "nehézsúlyú" eszközök általában nem a nyelv, hanem az API, a keretrendszer stb. miatt szükségesek.
A fentivel kb. azt állítja, hogy mondjuk a swing a java része. Holott az már csak egy java-ban írt eszköz.
Swing?
Öhjajj... Azért említettem
Azért említettem _példaképp_ a swinget, mert az kellőképp bonyolult ahhoz, hogy miatta már kedvet érezzen az ember ahhoz, hogy IDE-t használjon a fejlesztéshez.
Holott a swingnek a nyelvhez nincs köze, csak egy keretrendszer.
Ő meg egyre azt erőlteti, hogy a nyelv hibája(amennyiben nem a sajátod), ha IDE-t használsz.
A keretrendszerek pont
És ezekkel mi a baj? A
Ezekkel az a baj, hogy
Egyébként nem kötelező többezer soros mammutokat gyártani egyik programozási paradigma esetén sem, a moduláris programozási elveket már az OO előtt használták.
Ezekkel az a baj, hogy
Pl? És miben mérjük a hatékonyságot?
Így hirtelen amire nem feltétlenül célszerű OOP megoldást választani, az pl a kernelközeli programozás. De az üzleti logikák implementálására nem igazán van hatékonyabb programozási paradigma. És azért javarészt ezt végzik a programozók.
Kevertre (pl PHP) igen, egész pontosan az OOP részére. Procedurális kódra ezeknek viszont nincs túl sok értelme. Ettől még egy c-hez is célszerű IDE-t használni.
Alapvetően pl a Java is egy moduláris nyelv. Package->osztály->metódus. A modularitás a funkcionális elkülönülést biztosítja. Ettől még az üzleti logikát egy láncban kell megvalósítani. 1 fv, 1 feladat. Ha a feladat nagy, a függvény is nagy lesz. Nincsenek igazán hatékony építőkockáid, amiket cserélgethetnél. A függvény B függvényt hívja meg, ezért A függvény működése minden esetben azonos lesz. Ha ettől kicsit eltérőt szeretnél, kell csinálnod egy A' függvényt, ami copy-paste-tel, és sorhalmozással jár. Az OOP erre mást mond, sokkal kezelhetőbb, karbantarthatóbb, továbbfejleszthetőbb, emberileg olvashatóbb programok jönnek létre. És ennek következményeként sok kicsi file, ami szintén jobban tükrözi az ember gondolkodását.
Ezek miatt a mai szoftverfejlesztés elsődleges fejlődési iránya az OOP nyelvek területén van. És szintén ezek miatt jönnek létre az egyre nagyobb tudású IDE-k, kód analizátorok stb.
Így továbbra sem értem, hogy ezzel mi a baj igazából.
Object-oriented design patterns in the kernel
Nos vannak akik nem értenének veled egyet: Object-oriented design patterns in the kernel (-:
Azt, hogy valamit meg lehet
nem feltétlenül célszerű !=
A kernel pedig nem csak a számítógépekre írt kernelt jelenti, hanem a mikrohw-kre írt programokat is. Ezért volt a feltételes mód. És azért az kétségtelen, hogy az OOP-nek van egy kis többlet memória igénye. Nem véletlenül van pl a Javanak is CLDC specifikációja, amiben szinte alig van valami (előredefiniált) osztály.
Ha nem gond, a felvetéseidre
Pedig ez érdekelne kifejtve,
Pár példa,
- A mai ipari felhasználású PLC-k többsége;
- Folyamatirányítási és ~szervezési vezérlések / szabályzások sokasága;
- Kisebb-nagyobb hardverek ROM-ja, FROM, stb....
amikre lehet, de értelmetlen:
- Olyan szoftveres feladatok, amik az adott gép működése során rendkívül sokszor futnak, vagy más okból kritikusan fontos, hogy a lehető legkisebb memória- és prociigénye legyen (pl. kernel);
- Gépközeli nyelven is aránylag könnyen megvalósítható feladatok;
- Ha a továbbfejlesztés csaknem kizárt, mert az pl. a hardver cseréjekor szükséges, és a hardver tartalmazza a szoftvert is (pl. fényképezők, egyéb eszközök.)
Mindkét csoportban a "gépi kód" (assembly és hasonlók) vezet, PLC-khez szokott lenni asztali szoftver, amivel létradiagramozni lehet és / vagy egyszerű (struktúrált) nyelven molyolni, végén transzfer.
Azt hiszem, ezekkel az
Nem teljesen értem
Nekem először a funkcionális programozás jut eszembe, amivel pl. Javascriptben rövid tömör érthető kódot lehet írni. De ilyeneket nem minden nyelvben lehet alaklmazni (pl. parciális függvényhívás)
Nem kizárólag OOP pl a C++,
Sem a PHP sem a C++ nem OOP
(Mellesleg legtobb nyelv a kevert paradigmak fele halad. .NET/C#-ba sem veletlen toltalk bele a LinQ-t (kis funkcionalis elem, az egyebkent imperativ nyelvben))
Másképp
Amennyiben ez az esély kellően alacsony, akkor tegyük fel a kérdést: vajon miért így lettek megírva? A nyelv miatt? Vagy csak mert megyünk egymás után vakon (avagy mi csinálunk valamit rosszul, mert lehetne egyszerűbben is)?
Továbbra is érdemes mindkettőn elgondolkodni.
És mivel a cikkben nincs egy az egyben kijelentés, hogy a "tool" használat (és méginkább a "tool"-ból, annak használatából fakadó frusztráltság) rossz nyelvet jelent automatikusan, csak annak lehetőségét, valamint ha mind a két (A nyelv a rossz? Én csinálok valamit rosszul?) kérdésre némi vizsgálódás után nemmel válaszolunk, akkor megnyogudhatunk, hogy nincs mit tenni, így kell ezzel boldogulni, vagy a "tool"-on kell javítani.
Bármelyik esetben okosabbak lettünk valamivel, és ez a lényeg. (És pont ezért nem értem, hogy hol a cikkben a trollkodás.)
Hogy kéne kinézzen egy nagy,
Egy java, php, c, vagy bármilyen program is 1 forrásból áll, amit lehet notepadben írni, aztán lehet forgatni/nem forgatni, indítani. Ha kicsit bonyolultabb az alkalmazás egy hello worldnél, akkor azért ez a képlet borul mindhárom, sőt az összes nyelv esetén. Az IDE nem arra való, hogy kódoljon helyettünk, hanem hogy támogassa a navigálást, és egy felületen az arcunkba toljon minden számunkra hasznos infót, analizálja a kódunkat, ajánljon fel quick fixeket, kódkiegészítsen stb. Képzelj el egy refaktorálást egy többezer forrásfájlból álló nagyobb rendszeren IDE nélkül. Vagy egy search references feature-t.
IDE nem KELL egy adott nyelvhez. Csak szerencsére van, és akkor használjuk, mert rengeteget segít. Ennek következtében a cikk valóban jó nagy trollkodás lett. Az őskorban én is nyomtam dosnavigator editorban az assembly-t, pascalt, az OOP-t komoly erőforráspazarlásnak gondoltam stb. Nagyon menő volt, de azért már jórég az egyszerűbb php-s oldalakat is IDE-ben csinálom, mert nem kicsit hatékonyabb így a fejlesztés. És ahogy egy rendszer bonyolultsága nő, ez úgy lesz egyre igazabb. Meg hát... debugoljon a cikkíró text editorban ;)
Létezik hasonló összefüggés, mint amit boncolgat, de nem a nyelv minősége és az IDE hasznossága (szükségessége), hanem a rendszer összetettsége és az IDE hasznossága között. Ez a bejegyzés egy cerkahegyezés, hogy ő Haskell, meg Scala nyelveken programoz. Kb ennyi információtartalma volt. Hát hajrá :) De ha összetett rendszerekhez nyúl, akkor ott is fog "kelleni" IDE. Egy több tíz, százezer kódsorból és sok ember által fejlesztett rendszer esetében ezt semmilyen tökjó nyelven nem lehet megúszni.
Mivel mostanság mellőzöm a
Nézz bele a doksijukba! A wxPython-t leszámítva egyik sem függ programnyelvtől, melyik nyelv hibájaként kellene felhozni, hogy macerás a használatuk egy kulturált IDE nélkül?
A Python önmagában nem olyan bonyolult, hogy bármiféle komolyabb fejlesztő környezet kellene hozzá. De ha bedobsz mellé egy Qt jellegű keretrendszert (PyQt, PySide, wx stb), máris nagyon jól jön mondjuk egy eclipse+pydev páros.
És nem hinném, hogy azért, mert hülye vagyok hozzá...
Arról nem beszélve, hogy igazán nagy programrendszerek esetében elég macerás az élet komolyabb IDE nélkül.
Valaha dolgoztam Magic-ben. Amíg egy-egy kisebb alkatrészt kellett átlátni, még elment. De ha egy egész alrendszert... Hát vért izzadtunk vele, pedig ott egy sor programot nem kellett leírni. Csupa-csupa táblázat volt az összes program. (uniPaas néven találod meg az utódját, ha érdekel)
Csak egy példa: debugger
de
Csak találgatok: nem lehet,
Hadd idézzelek ;)
Azaz, miért minősíti magát a nyelvet az, hogy Programozó Szomszéd Pistike hogyan használja? Tudtommal a php nem követeli meg, hogy echo-val debuggolj :)
Oke, akkor szamoljuk ossze
Egyebkent vicces, hogy emlitet a TDD-t, ahhoz is tool kell (legalabbis nem art). Erdekes modon ez _sem_ a nyelvvel kapcsolatos feature.
Egyetértek az első hozzászólással...
Ha egy nagy és sok funkciót biztosító IDE nem teszi hatékonyabbá a programozást, akkor ott gondok vannak.
completely missing the point
"But furthermore, because a combination of shortcomings in the Java compiler and Javas OO nature, we end up with lots and lots of small files for every interface and class in our system. On any less than trivial Java system, development quickly turns into a game of code- and file-system nagivation rather than programming and code editing."
ezzel mélységesen egyetértek. és a konklúzióval is:
"I can only conclude that the need for an IDE or a heavy "code navigation tool" is a symptom of a deeper problem, if you suffer from tool frustration, it's not necessary your tools that are poor, it may be that your language sucks, or you're not using it correctly."
we end up with lots and lots
Nyilván, de ez nem véletlen. Ráadásul kit érdekel? :) Nem azért trollkodás a bejegyzés, mert nem igaz az a gondolat, hogy az összetettebb rendszereket öngól IDE nélkül fejleszteni OO - vagy ha már célkeresztbe került, akkor Java - nyelven. Azért lesz rengeteg apró file, mert az OO patternek és szemléletmód ezt eredményezik. Már feltéve, hogy jól használják.
Egyébként Java programozáshoz sem kell semmi, csak egy editor, egy javac, meg egy java, tehát ez a következtetése önmagában is hülyeség. Egy komoly nagy (pl ami a java kedvelt vadászterülete: rendszerintegrációs) projectben meg mindenféleképp lesz a végén vagy egy csillió egység (config,descriptor,fájl,osztály,függvény, ... tökmindegy), akármilyen nyelven is íródik. Ahhoz meg hasznos lesz egy IDE, ami összefogja a projectet.
Amúgy az IDE miért is ördögtől való, hogy baj van a használatával?
Szoval most a cikkironak
Trollok
Ezzel szemben ő a saját blogján leírja a saját tapasztalatait, amit az évek során gyűjtött össze. Miért nem lehet elfogadni, hogy valaki bizonyos dolgokat máshogy lát? Elképzelhetetlen az, hogy léteznek olyan programozási nyelvek, ahol IDE nélkül is lehet nagy projekteket hatékonyan menedzselni?
Kérdezem a trollkodósoktól, ők próbálták-e már a blogban említett programozási nyelveket? Mindegyikük kijelentéseket, kinyilatkoztatásokat tesz, mintha tévedhetetlen lenne, egy kérdést sem láttam tőlük. Gondolkoztak-e már azon, hogy az általuk használt nyelvek és eszközök és paradigmák mennyire jók, és kerestek-e és keresnek-e (hisz a fejlődés nem áll meg) alternatívákat? Ha nem, akkor végülis kik a trollok?
Troll pl. aki tudatosan olyan
SZVSZ ebbe a kategóriába sorolható az eredeti iromány szerzője.
("7 éves korom óta programozok" - na ez sokat elmond róla, ha a hét évesen összetákolt valamit programozásnak nevezi :-D)
ui: trollunk (nevezzük így a továbbiakban), ha jól láttam, előszeretettel hivatkozik a Haskell-re. Megnéztem: van hozzá Qt. Használja ezt vi-ból! :-D
Tetézve mindezt Robert C. Martin Clean Code-jában szereplő felszólítással, miszerint használjunk nyugodtan beszédes neveket mindenre (változó, metódus, osztály stb), hiszen a moderni IDE-k pl. a kódkiegészítő funkciójukkal sokat segítenek a gyors gépelésben. Én inkább hiszek Bob bácsinak, mint ennek a ...-nak.
A körülmények ismerete nélkül
Miért ne programozhatna hét éves kora óta? A Legónak pl. vannak programozható masinái, nekem is volt programozható számológépem (később persze), ismerőseimnek gyerekként volt C64-e, amin próbálkoztak mindenfélével. Természetesen ezeket a Móricka-programokat legtöbb esetben nem lehet összehasonlítani egy felnőtt, dolgozó ember által készített kóddal, de az alapokat nagyon jól el lehet sajátítani már ilyen korán.
Uncle Bob
Re Trollok
Ez az egész olyan, mintha azt mondanánk, hogy két pont közötti távolságot, ha csak járművel tudjuk megtenni, akkor el kell gondolkozni azon, hogy meg kell-e nekünk tenni ezt a távolságot? (és, hogy okosabbnak tűnjünk, tegyük hozzá, hogy nem feltétlen kell kizárni a jármű használatát, csak gondolkodjunk el rajta, mert a gondolkodás sosem árt:)
Nehogy már azt nevezzük fejlődésnek, hogy olyan nyelvet keressünk, amihez nem kell IDE?!
Azért segédeszköz a segédeszköz, hogy segítsen minket. Nem is értem, hogy miért merül fel, hogy a segédeszközök lennének a probléma forrásai? :)
A fejlődés abba az irányba megy, hogy sok kis apró újrahasznosítható kódot készítsünk. A blogbejegyzéssel szimpatizálók már ezt is megkérdőjelezik? Vagy csak az a baj, hogy a sok újrahasznosítható kódot több fájlban/mappában tároljuk?
Ami vicces, hogy a blog a C++ -t nem is említi, pedig ugye ott még a header és a source is külön van, dupla annyi fájl, mintha ugyanazt Java-ban implementálnák. :) Szerintem nagyon meredek állítás az, hogy a nyelv rossz, mert sok fájlt használ.
De tényleg a legviccesebb az egészben, hogy mindez még úgy hangzik el, hogy akik az IDE-ket támogatják, ők nem akarnak fejlődni… na ez a trollkodás iskolapéldája.
A másik oldal: mindegyik nyelvnek megvannak a maga korlátai, ugyanarra a kérdésre más-más választ adtak, és egyáltalán nem biztos, hogy a legjobbat. Szükséges, hogy a nyelvek is fejlődjenek, illetve tiszta lappal új nyelvek szülessenek. Mindenki érdeke, hogy így történjen. De semmi köze ne legyen mindennek ahhoz, hogy hány fájlból áll az elkészült munka, és hogy a sok fájlhoz kell-e IDE vagy sem?
Engem jobban zavar, hogy a
"mindez még úgy hangzik el,
Végigolvastam ismét a cikket, valamint az itteni hozzászólásokat, de ilyet senki sem állított.
Szerintem ezt te írtad itt picivel feljebb.
Nem ezt írtam.
OOP?
OOP
Tehát?
1. vannak nagy rendszerek
2. a nagy rendszereknél OOP-t használhatunk
3. nagy OOP rendszereknél sok fájl van
4. sok fájl esetén nagy segítség az IDE
Most akkor melyik állítással nem értesz egyet? Merthogy szerintem ezek triviális állítások és a vége az, hogy szükség van IDE-kre.
Kimaradt
Na ez az
Ezzel együtt szerintem nem troll sem a cikk, sem az itteni kommentek (eddig a pontig). Mindenki elmondta a véleményét, ott, ahol jónak látta. Ami szerinted (vagy szerintem) butaság, az még nem trollkodás, akkor sem, ha erőltetik. Csak akkor, ha semmi más célt nem szolgál, kizárólag azt, hogy a trollra figyelj.
IDEs Are a Language Smell...
A JavaScript esetén a nyelvet kellett megújítani ahhoz, hogy lehessen hozzá jó IDE-t készíteni, lásd Dart (Google) és TypeScript (Microsoft).
Kik a trollok?
- ha egy nyelven való fejlesztést megkönnyít egy IDE használata, az csakis rossz nyelv lehet
- akik IDE-t használnak, azok egyértelműen rossz, buta emberek és visszafogják a fejlődést
Véleményem szerint a cikkíró csak megosztotta tapasztalatát, véleményét, amire ha nem flame-elési vágyból ugrunk rá (olyan dolgokat adva mások szájába, amit nem mondtak/írtak), hanem gondolkodni, fejlődni szeretnénk (akár meglévő elvek megkérdőjelezésével, mert ugye számtalan korábbi tudományos és gondolkodási paradigma, bevett szokás dőlt már meg idővel, holott az volt előtte az egyetlen igaz út), akkor talán a gondolkodásra felhívó cikkeknek is helye van a weblaboron (sőt, szerintem ez a célja, de szóljatok, ha rosszul tudom).
És mint korábban írtam, mivel a cikk nem mond ítéletet senkiről látatlanban (csak kérdéseket vet fel), ezért ha azon elgondolkodva, hogy rossz-e a nyelv (vagy a mögöttes szemléletmód), vagy amire, amilyen módon használjuk, arra jutunk, hogy nem, nincs ezekkel semmi gond, akkor megnyugodhatunk, mert minden a legnagyobb rendben van. Ha viszont valamit észreveszünk, amin akár javíthatnánk is, akkor megint csak jól jártunk.
Mi ezen a felháborító trollkodás, aminek nincs helye a weblaboron?
Egyetértek
Legalább az eredeti poszt
(bocs, egyszer felkerestem azt az oldalt, újabb kattintásokat nem adok neki...)
És te megpróbáltad?
A kiemelés tőlem van. Tehát ha le akarom fordítani az "IDEs Are a Language Smell" címet akkor a következőre jutok (amit Gábor is írt):
Kiemelés ismét tőlem. Tehát senki sem állítja, hogy IDE := rossz nyelv, IDE használó := rossz, buta ember.
Tehát továbbra sem tudsz, akarsz idézni az állításaidat alátámasztó dolgot, mégis te dobálózol trollkodással. Érdekes hozzáállás.
A poszt címe ennyi: "IDEs Are
(language és nem code)
De mint mondottam volt, nem vagyok hajlandó mégegyszer meglátogatni, akkor beleolvastam, szerintem hülyeséget írt, pont.
ui: ha kicsit körülnézel a magyar fórumokon, nem én vagyok az egyetlen, aki szerint a "cikk" szimplán egy kattintásgyűjtő trollkodás, nincs mögötte valós gondolat.
Én sem mondtam, hogy más lenne a címe :)
A többmilliárd légy nem tévedhet elve pedig nem fog meggyőzni. Egy, az állításaidat alátámasztó idézet meggyőzne, akár innen, akár az eredeti oldalról. De ha nem, hát nem. Nekem hasznos volt, neked nem.
ui.: Azt írod beleolvastál, nem pedig elolvastad, részletesen értelmezted. Én a vita (és nem vitatkozás, flame-elés, mert van különbség) kedvéért legalább ötször elolvastam, átolvastam, hogy hátha bennem van a hiba, és írt isteni kinyilatkoztatást a fent említett troll dolgokról, de nem találtam olyat. Viszont az ellenkezőjére tudok/tudtam idézni.
Mindegy, hosszú...
mégis te dobálózol
Vita
Természetesen, de ha a másik
Nem állítottam senkiről, hogy troll lenne
A cikk egyetlen
IDE
Viszonylag kevéssé tűnik
Miért, szerintem
(Meguntam a sok troll-vádat, hát itt egy troll-komment. :))
Miért mindig csak a kódszerkesztés...
Vegyük már észre, hogy egy IDE nem attól ide, hogy egy túlhízlalt szövegszerkesztő, hanem azért, mert egy integrált fejlesztői környezet. A fejlesztés meg nem csak arról szól, hogy ontjuk magunkból a kódot ezerrel.
Anno a Turbo(Borland)
Pedig abban már volt
Profiler szerintem nem volt
De lehet, hogy én emlékszem rosszul.
Profilerre én se emlékszem,
IDE
Tehát ha mondjuk egy Turbo Pascal-t használsz, annak felületével, akkor te egy IDE-t használsz, mert abban szerkeszted, debuggolod, fordítod és futtatod az alkalmazásodat. De ha egy Vim-et felruházol parancsokkal, amivel tudod az alkalmazásodat fordítani futtatni, tesztelni, deployolni, debuggolni, akkor te lényegében te egy IDE-t hoztál létre. Ugyan ez igaz minden szerkesztő alkalmazásra, sőt, manapság nem is nagyon léteznek alkalmazások, amikben ezt nem lehet megtenni, ezáltal szinte minden szerkesztő program pár beállítással IDE-vé alakítható. Ha valaki tényleg olyan alkalmazást használ, ami ezekkel a képességekkel nem rendelkezik, akkor mondható el róla, hogy nem IDE. Szerintem ezek után az egész vita okafogyottá válik.
Jó nézőpont
These two wonderful languages
Most belenéztem egy komolyabb Haskell alkalmazás kódjába (történesen a Darcs verziókezelőjébe), és azért ezt az állítást megkérdőjelezem. A kód maga több mint 200 fájl. Aki ezt fejben tudja tartani, annak azért gratulálok.
Egy fecske nem csinál nyarat
Mindent lehet jól és rosszul is csinálni. Egy múltkori fórumtéma alapján olvastam újra Felhő cikkét, és abban az első példa szerintem tárgyi tévedés, mert procedurális programozásban nem szükséges ilyen kóddal megvalósítani azt a funkciót, vannak rá sokkal jobb eszközök.
kiváncsi lennék, hogy honnan
eleve te szüröd át és választod ki ezeket, vagy valahol már összegyűjti valaki a minden elfogadott best practice-szel szembemenő véleményeket?
a témához: szerintem az IDE ugyanolyan velejárója a programozás fejlődésének, mint az egyre magasabb szintű/menedzselt programozási nyelvek terjedése.
ugyanígy régebben az autók/repülők/minden elműködtek mindenféle elektronika nélkül.
Tyrael
valahol már összegyűjti
Te most tulképp akkor az OOP
Nem azért szeretjük az OOP-t, meg a patterneket, mert mások azt mondják, hogy jó, hanem mert a sokéves tapasztalatunk is azt támasztja alá, hogy ez a helyes irány. És járulékos jóságként egyszerűbbé teszik a fejlesztés számokkal mérését, illetve a céges szabályokhoz igazodást is stb. Legtöbben fejlesztettünk nem keveset procedurális nyelven is, úgyhogy szerintem van összehasonlítási alapunk, ami alapján azt mondhatjuk, hogy ez így jobb, színesebb, szagosabb. Utoljára kb 8-10 éve volt divat értetlenkedni az OOP létjogosultságán. Azóta legalább 2 olyan nyelv is kinőtte magát használhatóságilag is, plusz épültek rájuk olyan toolok, ami nagyon egyértelműen eldöntötte ezt a vitát.
Mindenkinek, aki ismét leállt
Az objektumorientáltság különböző programozási paradigmák összessége: modularitás, adattípusok, összetétel, absztrakció, egységbezárás, öröklődés és polimorfizmus. Ezek közül mindegyik használható és használandó bármely típusos, strukturált nyelven. Az egyetlen kivétel, valójában tehát az, amit az objektumorientáltság a világnak adott, a polimorfizmus.
Kérdem hát, ez utóbbi mennyiben járul hozzá a kód méretének növekedéséhez? Nem inkább arról van szó, hogy a fősodor nyelvei (PHP, Java, C/C++, JavaScript stb.) nem adnak elég tömör eszközöket egy új típus vagy egy algoritmus definiálásánál ahhoz, hogy ne képernyőnyi, önálló állományba kívánkozó kódot kelljen hozzájuk megírni?
Itt van a cikk szerzőjének igazsága: egy valóban típusos vagy egy funkcionális nyelv ilyen eszközöket ad, és ezért lesz tömörebb a kód. De mindennek semmi köze az objektumorientáltsághoz.
Már jóideje foglalkozom a
Nem tudom, miért fáj az egyeseknek a cikk konklúziója? Mivel emberek alkották a programozási nyelveket, miért ne lehetnének hibásak vagy tökéletlen eszközeik?
Az OOP nyújtotta szabályrendszer átlagos programozóknál valóban rengeteg előnyt nyújt, megakadályozza őket, hogy egy csomó alaphibát elkövessenek. Egy nagyon jó programozót viszont abban akadályoz meg, hogy jó programot írhasson, hisz csak korlátokat állít elé.
Figyelembe véve az átlagos és a nagyon programozók arányát, az OOP felé billen a mérleg nyelve, ezen valóban nincs mit vitázni.
Ami érdekes még, amit Blaze említett, hogy az OOP eszközeinek használata mérhetővé tesz bizonyos dolgokat. Ez és a különböző, rutinfeladatok elvégzését segítő könyvtárak, library-k elterjedése (továbbá ide lehet sorolni a CSS3 újításait, amelyek jelentősen egyszerűsítik egy website kinézetének és animációjának elkészítését), nyilvánvalóan látszik az irány az automatizált szoftverkészítés felé.
Szerintem belátható időn belül ugyanúgy "gyárakban" készül minden program, amelyek nem feltétlenül lesznek kicsik és gyorsak, de hatékonyságban és fejlesztési időben verni fogják az emberek által készített társaikat. A hagyományos gyárakkal szemben itt viszont először a kulimunkát fogják programokkal elvégeztetni, és elég lesz pár magasan kvalifikált mérnök a kóceráj működtetéséhez.
Gyárak
Amennyire én ismerem a törtenelmet, ezt a progarm generáló program ötletet nagyjából 10 évent újra és újra elpróbálják és újra és újra elbuknak vele (CASE eszközök, "Majd generálunk kódot UML-ből"...). Ha emlékeim nem csalnak elösször a "No silver bullet" esszében (Mythical Man Month), kerül elő az "essencial complexity" fogalma aholis Fred Brooks megkülömbözteti a software gyártásban előforduló komplexitast aszerint, hogy a konkrét feladat lényegéből adódik-e a nehézség, vagy mert az eszközeink nem igazán alkalmasak a feladatra.
Az eszközöket lehet csiszolni a végtelenségig és minden bizonnyal kell is, szerintem ide tartozhat az, hogy egyes részeket deklaratívan írhatunk le ahelyett, hogy imperatíve magyaráznánk a gépnek.
De a feladat minden kis nüanszát lefedő "tervrajzot" (ha már gyár analógia) nem lehet megúszni. Ennek a tervrajznak a software gyártásban a forráskód felel meg jelenlegi allapotok szerint, legyen az bárhogy is reprezentálva (pl. smalltalk környezetek object browserjei nem fárasztották/fárasztják a felhasználóit fileokkal, a lényeg szempontjából édesmindegy, hogy miképp vannak rögzítve). Nemrég láttam egy remek előadást ebben a témában, érdemes megnézni.
Jelen
A programozón kívül mindenkinek érdeke, hogy az emberi tényezőt minél inkább kiiktassák a munkafolyamatból, hisz pénzbe kerül a képzése, rengeteg idő, amíg megtanul jól dolgozni, pénzbe kerül a "fenntartása", pénzbe kerülnek a hibái. Az más kérdés, hogy az emberiség növekedési üteme mellett mindenféle gépesítés és szoftveresítés nagyon komoly társadalmi problémákat vetít előre.
Jövő
Nem mint fejlesztők, hanem mint emberiség. Mert kényelmesebb lesz a nagy-nagy rendszereinkre rábízni a saját energiaellátásukat, alkatrészcseréjüket, továbbfejlesztésüket -> idővel szépen kitalálja, hogy az ember a legnagyobb kártevő a földön és nincs szüksége rá a saját működése biztosításához...
Nemrég olvastam Zsoldos Péter Ellenpont c. sci-fi-jét, talán a 80-as években írta, meglepően jó könyv. A Plutón egy robotkolónia "él" már vagy 600 éve ember nélkül (nem is ismeri), de végül felkutatja a katasztrófa túlélőit. Érdekes, hogy ha nem tekintem a szerző akkori technikai elgondolásait (pl. fogyasztási nagyságrendek, "rövid út"), akkor nagyon is lehetséges - mármint a sztori.
Szóval ez a kérdés érdekesebb, mint a kiinduló cikk, de még az "életveszély" és a társadalmi problémák előtt szintén komoly gazdasági fejtörést (gondot) is okozna. Az sem jó (gazdaságilag), ha valami hirtelen egy nagyságrenddel olcsóbb (és gyorsabb) lesz...
"Nem tudom, miért fáj az
Nem fáj, csak butaság :) Mi köze egy nyelv minőségének ahhoz, hogy sok file-ból áll, vagy nem? És miért lenne rossz egy nyelv azért, mert IDE-vel jól támogatható és erre kimondottan gyúrnak is?
Itt mire gondolsz? Szerintem ahogy Ádám is írta feljebb, semmi ilyesmi különbség nincs az OO és a procedurális programozás között. Sőt, ha úgy tetszik, az OO nagyon sarkítva sok pici procedurális program. A global scope, vagy namespace a class maga, vannak benne függvények (metódusok), amik kapnak paramétereket. Az OO inkább egyfajta programozási, de főleg tervezési szemléletet ad. És szerintem ez az igazi előnye a procedurális programozással szemben. Procedurális nyelven igazából inkább csak funkcionális szinten tudsz tervezni, OO-ban pedig megvalósítási szinten is. Tudsz az alkalmazásodba tervezni valamiket, amiknek vannak tulajdonságaik és képesek valami funkciót ellátni, illetve definiált kapcsolatban állnak más valamikkel. Még azelőtt, hogy valódi kódot egy betűt is leírtál volna. Ez azért szerintem nem kötöttség, hanem lehetőség :)
Nem akarom elrontani az utópisztikus képedet :), de itt vissza kell kanyarodni kicsit a böngészős száladhoz: a gépeknek nincs intelligenciája. Vagyis csak emberek által definiált szabályok szerint, emberek által definiált működést tudnak megvalósítani. Lehet dobozokat (valamiket) definiálni, és azokat összefűzni egy működő egységgé, de ezt hatékonyan csak egy intelligenciával bíró entitás tudja megvalósítani, a tudomány mai állása szerint ez pedig jelenleg csak az ember. És ma tulajdonképpen ez történik: javarészt előre gyártott dobozokból építgetünk fel egész programokat, ezt hívjuk kód újrahasznosításnak. És vannak azért olyan szkeptikus vélemények is, hogy az AI képes lesz-e valaha hasonló eredményeket felmutatni, mint az emberi intelligencia.
Ez az idő viszont már rég eljött :) Vannak seniorok, architectek, és az implementáció lényegét végző juniorok, még nem seniorok.
De, tképp fáj! Konkrétan
A cikk írója azt állítja,
Az "Itt mire gondolsz?"-ra reagálva:
Az OOP az az Ádám által is felsorolt programozási technikák összessége. Ha egy egészen egyszerű programot is szeretnél OOP-vel megírni, minimum létre kell hozni egy osztályt, és annak a metódusait kell hívogatnod, míg pusztán procedurális programozás esetén elég megírnod egy függvényt (vagy csak a parancsok sorozatát).
Egy teljesen analóg példa: az F1 versenyzők 300 felett száguldoznak elég nagy hatékonysággal, de ha kimennek egy autópályára, ott nekik is 130 a megengedett - a nagy többség miatt. Funkcionális programozásban bármit megtehetsz, szabad a terep, míg OOP-ben már vannak szabályok. Viszont erre írtam a következőt: "Figyelembe véve az átlagos és a nagyon programozók arányát, az OOP felé billen a mérleg nyelve, ezen valóban nincs mit vitázni."
Ha egy egészen egyszerű
Ez így értelmetlen, ne haragudj :) Hello world c-ben:
Erre lennék kíváncsi konkrétabban. Ez jól hangzik, de mit jelent valójában? :)
Vagyis a funkcionálisan programozók jobbak, mint az OO programozók, akiket le kell korlátozni, hogy működőt csináljanak? Ez elég érdekes gondolatmenet :) Én ennek a vitának kapcsán 2 dolgot érzek. Egyik, hogy nincs igazán tapasztalatod az OO programozásban, tervezésben, illetve ha dolgoztál így, nem jól fogtad meg a dolgot és szenvedtél miatta. Ezt azért érzem, mert olyan érveket hozol fel, amik a gyakorlatban nem állják meg a helyüket. A másik, hogy a vita kicsit elapadt az érveid miatt, mert ezek gyakorlatilag "csak" típusú érvek, tehát nem érvek.
Mint korábban írtam,
Azt is írtam már korábban (hadd ne keressem meg, másik fórumbejegyzésben), hogy az OOP-nek az utóbbi húsz évben, amióta programozással foglalkozom, nekiszaladtam már párszor (Pascal, PHP, Javascript nyelveken), de egyszer sem éreztem, hogy bármilyen pluszt hozott volna a procedurálishoz képest, a programjaim nem lettek jobbak tőlük.
Erre lennék kíváncsi konkrétabban. Ez jól hangzik, de mit jelent valójában? :)
Mint írtam, OOP-ben bármit szeretnél csinálni, létre kell hoznod egy osztályt. Ez korlátozza a gondolkodást, mert csak osztályokban gondolkodhatsz, íme, erről egy szórakoztató olvasmány.
PHP-ban csak osztályok
Nem
Így viszont nem tudod
Akkor viszont nem teljesen
De ha olyan függvényt írsz,
Többnyire "OOPárti" vagyok, de
Viszont ha egy OOP alkalmazást a végletekig optimalizálsz (a procira, nem a szemedre!), akkor végül egy struktúrált, néhány fv-ből és rengeteg fv-hívásból álló kódot kapsz, távolról sem OOP-t.
Szerintem nem jól érted, amit
Ennek viszont nincs értelme. Procira nem tudsz csak nagyon alacsony szintű kódot optimalizálni. De igazából már azt is megteszik a compilerek, pl pipelining. Egy mai jó nyelvnek a compilere is sokat optimalizál. Főleg, ha beépített nyelvi elemeket használsz, amire Ádám is utalt. És vannak az olyan megoldások is, mint pl a JIT, amik nem kicsit teker(het)ik meg a kód teljesítményét a frekventált helyeken.
De azért már régóta tudjuk, hogy olcsóbb a hardware, mint a fejlesztési idő, ezért használhatunk legtöbb helyen OOP-t. Ahol annyira fontos a sebesség, pl realtime alkalmazásoknál, ott azt úgy is tervezik. De ez még nem zárja ki az OOP-t. Futnak elég komoly trading alkalmazások pl Javaban, és ha valahol, ott aztán kell a teljesítmény. Pedig OOP, és még csak nem is natív nyelv. Elvileg :) De ott már bejön a GC tuning is, meg minden.
Valójában minden pointerekre
az OOP-nek az utóbbi húsz
Az én tapasztalataim szerint, akinek ilyen tapasztalata van, OOP-n általában classokba sűrített procedurális programozást ért. Érdemes megnézni az OOP patterneket, akkor talán tisztul a kép.
Vagy gondolkozz el azon, hogy pl amire Ádám utalt előbb mennyivel egyszerűbb, és mennyivel biztonságosabb:
Procedurálisban meg kizárólag függvények (eljárások) vannak. Tehát az korlátozza a programozót, mert nem gondolkodhat objektumokban (valamikben), csak blackboxokban, ami bemenetre kimenetet hoz létre.
De, pl az OO hiánya :) Lásd fent.
Az ExtJS-t én nem ismerem, így nem tudom mennyire van igazad, de az, hogy pl egy combo kirakása végigmegy egy pár ősosztályon, az nem jelenti azt, hogy lassabb, rosszabb lesz. Csak azt, hogy könnyebben adsz hozzá új input típust.
Blaze, nem tudod, mennyire
Az általad írt rossz (második) példában a problémát én az Ádám által megadott módon szoktam megoldani, kinézetre nagyon hasonló lenne a te első példádhoz.
Ha valaki hasznosnak találja
A második megoldással az a baj, hogy le kell írni a validációt. És ha valaminek nem írod le a validációját, attól még felhasználhatod, pedig nincs ellenőrizve. Valójában ezt a gondolatot tovább kell vinni, hogy érthetőbb legyen:
form.render()
-t,form.setFormLayoutRenderer()
-t, aggathatsz rá saját validátorokat, amik már pl üzleti logika alapján validálnak:form.addValidator( new AddressValidator() )
. Sőt, mondhatod azt is, hogy doProcess előtt nyitsz egy tranzakciót, sikeres lefutás esetén commit, exception esetén rollback stb... És akkor már ott vagy, hogy egy ilyen egyszerű pici frameworkkel is csak az üzleti logikára kell koncentrálj adoProcess()
-ben.Számomra nagyon hasznos volt
Köszönöm mindenkinek a válaszokat, különösen a példákat, igyekszem azok fényében átgondolni a dolgokat.
A funkcionális programozók
(Procedurálisra gondolsz, a funkcionális más.)
A jó programozó tudja, hogy mikor milyen paradigmát használjon. Az objektumorientáltság nem vallás, hanem bevált gyakorlat.
Nem tudom, hogy ez mennyire
Kicsi. Nagyon kicsi. Nagy projekt az 1M loc felett indul. Egyébként olyan érzésem van, hogy te kevered a funkcionális (pl. Scheme, Lisp...) és az imperatív procedurális nyelveket (C, Pascal, stb.) nyelveket.
Az öröklődés is OOP elem. A
Ami a méret növekedését illeti, egy tízezer soros kód ugyanúgy nem áttekinthető eszközök nélkül, mint egy százezer soros; a Java kétségkívül egy bőbeszédű nyelv, de aligha ezen múlik, hogy szükség van-e IDE-re, még ha csak a navigációs képességeket nézzük is.
A cikk egyetlen érvényes pontja szvsz az, hogy a debugger az imperatív paradigmák sajátsága, és egy valódi funkcionális nyelvben nincs rá szükség, illetve nem is teljesen értelmezhető (helyette a kiértékelési fa bejárásában segíthetnek az IDE-k).
A Java amúgy miért nem valóban típusos?
Az öröklődés is OOP
Öröklődés nélkül a polimorfizmusnak nincs értelme.
De az a kód, ami A nyelven tízezer soros és áttekinthetetlen, az B nyelven, ezer sorban már áttekinthető. A nyelvek felelőssége, hogy a mindenkori jellemző kódállomány kezeléséhez megfelelő eszközöket biztosítsanak. Az egyre újabb és újabb nyelvi eszközök megjelenését mindig a folyamatosan növekvő komplexitás hajtotta.
Ha egy nyelv bőbeszédű, vagy nem ad elég magas szintű eszközöket, akkor a kód hosszabb, amit nehezebb kezelni, szerintem ezzel nem lehet vitatkozni. Például Javában egy egysoros map átadásához létre kell hoznom egy teljes új osztályt, ráadásul a hívás helyétől messze, ami sokkal nehezebben áttekinthetővé teszi a kódot.
Csak osztályokat tudok létrehozni, amik kilógnak a beépített típusok közül. Nem tudok létrehozni például saját skalár típust, hozzárendelt értéktartománnyal.
Ha egy nyelv bőbeszédű, vagy
Azzal viszont igen, hogy egy reális bonyolultságú feladat (nem hello world) magas szintű eszközökkel kezelhető méreten belül marad. Ezer sorból funkcionális nyelven sem raksz össze egy komplett alkalmazást.
Mindenkinek, aki ismét leállt
Az objektumorientáltság különböző programozási paradigmák összessége: modularitás, adattípusok, összetétel, absztrakció, egységbezárás, öröklődés és polimorfizmus. Ezek közül mindegyik használható és használandó bármely típusos, strukturált nyelven. Az egyetlen kivétel, valójában tehát az, amit az objektumorientáltság a világnak adott, a polimorfizmus.
Igen is, meg nem is. Nyilván egy procedurális nyelven is növekedik a kódmennyiség, viszont ami különbség, hogy a procedurális programozás igazából csak az implementációt ismeri, egy jó OO kód alapja pedig az absztrakció (interface->abstract class->bővebb abstract class ... -> implementáció -> implementáció kibővítése ...), jóval több a definiálás, öröklődés stb. Hogy a sorok számában ez hoz-e növekedést, azon lehet vitatkozni, bár szerintem ez nem is érdekes. Az eredeti bejegyzés felvetésében a file-ok mennyiségén van a hangsúly, ez pedig egyértelműen igaz. De bennem továbbra is kérdés, hogy ez miért baj, miért kéne bárminek is a minőségét mérni azzal, hogy hány file-ból áll? Ki az, aki ma egy komolyabb rendszert IDE nélkül akar megcsinálni? Ha meg van IDE, akkor miért ne használnánk ki a tudását?
Sőt, ha már a kód minőségének mérésénél tartunk, a jelenlegi elvek ezzel pont szembe mennek: minél kisebb egy adott programegység (osztály, metódus) mérete, annál jobbnak tartják, mert annál definiáltabb, vagyis átláthatóbb, karbantarthatóbb az egység működése (code complexity).
a procedurális programozás
Ez nem így van, ahogy fent is írtam, az objektumorientáltság egyetlen újdonsága a polimorfizmus volt. Az absztrakciót nem az OOP találta fel, bármennyire is fáj (az eljárás mint olyan az absztrakciók ősapja).
Szerintem egy dologról
Amiért én írtam a fentit, hogy ennek az absztrakciónak a következménye, hogy mivel (nagy általánosságban) minden class/interface külön file, igaz a blog felvetése, miszerint az OO kód több filet generál. Hogy sorban több, vagy kevesebb ugyanaz a funkcionalitás OO, mint procedurális megvalósításban, az már kérdéses. Ha sok a hasonló funkcionalitás, akkor szerintem elképzelhető, hogy a polimorfizmus miatt sorban pont kevesebb lesz az OO kód. De szerintem ez igazából nem lényeges, mert továbbra sem a mérettől lesz jó, vagy nem jó egy kód, vagy egy programozási nyelv.
Procedurális nyelvben nem
Pedig azért nem írunk üzleti alkalmazást gépi kódban, mert azon az absztrakciós szinten kezelhetetlen a kód mérete.
Ok nyertél, sejtettem, hogy
:) Egyrészt. De főleg azért, mert a gépi kód olvashatatlan "azon az absztrakciós szinten", ahol az üzleti logikát implementáljuk, és ez főleg nem a méretén múlik. Már assemblyben is írtunk macrokat stb. Ebben azért a mai nyelvekben nincs igazán nagy különbség. Aki ismeri a nyelvet és a szintaktikát, az ha ránéz egy jó kódra megérti a működését. És ez a lényeg, ebben mérjük a kód minőségét, nem abban, hogy 20, vagy 30 sor egy logika megvalósítása. Illetve van pl code complexity, de ez már más téma.
De ez azért nem teljesen az,
Nyilván, nem véletlen, hogy az algoritmusok polimorfizmusa után megjelent az adatoké is. Csak zavaró, ha hetven év nyelvi fejlődését húszénak tudjuk be.
Ezt hogy érted?
Nem véletlen, hogy gépi kódot és nem assembly-t írtam. Egy makró új absztrakciós szintet vezet be, és épp a tömörebb kód végett találták ki. Az egyre magasabb szintű nyelvek pedig mind egyre kifinomultabb makrók a gépi kód fölött.
A kódét igen, a méret mellett egyébként, hisz a redundáns kódot sem tartjuk jó minőségűnek. A nyelv esetében azonban fontos, hogy a lehető legtömörebben fejezze ki, amit kell. Ez egyébként a természetes nyelvek esetében is igaz.
Csak zavaró, ha hetven év
Erről szó sem volt.
Arra, hogy ha egy programozó
Erről szó sem volt. Sokan
Sokan vannak, akik azt hiszik, a szép új világot a Java jelenti és hozta el a világnak.
A másik felvetésre: Az Intel és a GNU assembly szintakszis elég ocsmányak, de ez nem a dolog természetéből fakad. Semmi akadálya jól olvasható, a magas szintű nyelveket követő szintakszisú assembly nyelvet írni (létezik is). A gond az, hogy a processzor által nyújtott műveletek annyira elemiek, hogy egy üzleti alkalmazás követhetetlen velük. Itt lép képbe a strukturálás és az absztrakciók.
Sokan vannak, akik azt
Az azért kétségtelen, hogy egy nagyon komoly hatású nyelv, hozott (elismertett) pár dolgot a mainstream programozásba (VM, platformfüggetlenség, pure OOP), amiknek a létjogosultságáról, de legalábbis hatékonyságáról korábban azért voltak viták a szakmán belül. És tegyük hozzá, a Java is kínlódott vele eleinte. Ma pedig a Java sikeressége miatt más nyelvek is egyre inkább építenek ezekre. De hát nyilván előtte is volt élet, és a Javaba is összelapátoltak sok más nyelvből jó ötleteket. De a Java se véletlenül van itt már közel 20 éve, na :)
A C-re meg hatványozottan igaz ugyanez. Elképesztő, hogy már 40 éve (pont idén 40) itt van, és még mindig az egyik legnépszerűbb programozási nyelv.
Összetöröd a nosztalgikus érzéseimet :) Én imádtam assemblyben programozni. De az tény, hogy nem túl valószínű, hogy találkozunk még valaha. Mostanában épp egy nagyon szűk erőforrású mobiltelefon chippel dolgozok, de már ez is Java. Lassan a vasalóban is Java fog futni :)
Egységbe zárás
Hibaellenőrzés meg mindenhova kell. Pont két hete volt erre egy nagyon jó példa: egyik user egy törölt szállítási módot bökött ki egy rendeléshez (hogy a használt ügyviteli rendszer miért enged ilyet kiválasztani, azt hagyjuk...), ami a webre való szinkronizáláskor dobott egy exceptiont, mondván, hogy nem érvényes szállítási mód.
(Ilyen enumszerű képződményekre - miután nincs rá nyelvi elem - szoktam használni PHP-ben ilyesmiket:
Persze, lehetne így is:
Arról nem is beszélve, hogy ha leírom, hogy Valami:: akkor egy normálsi IDE már ajánlja fel, hogy mik vannak.
Itt most mire válaszoltál?
Arra, hogy azért van más is a
Sejtettem, köszönöm.
C-ben is működik az
Szerintem kevered az
Szerintem pedig nem
Maguk a fogalmak
Egységbe zárás azt jelenti, hogy nem választjuk el az adatokat és az azokkal dolgozó függvényeket, hanem egy egységben (osztály) kezeljük. (Pl. Complex osztály tartalmazza az azokon végzett műveleteket.) Ezt C-ben nem tudod megoldani, mert nincs olyan, hogy egység.
Adatrejtés meg azt jelenti, hogy az adatmezőidet elrejted a külvilág elől és csak ellenőrzött függvényhívásokon keresztül éred el. (Bár személyes véleményem az, hogy pl. Java-ból naaaaaagyon hiányzik a property fogalma, ami C#-ban nagyon-nagyon sok felesleges kódtól szabadítja meg az embert, valamint a setter/getterek is sokkal-sokkal átláthatóbbak.)
C-ben ezt sem tudod jól kivitelezni, mert vagy mindent elrejtesz vagy mindent megmutatsz. Készíthetsz függvényeket, amelyek visszaadják egy opaque struct egy mezőjét, de akkor már sérül az egységbezárás elve, hiszen ez a függvény nem a struct része.
Zárójelesen hozzátenném azonban, hogy egy OOP nyelvben is rendszeresen előfordul, hogy hébe-hóba meg sértjük az adatrejtés (pl. reflection, friend class C++-ban, internal láthatóság és friend assembly, bár utóbbin el lehet vitatkozni, hiszen a .NET Assembly egy újabb egység) és az egységbezárás ("helper" osztályok a komplexitás csökkentésére) elvét, de azonban ezekre rendszerint van valamilyen kontrollált megoldás.
Maguk a fogalmak
Én láttam, hogy az adatrejtésre adtál példákat, ezért úgy gondoltam, hogy az egységbezárást az adatrejtés elvének egy lehetséges megvalósításaként értelmezed. A vonatkozó Wikipédia szócikk egyik értelmezése ez.
De, C-ben is van egység, compilation unit a neve. De az osztályok szerepét ebből a szempontból a struktúrák tökéletesen betöltik, hisz a
struct a
-hoz írt függvényt nem tudom meghívnistruct b
-re (sajnos C-ben a paraméterek nem részei a kézjegynek, ezért meg kell különböztetni a függvényeket, de ez tervezési hiba, nem a paradigma sajátsága). Az pedig, hogy a függvényt a struktúra definícióban adom-e meg, aligha képezi tárgyát az egységbezárás elvének (C++-ban például a tagfüggvény definícióját az osztályon kívül adom meg).Ez sem igaz:
Ezért elv és nem törvény :)
Az pedig, hogy a függvényt a
Félreérted: nem arról van szó, hogy az implementáció és a deklaráció elkülönül-e vagy sem, hanem arról, hogy egy egységed van. Maguk az adatokhoz tartozó műveletek nem kapcsolódnak sehogy sem a structhoz, teljesen önálló kicsi egységeket alkotnak.
Ok, jogos, nem tudtam, hogy forwarded delcaration-nak meg lehet adni törzset. Bár azért tegyük hozzá, hogy normális OOP esetén alapból mindent rejtesz és csak a megfelelő setter/getteren keresztül (ami jobb esetben property, rosszabb esetben függvény) érsz el mindent.
(b*)(void*) ;)
Félreérted: nem arról van
Mitől tartod őket egységnek más nyelvekben? A C forráskódban fizikailag a függvények önállóan jelennek meg, a típusrendszer azonban hozzáköti őket a struktúrához. C++-ban ugyanehhez kapok szintaktikai édesítőszert: a tagfüggvényeket ugyanúgy a rejtett
this
paraméter típusa köti egy struktúrához.Itt csak arra reagáltam, hogy nem mindent vagy semmit kell elrejts, illetve megmutass. Persze, normális esetben a lekérdezéshez és a beállításhoz függvényt írsz, ami, ahogy fent írtam, nem sérti az egységbezárást, mert ahhoz a struktúrához tartozik.
Ugyanígy egy privát tagváltozó is kiolvasható C++-ban :) A típusrendszer arra való, hogy segítse a fejlesztőt, nem arra, hogy bármiben megakadályozza :)
Mitől tartod őket egységnek
Hogy nem egy függvénynek adod át azt, amivel dolgozol, hanem az objektumon végzel műveletet. A tagfüggvény a típus része.
Nyilván Java-ban és .NET-ben is ott a Reflection első szinten.
És itt jön be az, hogy egy OOP nyelvben egy jó IDE-ben ha egy objektum/osztály neve után nyomok egy ./::/->/[] jelet, akkor nekem az IDE egyből dobja fel, hogy mi az, ami az adott objektumhoz tartozik/mit tudok az adott objektummal művelni.
Ami azt illeti, de: megakadályozza, hogy hülyeséget vagy nem kívánt dolgot csináljon. Nem feltétlen azt, aki írja, lehet, hogy más kollégát vagy egy 256.-ként odakerülőt kell megakadályozni valamiben.
Hogy nem egy függvénynek adod
Itt csak magamat tudnám ismételni: attól, hogy más szintakszissal hívok egy függvényt, attól az még csak egy függvény marad.
A hozzá tartozó függvényeket ugyanúgy fel lehet dobni.
Nem: segít elkerülni a véletlen hibákat, de nem akadályoz akkor, ha jelzem neki, hogy tudom, mit csinálok.
Itt csak magamat tudnám
De itt nem csak szintaktikai különbségről van szó, hanem gondolkodásbeli különbségről is. Nagyon sokan azért nem értik az OOP-t, mert továbbra is függvényekben gondolkodnak ahelyett, hogy tagfüggvényekben (vagy sokkal inkább helyesebben: metódusokban és üzenetváltásokban*) és típusokban gondolkodna.
* Rendben van, C++ nem ezt az utat járja és ez végigvonul a Java, C#, stb. vonulaton is.
Mégis hogy? :) Van egy char* a -m, amiben egy stringet tárolok. Hogyan dobatom fel az IDE-vel, hogy mik az ehhez tartozó szövegmanipuláló függvények? :)
Mégis hogy? :) Van egy char*
Leírod a változót, megnyomod a gyorsbillentyűt, és az IDE feldobja azokat a függvényeket, amik ilyen típusú paramétert várnak. Ha kiválasztod, beszúrja a helyére, majd megadod az esetleges további paramétereket.
Messages
computers on a network, only able to communicate with messages...
Lehet ha "üzenet"ként hivatkoznánk ezekre jobban elkülönülnének ezek a fogalmak.
Azhogy egy-egy object milyen üzeneteket ért, éshogy milyen metódusai vannak eleve nem szükségszerűen egy és ugyanaz (lésd még __call(), method_missing, __getattr__, doesNotUnderstand).
Igen, az alapvető probléma
Érdemes utánanézni pl. az Actor modellnek, ahol minden objektum egy önálló kis zárt "programként" (természetesen nem OS szintű thread vagy process-ként kell elképzelni) fut, és csak üzenetváltásokkal lehet kommunikálni egymással. Más világ első nekifutásra.
Más, vannak előnyei,
Pl: AMQP XMPP JMS És még kismillió implementáció és protokoll. Pl egy job tábla is egy message queue, és ilyesmit weben is gyakran használunk. Érdemes ismerni ezeket, ahol lehet (async requestek, pl keresések), nagyon jó eszköz a terhelés kontrollálására (párhuzamos requestek sorosítása). Meg nem nyitott zárójel bezárva :)
Amikről te beszélsz az
Itt magának az objektumnak van üzenetlistája (látszólag, valójában ezt az egészet megoldja jól a runtime, hogy optimális legyen). Ennek köszönhető, hogy egy objektum egyszerre mindig csak egy "hívást" kezel, emiatt nincs érvénytelen állapota (nincs lock!), stb. Ez teszi pl. az Erlangot jól skálázhatóvá. De ez nem okoz lazább kötéseket, hisz ez nyelvi szinten működik.
Csak ez egy egész más megközelítés, mint amin a C++ elindult).
Ami inkább laza kötést ad, az az, amikor mindent Interface-kon keresztül intézel, hiszen elrejti a mögöttes objektum valódi típusát (bár ez a cél) valamint a delegáltak (eseménykezelők, .NET-ben) használata. Bár ezen helyeken általában ez a cél, hogy az egyes modulok, részegységek között laza kötést alakítsunk ki, hogy egymással cserélhetőek legyenek.
Amikről te beszélsz az
Igen, ezt írtam.
De, definíció szerint lazább kötéseket okoz, enélkül nem lenne skálázható. És ne hívjuk objektumnak, hívjuk processnek, mert ez félreértésekre adhat okot (az Erlang nem OOP nyelv). Erlangban processeket tudsz indítani, és a processek közötti üzenetcserére vezetett be nyelvi eszközöket. Ez azért más, mint amit te mondasz. Ha úgy lenne, az egy nagyon durva bottleneck lenne, illetve konkrétan agyonvágná a többszálúságot, amiről azért nincs szó.
Nagyon, más nyelvcsaládba is tartoznak.
Lazább kötés alatt itt egyébként azt értem, hogy nem egy pontosan beazonosítható része fog lefutni a programnak, igazából nem is kell tudd, nem is érdekel mi fogja fogadni az üzeneted. Megmondod melyik processnek és milyen üzenetet küldesz, majd megadod a paramétereket. Ami paraméterek függvényében akár más blokkba is beeshet a fogadó oldalon, de erről nem feltétlenül tudsz. És ez a laza kötés okozza a skálázhatóságot. Ezért írtam az előző hozzászólásomat, hogy erre van mód nyelvfüggetlenül is, mert ez valóban nagyon hatékony eszköz a skálázásra. És a vicc kedvéért van olyan XMPP és AMQP implementáció, amit Erlangban írtak :)
És ne hívjuk objektumnak,
Na most aki magyarázott nekem az erlangról az pont azt mondta, hogy azért ne hívjuk processeknek, mert mindenki az OS processekkel fogja azonosítani és félre fogja érteni :)
Egyébként maga a nyelv AFAIK actor-nak hívja.
Na most aki magyarázott nekem
Hát az könnyen lehet :) Bár attól azért nem áll olyan messze:
És lassan fentről lefelé
Bár személyes véleményem az,
Megoldható javaban is, csak nem a core nyelv része. Bár szerintem hótmindegy, hisz a gyakorlatban ezeket úgyis az IDE generálja :) Úgyhogy én ezt nem igazán értettem sosem. A POJO azért POJO, mert pont ezt a funkciót látja el. Illetve ezzel pont megsértenéd az egységbezárás elvét, ezért van ez leszavazva javaban.
Bár szerintem hótmindegy,
Pont ez a bajom vele, rengeteg generált kód. C# esetén is a CSC odagenerál neked egy valag kódot (valójában nagyon hasonlóra fordul le, mint Java-ban), viszont a lényeges különbség, hogy magában a kódban egy jóval tömörebb, áttekinthetőbb és szemantikailag kifejezőbb nyelvi elem szerepel. Csak egy példa a triviális esetekre:
A 2 megközelítés között
De nekem igazából egyik megoldással sincs semmi bajom. Javanál az IDE, vagy valami legenerálja egyszer ezeket a metódusokat, aztán nem is járok arra többet, C#-ban meg ilyen és kész, az se fáj.
Kontraszt