Mivel tudnek gyorsabban es jobban fizetett helyre kerulni?

"Például ha egy Utánfutú akkor csatlakoztatható Normál kamionhoz, ha a rakomány összsúlya nem haladja meg a 20 tonnát, akkor nincs semmilyen publikus adattagod sem a kamion, sem az utánfutú osztályán. Hanem, az utánfutún van egy canAttachTo(TructType type) metódus, ami ellenőrzi a type-hoz tartozó súlyfeltétel meglétét. A Truck osztályon pedig van egy attach(Trailer trailer) metódus ami a trailer.canAttachTo(this.type) && this.attached_trailer == null feltétellel ellenőrzi, hogy lehet-e csatlakoztatni, és ha nem, akkor Exception-t dob. Tehát, nincs itt sehol semmi publikus adattag (tehát getter-setter sem)."

Ez egy tipikus jellegű példa a getter-setter vitában. Nagyon jó mint példa, de nagyon rossz megoldás. Nem is csak egy baj van vele, hanem több.

"Egy más kérdésnél való hozzászólásom nyomán tőled is megkérdezem. Ha mondjuk emberek életkorával számolsz és különböző értékeik között kell statisztikai célokból különféle származtatott adatokat kiszámolnod, akkor a "személy" entitás/objektum "getAge" (mindegy, hogy property, vagy közvetlenül field, vagy akármi) műveletének eredményeivel való számolás helyett miért egyszerűbb az, ha a "személy" entitásba rakom az összes számítási metódust, meg még a jövőbelieket is? A való életben sem miért így csináljuk?"

Hol írtam én, hogy így kell szervezni a kódot? Szerintem egyáltalán nem is jó teljesen objektum-orientáltan írni egy programot egyébként. Pont ez az egyik fő érv egy olyan nyelv ellen, ami megpróbálja lehetetlenné tenni azt, hogy multiparadigmás programozási szemléletet kövess. Szerintem egy, az adott objektumtól különválasztható működés, algoritmus esetén a legrosszabb ötlet azt egyáltalán bármilyen osztályhoz kötni. Sőt, egyáltalán nem az a cél, hogy adatszerkezetekhez kössük. Épp ellenkezőleg. Ha ez megvalósítható, akkor az adatszerkezet bejárását is célszerű különválasztani az algoritmustól. Pont ezért rossz a Java nyelv szemlélete. Ott ezt kényelmetlen megvalósítani.

Én nem programozok objektum orientáltan, de nem is akarom magam ebbe az illúzióba ringatni - mivel nem is tartom jónak. Ezzel együtt, megszabadulok azoktól a tanult rossz szokásoktól, amelyek ebből az erőltetett Java-s szemléletből erednek. A multi-paradigm programozásban hiszek. Szerintem az sem jó, ha egy program túlzottan lineáris. Minél apróbb, újrahasznosítható részekre érdemes felbontani a kódot.

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

Nem igazán látom be, hogy mondjuk jó pár tucat referenciát miért kellene folyamatosan belepakolnom a verembe úgy, hogy egyébként egy egész hívási fában konstans az értékük. Azt meg végképp nem, hogy miért lenne egyszerű a dolgom programozóként. "

Nem egészen értem, hogy ha nem egy program futásidejű optimalizálása a cél, akkor ezzel miért foglalkozunk? Megjegyezném, ha optimalizálni kellene egy ilyen kódrészletet, akkor szerintem az utolsó ötletem lenne az, hogy bevezessek rá egy extra osztályt. Egyszerűbb azért lenne a dolgod, mert nem lesz egy teljesen felesleges fájlod és osztályod. És, a Python nyelvben például van a functools.partial, amivel függvények paramétereit lehet szűkíteni. Ez a megfelelő osztályokat a háttérben, észrevétlenül elkészíti, és azokból példányosít. Tehát, egy egysoros, általános megoldást ad ugyanerre a problémára ahelyett, hogy egy külön osztályt és külön fájlt kellene létrehozni.

"Egyben el is érkeztünk oda, hogy miért is memória és órajelpazarlóbb ez a megoldás. De filozófiailag is. Ha nekem van harmincmillió (igen, vannak rendszerek, ahol még ennél is több van) sorom, amiről én hiába tudom, hogy mind ugyanolyan szerkezetű, csak az adatok mások bennük, mégis eltárolom a struktúra információt is, akkor igen csak rossz szoftvert írtam ennek kezelésére. "

Nyilvánvalóan vannak olyan esetek, ahol ez valóban egy pazarló megoldás. De ahol ez nem okoz problémát, miért foglalkozzunk vele? Nem érdemes olyan problémára fókuszálni, aminek a megoldása nem jár semmilyen előnnyel. Egyébként, a struktúra információját nyilván nem lesz kötelező ettől még minden esetben letárolni, egyszerűen csak okos megoldást kell választani. Például, ha egy azonos típusú objektumokat tároló adatszerkezetről van szó, akkor ezt elég triviális úgy implementálni, hogy kívülről ne lehessen észrevenni, hogy az implementáció más. Például egy metaclass segítségével.

"A function objectes kritikád az áll. Igen, vannak olyan esetek, amikor bizonyos objektumok függvényként kategorizálhatók. De ettől azok még objektumok. "

Igen, de miért kelljen őket 60 sorban leírni, amikor 10-ben is le lehet? Igen, felfoghatóak a függvények is objektumként, de ettől még nem kell hogy class-eket definiálj hozzá. :) Sőt, a class-ek is felfoghatóak objektumként, sőt, lehetnek metaclassek is, stb. Ettől még nem kell hozzá nyögvenyelős, túlbonyolított kódot használni. Attól, hogy egy függvény felfogható objektumként, még nem kell újra feltalálni a kereket.

"Hol írtam én, hogy így kell szervezni a kódot? Szerintem egyáltalán nem is jó teljesen objektum-orientáltan írni egy programot egyébként."

Itt igazából arról van szó, hogy te valami "vegytiszta", tankönyvi OOP-ről beszélsz, de én az elméleti konstrukciók nem mindegyikét tartom szükséges szereplőnek ahhoz, hogy egy adott helyzetben OOP-ről beszéljek. Pl. a láthatósági opciók, ami az egységbezárás megvalósításának lényegi megvalósítóiként szerepelnek a legtöbb nyelvben - számomra nem esszenciális hozzávalói az OOP-nek. A tankönyvekben szépen felsorolják az OOP N darab ismérvét, de attól, hogy nincs egységbezárás, az még OOP marad, csak egy "hiányos", "nem teljes" OOP. Az már csak annak az eszköze, hogy jó OOP-s programok szülessenek, nem pedig annak záloga, hogy egyáltalán OOP-ről beszélhessünk egy adott esetben. Úgy vagy te a getter-setter problémával is, hogy ha már van getter-setter, akkor az már nem per definitionem OOP, szerintem pedig még bizony lehet az, mert a getter-setter probléma nem az OOP mély lényegét érinti, ráadásul elkerülhetetlen sok esetben (ahogy rámutattál). Ebből én nem azt a következtetést vonom le, hogy az OOP rossz úgy általában, hanem hogy inkább a "getter-setter tiltás" az OOP-re a rossz általában.

"Pont ez az egyik fő érv egy olyan nyelv ellen, ami megpróbálja lehetetlenné tenni azt, hogy multiparadigmás programozási szemléletet kövess."

Egyrészt ez lehet egy fő érv a tucatból, másrészt nem "lehetetlenné tevésről" van szó, hanem "nem támogatásról".

"Szerintem egy, az adott objektumtól különválasztható működés, algoritmus esetén a legrosszabb ötlet azt egyáltalán bármilyen osztályhoz kötni."

Ez így is van. viszont "elegendően komplex" esetekben úgyis definiálnod kell számos adatszerkezetet, ha más nem, legalább implicit módon és a végén legalább olyan komplex kódot kapsz, mintha egy osztályban írtad volna meg.

"Ha ez megvalósítható, akkor az adatszerkezet bejárását is célszerű különválasztani az algoritmustól. Pont ezért rossz a Java nyelv szemlélete. Ott ezt kényelmetlen megvalósítani."

Valóban. De vannak más szempontok is, ld. lent.

"A multi-paradigm programozásban hiszek."

Rendben is van. Nem vagy vele egyedül.

"Minél apróbb, újrahasznosítható részekre érdemes felbontani a kódot."

Ezt kb. mindenki tudja. De hol állsz meg a felaprózásban? Számos esetben nem triviális.

"És, a Python nyelvben például van a functools.partial, amivel függvények paramétereit lehet szűkíteni. Ez a megfelelő osztályokat a háttérben, észrevétlenül elkészíti, és azokból példányosít. Tehát, egy egysoros, általános megoldást ad ugyanerre a problémára ahelyett, hogy egy külön osztályt és külön fájlt kellene létrehozni."

Érthető, amit mondasz, de te valójában nem arról beszélsz, hogy a Java OOP-je rossz, hanem neked hiányzik egy funkció/lehetőség egy nyelvből. A másik oldalról viszont pont az "észrevétlenül elkészíti" az, ami nem mindig jó.

"Tehát, egy egysoros, általános megoldást ad ugyanerre a problémára ahelyett, hogy egy külön osztályt és külön fájlt kellene létrehozni."

Lehet, hogy itt megspóroltál valamit, de elveszítheted máshol. Pl. ott, hogy úgy hoztál létre implicite egy új osztályt, hogy ezzel az implicit definícióval kapcsolatos kód futó kódban van elrejtve. Aztán most képzeld el, hogy egy kóddiagnosztikai szoftverrel értelmes mérőszámot szeretnél. A class-based OOP egyik előnye, hogy a típusaid (osztályaid) nem burjánozhatnak tetszőlegesen, mindig viszonylag könnyen kiderül a kódból, hogy mi a mibenlétük. Igen, vannak szituációk, ahol ez az egész kevéssé áldás.

"Nyilvánvalóan vannak olyan esetek, ahol ez valóban egy pazarló megoldás. De ahol ez nem okoz problémát, miért foglalkozzunk vele? Nem érdemes olyan problémára fókuszálni, aminek a megoldása nem jár semmilyen előnnyel."

Ne honnan tudod, hogy holnapután nem fog problémát okozni? De ezért is írtam, hogy ez filozófiai probléma, nem spórolási: miért tároljam el újra és újra egy homogén szerkezetű sokaság szerkezetét? Mondhatnám úgy is, hogy ahol ez nem okoz problémát, ott miért foglalkozzak azzal, hogy épp class-based módon reprezentálok adatbázis sorokat? Főleg, hogy ebben az esetben tudom is, hogy mindig tök egyforma a szerkezete minden sornak. Nem érdemes arra a problémára fókuszálni, hogy a sorok különböző szerkezetűek legyenek, vagyis hogy object based legyen a reprezentációm. Nem beszélve arról, hogy fejlesztés közben nem túl kényelmes megjegyezni 150 oszlop nevét pontosan, pláne, ha tele van szakszóval és rövidítésekkel, de class-based esetben ez nem is gond, mert az IDE felajánlja nekem azokat listában. Ezt meg csak is class-based esetben tudja tisztességesen megtenni.

"Egyébként, a struktúra információját nyilván nem lesz kötelező ettől még minden esetben letárolni, egyszerűen csak okos megoldást kell választani."

Igen, ebben a speciális esetben a class-based oop az okos megoldás. A metaclassokkal és egyebekkel csak több és macerásabb kódot kapsz, olyan helyzetet létrehozva, amihez hasonlókat az OOP esetén épp bírálás alá vettél.

Egyébként a kritikáid mellé van még egy lényeges szempont, ami rávilágít, hogy miért ott népszerűek a statikus nyelvek és azon belül miért pont a Java, ami még ezek között is viszonlyag egyszerűbb. Ezek pedig a nagy, komplex, akár egy, vagy több évtizeden keresztül, több száz főből álló, sokszorosan cserélődő fejlesztői csoportok által vitt szoftverek. Miért is? Mert igaz, hogy szószátyár a Java, viszont mivel puritán és sok nyelvi trükktől (pl. operator overloading) mentes, ezért jobban skálázható a fejlesztés maga: az újonnan felvettek hamarabb megértik a kódot (a megértésben a kompaktság inkább nehezít, mint segít), könnyebb ide-oda dobálni az embereket a projektekre, a statikusság miatt az IDE rengeteg segítséget tud adni, nem beszélve a statikus kódelemző eszközökről.

A saját ízlésemnek megfelelően kb. két nyelvre mondom, hogy "üti" a többit: statikusban a Scala, dinamikusban a Ruby. De igazán komplex szoftvert Ruby-ban nem állnék neki csinálni, a Scala-val meg az a "baj", hogy ugyan rendkívül elegáns, de egyrészt megtanulni több időbe telik, mint a java-t, másrészt a kevés nyelvi feature fejlesztéskor átok, megértéskor és kódátvételkor áldás.