BGAFC Vendégkönyv

Σ: 1 post

saxus (statz)

#9, Agyfasz (419)

4298 | #1c2d | ^ | Idézet | Sat, 28 Apr 2012 01:17:32 +02

84.3.*.*

*.catv.pool.telekom.hu

TCH írta/wrote:
pl. létrehoz mondjuk egy threadet, az betölt egy osztályt, az osztály allokál egy nagyobb porció memóriát, aztán a referenciát tárolja a szálban, a szál meg törli a referenciát, a GC meg mehet kecskét baszni.

TCH írta/wrote:
hogy a faszul megírt felszabadítás C-ben is memleakhoz vezet.

Nem egy faszul megírt felszabadítás konkrétan összeomláshoz vezet ;)

TCH írta/wrote:
a legegyszerűbb feladatra is osztályba szervez mindent a sok balfasz és akkor a kiterjesztés kiterjesztésének a kiterjesztését kiterjesztjük, azért, hogy kirakjunk három kibaszott input fieldet a kibaszott képernyőre

Ez kb. pont azért szar példa, mert a keretrendszerünkben nem véletlen tértünk át a "switch-way" megoldásról egy OOP szemléletűbb megoldásra: egyrészt rugalmasan lehetett bővíteni a mezőtípusokat, generátorokat, másrészt a kimeneti formátum is transzparensen bővíthető lett (HTML, szerkeszthető, CSV, Excel, PDF, stb.) Validálás meg nem úgy nézett ki, hogy az adott modulba írtam csilliónyi validálási függvényt, hanem az előre megírt validátorokat dobáltam hozzá. Lassabb volt, mint a hardcoded régi út? Igen. Elbírta a gép? Igen. Töredék idő alatt megoldottunk nagyobb funkcionalitást? Igen.

Persze, egyszerű oldalra nem ezt fogom használni.

TCH írta/wrote:
de egy kernelbe (te említetted), minek OOP?

Érdemes elolvasni az MS Research féle Singularity-ról szóló papereket. Egyébként lenne sok helyen értelme, pl. mindenhol ahol egy interface-t kell definiálnod: nem csillió függvénypointert adsz át, hanem egy osztályt. Vagy bárhol, ahol cserélgethetőnek kell lennie valaminek. Pl. schedulerek.

Ezen kívül egy normálisan megírt osztály egyszerűbben egységtesztelhető (lenne, ha pl. ilyenre adnának a Linuxnál ;), és nincs minden globális változóként belehányva a nagyvilágba.

De mondok egy másik példát: most fejlesztek az ügyviteli rendszerünk mellé néhány kiegészítő dolgot. Áll egy szerver és egy kliens részből. Egy fontos tulajdonsága, hogy van egy szabályrendszer benne (amolyan nagyon leegyszerűsített scriptnyelv féleség, csak nem megírt kóddal, hanem összekattintgatós felülettel, ciklusok és hasonlók nélkül. Lényegében csak képlet, változók, és IF-THEN,IF-THEN-ELSE ami van benne, szándékosan egyszerűsítve). A képletekben vannak függvények. Egyes függvényeknek más a működése szerver és kliens oldalon. Pl. szerver oldalon csak simán lekérded az ügyviteli rendszerből az árfolyamot. Kliens oldalon meg ehhez el kell nyúlni a szerver oldalra.

Persze, lehetett volna switch-case-al is kiválasztani, csak épp az úgy egy hányás, ráadásul bizonyos dolgok (pl. az ügyviteli rendszer DB-je) szimplán elérhetetlen a kliensből. Itt van az, hogy a GetArfolyamFunction() vár egy IArfolyamProvider interface-t, amelynek van egy GetArfolyam(string) metódusa, amely visszaadja nekem az árfolyamot. Amikor létrehozom a függvényt, akkor ugye a megfelelő árfolyamlekérő megoldást adom át neki.

Persze, lehetne ezt függvénypointerekkel is megoldani (elméletben), gyakorlatban meg elég undorító katyvasz lenne a vége. Ugyanis kliensoldalon az ottani ArfolyamProvidernek kell egy IClientHandler, amely segítségével tudok üzenetet küldeni a szervernek (valójában a NetworkModule -t kapja meg), szerver oldalon meg attól függően, hogy a konfig állományba mit adok meg, kaphat FakeArfolyamProvider-t (szimpla fejlesztéshez használt konstans érték) vagy másikat (amelyik ténylegesen kiolvassa az adatbázisból - nyilván ehhez át kell adni a megfelelő db-t. Megjegyzem, többhöz is kapcsolódik a szerver -) vagy akár egy teljesen másik megoldást. (Pl. élő árfolyam lekérdezés netről).

Tipikusan ezek az esetek, amikor jó az OOP, még ha elsőre több is a kód, mint sima struktúrált kódnál. Nem azért, mert gyorsabb lesz, hanem mert rugalmasabb.

TCH írta/wrote:
http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/

Na a funkcprog után ne szóljál be az OOP-re ;) Ha valaminek _tényleg_ nincs köze a CPU belső lelkivilágához, az a funkcionális programozás, ahol már tényleg inkább azt írod, hogy mit akarsz végeredménynek, mintsem, hogy mit csináljon a CPU.