Weblabor

Erre tudsz hozni egy példát?



Ezt nem értem, a strukturált programozás éppen ezeknek a használatáról szól, mitől lesz a kódod csak félig strukturált?



Meg asszociatív tömböket, meg erőforrásokat, meg nullt. Ezekben semmi speciális nincs, ezek adattípusok. Épp csak a PHP fejlesztői ezeket implementálták a nyelv részeként. Nem értem, hogy ha szükségét érzed, hogy ne csak sztringet használj, hanem dedikált típusokat, akkor miért csak a beépítetteket érzed hasznosnak.



A szoftver legalább olyan komplex, amilyen komplexek a követelményei.



Senki sem vonja kétségbe, hogy lehetséges, csak azt, hogy ez a leghatékonyabb módja. De én még csak nem is erről beszélek, én továbbra is azt akarom elhitetni veled, hogy az OOP és a procedurális programozás nem két egymással ellentétes paradigma, hanem előbbi az utóbbi egy bizonyos felhasználási mintája.

Nagyon jó példa. Azért vannak gombok a gépen, hogy ne kábelek összeérintésével kezeld, mert egyrészt kényelmetlen derékig bebújni a dobozba, másrészt nincs elég kezed mindet tartani, harmadrészt bármikor kihagyhatsz egy lépést, és akkor leég az egész.

Ha kell egy új funkció, akkor tegyél ki egy gombot. Ha időközben rájössz, hogy máshogy akarod megvalósítani, a gomb marad, csak átdrótozod.

Az információ maga absztrakt, a valóságban nem létezik ilyesmi. Innentől kezdve miről beszélünk?

De, a feladatmeghatározásom tök pontos volt. Arra akartam rávilágítani, hogy az add() meghívása mindig össze fogja adni a két számot és csak akkor tudod szorzássá alakítani, ha a hívó helyén megváltoztatod a függvényhívást mul()-ra. De akkor a hívó már csak szorozni fog tudni. OOP-nél ezzel szemben egy interface-en függ a kódod, és hívó oldali változtatás nélkül tudsz bármilyen műveletet végezni attól függően, hogy milyen objektumot kap paraméterként. Itt van a példa. Nyilván senki nem csinál ilyet, még mielőtt jönnél, hogy hülyeség ennyire overengineerelni egy tök egyszerű aritmetikai műveletet, ez csak egy példa ;) Gondolj arra, hogy ez egy adatfelolvasás, és XML, CSV, SQL a források.


Na ilyen az a kód, amivel én nem akarok találkozni munkám során :) Ha egy recordset felolvasását, feldolgozását, és kiíratását végzi egy metódus (amit ugye nem csinál, de tegyük fel, hogy igen), akkor abban a metódusban 3 metódushívást akarok látni: fetch, process, write. Hogy ezek belül mit csinálnak, nem érdekel, mert nem azon az absztrakciós szinten vagyok, ahol ezzel akarok foglalkozni. Ha 500 sor, ciklusok, változókkal mókolások stb... Az áttekinthetetlen, és olvashatatlan. Ami nem fér ki kb egy képernyőre, az már egy jelzés, hogy ki kéne emelni dolgokat külön metódusba. Ez persze nem egy beégetett szabály, de általában jól jelzi, hogy túl sokminden került a metódusba.

És hogy nem elméletnek programozol... Az elméletedről szól az egész vita szemben a többiek gyakorlati alkalmazási tapasztalatával :)


Ismerjük szerintem mind a procedurális programozást, azzal kezdtünk. Majd azt választottuk, hogy OOP-ben programozunk, mert a gyakorlati tapasztalatunk szerint ez kifizetődőbb. Nekem továbbra is az az érzésem, hogy nem érted miről szól az egész, és mumusnak tekinted. Ami a te bajod, csak ha sok helyen leírod, hogy az OOP szar és túlbonyolítás, ráadásul mindezt elég nagy hangerővel és meggyőződéssel, akkor könnyen lehet, hogy lesznek, akik elhiszik. Főleg, mivel elsőre sokan nehézkesnek találják. És mondjuk egy Pascalról Javara váltás (ami egy tipikus lépés az oktatásban) valóban nem zökkenőmentes. Bevallom, elsőre én is baromságnak és túlbonyolításnak éreztem az egészet. Főleg assembly után tűnt istenkáromlásnak. De miután tudtam hová tenni, és lett belőle valódi gyakorlati tapasztalatom, már egész mást gondolok róla. Azt ajánlom, hogy olvass el pár könyvet a témában. Valami jó OOP alapozó, aztán Design patterns, végül Clean code. Ha a végére sem változik meg a véleményed, akkor ez van :)

Már hogy ne lenne rá bizonyíték. Az oop kód olvashatóbb, mint a struktúrált, könnyebben kereshetőek és cserélhetőek benne a komponensek. A névterek, az osztály és metódusnevek a kód kereshetőségét segítik elő. Struktúráltan ugyanezt csak kilométer hosszú függvény nevekkel lehet elérni, ami meg távol áll a könnyen emészthetőtől. Nyilván ha nem vagy tisztában azzal, hogy mennyire fontos egy-egy kód karbantarthatósága, akkor 500 soros függvényeket írsz, utána meg ha valamit módosítanod kell, akkor végignézed mind az 500 sort mire megtalálod. Ha szétbontod az 500 sorodat 5 osztályra, osztályonként 5-10 metódusra, akkor megnézed az 5 osztály nevet, kiválasztod, hogy melyikben van, amit keresel, utána megnézed az 5 metódus nevet, kiválasztod azt a metódust, amiben az adott dolog van, aztán végignézed a metódus kódját, ami 10 sor, és máris megvan, hogy hol kell belenyúlnod a kódba. Szóval csak ebben a példában 25x gyorsabb a kód kereshetősége, és akkor csak egy 500 soros kis valamiről beszélünk... Struktúráltan is lehet finomszemcsés kódot írni, de mivel abban nincs megtámogatva a dolog, ezért maximum annyit tudsz tenni a kereshetőség érdekében, hogy szétosztod fájlok között a függvényeidet.