Weblabor

A vulgáris beszéd tünet.

hogy én hogyan találkoztam először (és másodszor) az OOP-vel :D - az KATASZTRÓFA volt, csupa nagybetűvel. Akik nem tudják, tanítják egyértelmű esete forgott fenn, a net pedig még gyerekcipőben járt...

Elgondolkodtam azon, hogy ez a gondolatod
miért keletkezett és rájöttem, hogy nagy hibát követtem el a szerkezet felépítésekor. Az elmélet tökéletesnek tűnt, a gyakorlatban viszont megbukott. Gondolok itt arra, hogy azt a részt, amit először is és most is elemeztél, azt én totál lesöpörtem a színről és nem tartom lényegesnek, egy lábtörlőnek gondoltam a bejárati ajtó előtt. Ehhez képest már nem te vagy az első, akinek ott akadt meg a figyelme. A miértre pedig ez a mondatod adja meg a választ...

- nem akartam egy az egyben rányalni a kódot a body-ra :)

Ugyan nem vagyok híve az ilyen összefeszüléseknek (ez az az uccca, amibe nem akartam...), de elfogultnak találom néhány mondatod – az OOP kárára –, így mégis írok még néhány gondolatot a közösbe. Azt nem gondolom, hogy az objektumorientált programozás rászorulna a védelmemre és azt sem, hogy rábírlak egy (legalább enyhe) paradigmaváltásra.

1.
Egy tervezési hibás implementációval nem érdemes véres-kardozni, mert senki nem fogja komolyan venni és az OOP bűnének betudni a dolgot.
A részére meg azt kell válaszolnom, hogy ebbe a tutorba ez tematikailag (OOP ‹alapok›) nem fér bele.

2.
A tervezés szakasza kiemelten fontos a fejlesztésben. Ekkor dönti el az ember (vagy csapat), hogy melyik eszközt és milyen módon érdemes használni a megvalósításhoz. Amennyiben egy OOP nyelvre (is) esett a választás, még mindig csak egy töredékén vagyunk túl a tervezésnek, most jön a design része, ahol sok szempont alapján kell dönteni és rizikófaktor mindig van.
Az öröklődés kontra kompozíció témaköre mostanában ismét üstökösként szántja a fejlesztés egét, de ha belegondolunk, csak egy logikus és igen egyszerű kérdést kell megválaszolnunk: milyen változásokra számíthatunk a közeljövőben, illetve számolhatunk-e a példányok közötti állandó kapcsolatra a teljes életciklus alatt, vagy nem.
A protected hozzáférésnek egy kompozíción belül a dolog természeténél fogva nem sok értelme van :D

3.
Neten (front-end), bytecode-ra fordulás nélküli OOP fejlesztésről inkább ne beszéljünk. Ez az a klasszikus helyzet, ahová NEM VALÓ az OOP. Ha csak „csuklott”, akkor még elég jók voltatok :)

4.
Kis tervezési hiba ismét? :)
Próbálom elképzelni a helyzetet, amikor ilyesmibe keveredik az ember, de nem sikerül.
A világ minden kincséért nem törölném (no jó, a világ kincse túlzás :D), de te egy kicsit félreértelmezted és a saját céljaidra használtad fel a mondatomat... Az objektumorientált programozás nem egy szélmalomharc – miközben megrendelők, feljebbvalók, törtetők szívják a véredet – hanem egy stabil és megbízható eszköz, kihívásokkal teli lehetőségekkel.

5.
Sosem szempont a cég és a fejlesztők szemszögéből, hogy egy esetleges newbie hogyan fogja venni az akadályt. Ez legyen az ő problémája.
Az dolog megint csak szúrja egy kissé a szememet, ilyen helyzetnek nem szabad előállnia, mivel veszélyforrás. Ide BlaZe válaszát szívesen beemelném még, indoklásának pontossága miatt. A "separation of concerns" ugyan nem, de az egységbezárás, absztrakció és típustól függő szoros/laza csatolás tipikusan OOP jellemzők, amik valószínüsíthetően a „józan ész” jegyében vettek alakot a tervezés kohójában ;)

6.
Idézném magamat, de a pdf-ből: „Ez az írás csak egy kezdőcsomag a legszükségesebb tudnivalókkalƒˆˆ” – szóval aszondod "round two"? :)
Ezt az IDE-vel szembeni ellenérzésedet én sem vágom, bár engem még úgy tanítottak, hogy az a jó programozó, aki papíron egy szál ceruzával... azt gondolom ezek az hősidők már a múlt árnyai :)


Más problémák jelentkeznek (nem sorolom, sokszor rágott csont immár). Az öröklődés miatti a flexibilitás elvesztésén és a kompozíció-témán sem érdemes tovább lovagolni – bár látom kedvenc citálandók lettek :) –, mert általában „simaliba” és ritkán kerülsz miatta egy két másodpercesnél hosszabb dilemmába. Pár év intenzív elmélettel megtámasztott gyakorlat után már ösztönösen nyúlsz a megfelelő megoldáshoz anélkül, hogy szétolvasnád előtte a netet, vagy egy kicsit is problémás lenne egy szélsőségektől mentes project megtervezése. Ellenben! – amit a tervezésen (vámon) elvesztettél, sokszorosan nyered a réven: kódolás minőségén, a megvalósítás gyorsaságán (kód újrafelhasználás), a változtatások könnyed bevezethetőségén, az egymásról logikailag elkülönülő kódrészeken (spórolás a hajtépő "mitírtamfelül" pillanatokkal) és ez csak amennyi egyszuszra eszembe jutott. Az olyanok mint a „húsz darabra kell tépnem egy algoritmust de még így is befigyel egy kis redundancia” típusú maszírozások – idézet az idézetből: – egyszerűen fel sem merülnek, és a feladatmegoldásra tudsz koncentrálni. ;)

- ez a patthelyzetgyanús közel-öklözésünk a oop-procedurális-einstein-fogalom felbukkanásakor alakult ki. Azért patt, mert bemondásra elég nehéz elfogadnom, hogy egy procedurálisan megvalósított nagyobb lélegzetű projekt felülteljesítené egy ilyenfajta megmérettetésben (bekapcsolódás újoncként) az objektumorientáltat – pláne egy kialakult, (szintén) tapasztalaton alapuló véleménnyel a háttérben. A kód hossza önmagában semmiképp nem minősiti a paradigmát ami mentén el lehetne dönteni, melyik az áttekinthetőbb és könnyebben emészthetőbb.

...és most, ha senki nem sérült, tisztelgés és hátra arc :)
(jólesett egy kis birkózás)