Mivel tudnek gyorsabban es jobban fizetett helyre kerulni?

> Mivel tudnek gyorsabban es jobban fizetett helyre kerülni?

Tudsz gyorsan bekerülni valahová, és tudsz lassan jól fizetett helyre kerülni.

Nyilván webbel hamar elhelyezkedsz, ha jó vagy lehet több a fizud.

Application deleoperként már kicsit nehezebb, de jobban keresel.

Rendszerprogramozóként sok év tapasztalat hozza meg az álommeló.

Nyilván vannak átfedések.

A kérdésed pedig egy nyelv vita lett, hogy minden más hasonló kérdés is.

Talán mert a kódsorok mérete csak egy mutató a sok közül. Ha a főnök kódsor alapján fizet, akkor persze, hogy az az érdekes, hogy mindnél kevesebb legyen a sor.

Sőt egy bizonyos pontig a túl tömör megfogalmazás a kód olvashatóságát még rontja is, mint hogy elősegítené.

Ennyire nem látom át, hogy miért akkora probléma, hogy osztályszemléletű a nyelv, illetve amiket felsoroltál, de gondolom ennyi cég nem állna mögötte, ha annyira elborult lenne, mint ahogy azt beállítod.

A funkcionális személet mitől jobb? (nem tanultam sajnos(?))

Hol hibázik az a hasonlat? Adott két objektum: autó, ajtó. Mindkettőnek van egy színe és mindkettővel / mindkettőn lehet valamit csinálni: az ajtót be tudod csukni és az autót tudod vezetni és az autónak van mondjuk 4 ajtaja.

Az osztájok az autó és az ajtó. Az osztály metódusai a becsukás meg a vezetés.

Nem értem, hogy az ajtóból miért lenne logikusabb funkciót csinálni?

Egész biztosan van olyan feladatkör, ahol a funkcionális használat célszerűbb és jobban idomul, mint az OOP. És ez fordítva is egész biztosan igaz.

Ezen kívül tudom, hogy vannak nyelvek, amik tökéletesek a funkcionális programozáshoz és szenvedősek OOP-ben és fordítva.

A Java egyértelműen az OOP-t támogatja. Ezt hibának felróni dőreség. Olyan, mint ha lesz*roznál egy Ferrari Enzot, csak mert nem tudsz vele trágyát hordani.

"Ezt hibának felróni dőreség. Olyan, mint ha lesz*roznál egy Ferrari Enzot, csak mert nem tudsz vele trágyát hordani."

Jó hasonlat.

Minden feladatra a neki megfelelő nyelvet kell használni.

Igen, a funkcionális nyelvek is jók, illetve maga a szemlélet, de vannak olyan esetek, amikor fölösleges, de ettől még nem lesz sz*r.

Az OO szemlélet is egy megközelítés, egy halom modell kifejezetten erre épül és köszönik, de elég jól megvannak.

Hogy szemléltessem az érvem, itt van két kódrészlet, mindkettő ugyanazt csinálja. Mindkettő redundáns, refaktorálható, ha egy komplexebb rendszer része. Ebből az elsőhöz hasonlót írnak a Java fejlesztők, a másodikhoz hasonlót pedig olyanok, akik dinamikus vagy funkcionális nyelven kódolnak szívesen.

[link]

Vonatkoztassunk el a konkrét példától, hiszen nyilván egy Hello World-ot ennél egyszerűbben is meg lehet írni, tehát nem erről van szó. Hanem egy újrafelhasználható kódrészletről, ami mondjuk tegyük fel, hogy adatbázisból, vagy egy online forrásból kér le adatot. Tehát hasonlóan valami egy-két soros dologról van szó. Így tekintve a példában szereplő két kód újrafelhasználhatóság szempontjából pontosan ugyanazt a teljesítményt nyújtja. Az, amelyik erősen próbál osztályszemléletű lenni, az csaknem 40 sor. Amelyik nem, az még húsz sincs. Olvashatóság szempontjából mindenképp a második teljesít jobban.

Ráadásul! Példa Python-ban van írva. A második példa, Java-ban nem lenne megoldható, mivel class-first nyelv. Ráadásul, Java esetén ez 3 fájl lenne, és nem 40, hanem legalább 60 sor, de saccra talán még több is.

"A Java egyértelműen az OOP-t támogatja. Ezt hibának felróni dőreség. Olyan, mint ha lesz*roznál egy Ferrari Enzot, csak mert nem tudsz vele trágyát hordani."

És itt értettétek félre a lényeget. Az nem feltétlenül hiba, hogy támogatja az OOP-t. Hanem az, hogy class-first. A hasonlatod szerintem azért nem jó, mert a trágyahordás nem analóg a probléma egyszerű, tiszta, és jól olvasható megoldására... Ugyanis egy olyan osztály, ami csak privát adattagokból, konstruktorból és metódusokból áll, az nem osztály, hanem egy olyan, 20-30 sorban megírt függvény, amiből a lényegi rész 2 sor. Amikor egy komplex modellt építesz fel, akkor tudod hasznosítani az objektum-orientált elképzelést. De attól, hogy valamit osztálynak álcázol, még nem lesz az. A Java fejlesztők rendszeresen osztálynak álcázzák például webes alkalmazások esetén az egyes adatbázis táblákra mappelt modelljeiket. Ilyenkor raknak bele n darab privát adattagot, n darab gettert és n darab settert. Objektum-orientált lett ettől a modelljük? Megvalósították az egységbezárást? Lóp1kulát. Nem 10 soros, 3 másodperc alatt értelmezhető kódjuk lett, hanem 300 soros, pontosan ugyanazt csináló, de értelmezhetetlen, és nehezen kezelhető katyvaszuk. És ilyenkor kezdenek el a Java fejlesztők olyan eszközöket használni, mint például az osztálydiagram generátorok, és az IDE-be épülő egyéb haszontalan vackok, amik mind egyetlen dolgot csinálnak: megpróbálják olyan formátumban mutatni a kódot, mintha az normális programozási nyelven lett volna megírva.

Hibának tehát nem az írom fel a Java esetében, hogy támogatja az OOP-t. Nem. Azt írom fel, hogy rossz megoldást választ erre.

Az OOP sokkal jobban működik object-first megközelítéssel, mint class-first megközelítéssel, különösen ha multi-paradigm nyelvről van szó. Ugyanis az OOP elképzelés egy nagy, mára már beismert hibája az az, hogy ki lehet kényszeríteni azt, hogy a fejlesztő az egész programot OOP szemléletben írja meg. Ez azonban nem működik, és az élő példa rá a Java nyelv.

"vannak nyelvek, amik tökéletesek a funkcionális programozáshoz és szenvedősek OOP-ben és fordítva. "

Az én véleményem tehát nem az, hogy vannak olyan nyelvek, hanem az, hogy egy adott szoftvernek vannak olyan részei. Például, mint megvalósítási modell, a funkcionális programozás az OOP-vel egyáltalán nem ütközik. Önmagában semmit nem ér az OOP, viszont más paradigmákkal együttesen jól hasznosítható.

"Hol hibázik az a hasonlat? Adott két objektum: autó, ajtó. Mindkettőnek van egy színe és mindkettővel / mindkettőn lehet valamit csinálni: az ajtót be tudod csukni és az autót tudod vezetni és az autónak van mondjuk 4 ajtaja.

Az osztájok az autó és az ajtó. Az osztály metódusai a becsukás meg a vezetés.

Nem értem, hogy az ajtóból miért lenne logikusabb funkciót csinálni? "

Nem logikusabb. Ez esetben, egy megfelelő alternatíva az osztályszemlélet. Azonban ha tényleges Java kódokat olvasol, akkor meglátod, hogy az osztályok 70-80%-a nem így néz ki, hanem lényegében csak egy metódus. A gyakorlat ezt mutatja. Egy két soros metódus, külön fájlban, 20 sornyi felesleges, semmit nem jelentő boilerplate kóddal.

Nekem speciel jobban szememre áll és hamarabb megtalálok valamit, ha 20 fájl közül kell kiválasztanom a nekem kellőt, mint ha 200 sorból...

Milyen mód van arra, hogy ha van egy metódusom, abban egy halom adattag és és megvalósít valamilyen működést, majd kitalálom/kitalálják, hogy kellene még egy plusz működés. Hogy érem el a metódus privát adattagjait?

Miért jobb ha egy nyelv inhomogén - osztályok és funkciók és minden, mint ha homogén? Csak osztályok (és egyetlen függény a main)?

A metódus az nem olyan valami, ami elindul, csinál valamit és leáll, kipucolja magát a memóriából. Hol tárolod az adatokat? Globális/lokális tömbökben? Meghatározod, hogy adott metódus csak adott tömbhöz férjen hozzá? Akkor miben más a metódus, mint az osztály?

Most nem egészen értem mire akartok kilyukadni a JAVA -val.

Nekem a legnagyobb gondom vele, hogy lomha, RAM pazarló, CPU terhelő szoftvert lehet benne alkotni.

Webes motornak nem jó, mert a fizetős tárhelyek 90% -a nem támogatja, így ha nem saját szerverre fejlesztesz kizárólag, akkor nem sok értelme van, na'h meg ott a RAM éhsége amit már írtam.

Desktopra megint problémás, a fentebb írt gondok miatt, így nem tudja fel venni a versenyt egy C++ -bab írt programmal.

JAVA egyetlen, és legnagyobb előnye a multi platform, azaz Windows, Linux és Unix alapú rendszereken is használható.

(Mondjuk a QT framework programozásban, elégé utolérte ebben is, hogy a C++ ilyen téren is akár előnybe kerüljön.)

A Python szemlélete az, hogy van egy közös fogalom, amibe több speciális eset is beletartozik. Ez az objektum. Objektum az osztály, a modul, a metódus és a függvény is. Tehát, mindegyikben van valami közös.

Ha például van egy fájlod, akkor az egy modult fog alkotni, amelynek adattagjai a benne szereplő összes objektum. Egy könyvtár pedig szintén modult alkot, amelynek adattagjai az összes benne lévő modul.

Amikor teljesen OOP szemléletben programozol, akkor felfoghatod úgy, hogy egy adott osztály, ami egy fájlban szerepel annak vannak metódusai és adattagjai. Ezek mind szorosan összetartozó dolgokat tartalmaznak, és egy fájlban szerepelnek.

Hasonlóan, Python estében például a modul, ami egy fájlban szerepel, szorosan összetartozó dolgokat tartalmaz. A különbség annyi, hogy nem elvárás, hogy az elvárás csupán annyi, hogy ezeket egyetlen objektumot alkossanak. Az nem kötelező, hogy ténylegesen egyetlen osztály is legyen. De értelemszerűen az osztályokat az esetek nagy részében ugyanúgy külön fájlba szokás tenni.

A fájlok tehát praktikusan rövidebbek lesznek, mint Java esetében, mivel kevesebb a boilerplate kód. A fájlok száma pedig nem azért lesz kevesebb, mert mindent egy fájlba zsúfolsz bele, hanem azért, mert kevesebb osztályra van szükséged, és a logikai összefonódás miatt egy másik modulba át tudod helyezni ezt a kódot. Ettől még a fájljaid átlagos hossza nem fog megsokszorozódni, mert a teljes kódbázisod is, legfeljebb fele akkora lesz, mint a Java-s kódbázis.

"Milyen mód van arra, hogy ha van egy metódusom, abban egy halom adattag és és megvalósít valamilyen működést, majd kitalálom/kitalálják, hogy kellene még egy plusz működés. Hogy érem el a metódus privát adattagjait? "

OOP szemléletben sehogy, mivel ott egységbezárás van, tehát nem érsz el privát adattagokat kívülről... De, egyébként pontosan ugyanúgy át kell írnod a kódod, mint Java esetén. És pontosan ugyanannyi helyen. Egy kivétel van: amikor az adattagok listája nem változik. De tudsz nekem olyan példát mondani, ahol egy korábban egyetlen műveletből álló dolgot akarsz később egy komplex egységgé átalakítani úgy, hogy ez jó ötlet, és a kódod is átláthatóbbá válik tőle? Mert én nem. Metódust még a Java szemlélete alapján is atomikusan kell megírni, tehát annak a működősét, amit már egyszer ügyesen részekre bontottál, szinte soha nem jó ötlet újabb működéssel kiegészíteni. Ha mégis ilyet akarnál csinálni, akkor pedig egyszűrűen átalakítod a modulod egy osztállyá: a fájl elejére írsz egy sort, csinálsz egy konstruktort, és ahol kell, ott példányosítod. Ebben az esetben is csak ugyanannyi sort kellett hozzáírnod a programodhoz, mint ha pl. Java esetén a paraméterlistán változtatnál.

"Miért jobb ha egy nyelv inhomogén - osztályok és funkciók és minden, mint ha homogén? Csak osztályok (és egyetlen függény a main)? "

Jó ha egy nyelv minimalista. De nem a kódbázisod megduplázásának árán. Azonban, ha pl. a Python nyelv mélyére nézel, akkor meglátod, hogy sokkal homogénebb. A Python-ban minden objektum. És minden objektum átalakítható egy függvény által egy tetszőleges másik objektummá. A class például Python-ban nem egy nagyon erős nyelvi fogalom, csupán egy lehetséges leírási módszer. Valójában úgy működik, hogy elkészít egy funktor objektumot, ami futtatás esetén példányosít. A példányosítás során pedig egy másik objektum jön létre, mely alapértelmezetten üres, a konstruktorod töltheti meg tartalommal. Gyakorlatilag tehát csak egy hash tábla jön létre. Ez, egy sokkal homogénebb megvalósítás. A class statement csupán egy leegyszerűsített mód ennek leírására, mert egyébként "kézzel" is össze lehet állítani egy olyan objektumot, ami osztályként működik.

"A metódus az nem olyan valami, ami elindul, csinál valamit és leáll, kipucolja magát a memóriából. Hol tárolod az adatokat? Globális/lokális tömbökben? Meghatározod, hogy adott metódus csak adott tömbhöz férjen hozzá? Akkor miben más a metódus, mint az osztály?"

Semmiben. Object-first nyelvekben, a függvények gyakorlatilag singleton objektumok. Mivel minden referencia szerint van átadva, egy függvény nincs mit kipucoljon. Csakis a lokálisan létrehozott változókat. Ha olyat akarsz csinálni, aminek vannak egyéb adatai akkor több lehetőség van:

1) Eleve rossz a terved, mert az adatokat valahol máshol kellett volna megadni

2) Statikus értékeid vannak: ekkor referencia szerint használhatod a modul adattagjait

3) Ténylegesen parametrikus: ez esetben az egyik lehetőség, hogy OOP szemléletben gondolkozol. De bármilyen módon is gondolkozol egy biztos: még nem atomikusak a függvényeid, tehát fel kell őket bontani. Ha OOP szemléletben dolgozol, akkor egyértelmű, hogy példányosítható osztályod lesz. De alternatívaként felmerül az is, hogy egyszerűen procedurális szemléletben dolgozol. Ez lényegében úgy fog kinézni, hogy lesz néhány nagy függvényed, ahol ugyanazokat a paramétereket adod meg, mint amit a példányosításkor használsz. Tehát a különbség annyi lesz, hogy a paramétereket minden függvénynek külön-külön kell megadni, nem pedig példányosításkor. Ennek egy hátránya van: a függvényeid paraméterlistája hosszabb lesz. Egy előnye pedig: nem minden metódushoz van szükség minden adattagra, így, osztály nélkül a függvényeid számára kevesebb memóriára és processzoridőre lehet szüksége, mivel nem kell feleslegesen átadnod paramétereket. Ez pedig azt sugallja, hogy osztályt csakis úgy érdemes tervezni, hogy annak az összes metódusa értelmezhetetlen legyen anélkül, hogy ismert az összes adattag. Ha van egy olyan metódusod, amelynek az osztályon kívül is van értelme, akár csupán egy vagy két adattaggal, nem pedig az összessel, akkor az nem metódus, hanem valójában egy függvény. És egy igazi tapasztalt Java fejlesztő első dolga lenne az hogy ezeket a metódusokat egy másik osztályba refaktorálja.