Régi tanok vs. új módszerek - hogy is van ez?

A patterneket es dogmakat teljesen felesleges eroltetni. Aki azzal jon hogy globalis valtozo vagy goto az evil, arrol azonnal lehet tudni hogy az orranal sem lat tovabb es csak a bemagolt dolgokat szajkozza vissza. Szerintem egyetlen dologra figyelj: a jozan paraszti eszedre, azzal sokkal tobbre mesz, mint 300 kotet pattern konyvvel.

Jok a regi tanok, mert ugy lehet karbantarthato kodot irni.

DE:
A getter/setter method jellemzoen olyan nyelvekben van (mint pl. Java, Javascript), ahol nem lehet field accessorokat definialni (pl. C#ban, Pythonban lehet).

A Value Object ugy hangzik, mint ami egy vanilla C-s struct akar lenni, csak nincs ilyen a nyelvben.

Multiparadigm nyelvben ne akarj mindenaron OOP-s kodot irni. Tudd, hogy melyik eszkozt mikor erdemes hasznalni. Olyan programot kell irni, ami elegge altalanos, hogy bovitheto legyen; de elegge konkret ahhoz, hogy konnyen megoldja a feladatot.

Erdekes kerdes. A valasz az, hogy nincs valasz, azaz nincs altalanos szabaly.

- a programozok is divatoznak. Evente valtozik, hogy mi a Szent Gral (XML, dependency injection, Rails-like frameworkok, J2EE, funkcionalis nyelvek, actor modellek, platformfuggetlenseg -- nehany pelda arra, amivel az adott idoben tele volt az internet, es tobben allitottak, hogy mindenre hasznalhato).
- a konvencioknak van ertelme, megpedig az, hogy egyszerubben megertik a kodod. Peldaul C++-ban irtozatosan feszes, kifejezo kodot lehet irni, ha aladucoltad a megfelelo infrastrukturaval (a template rendszerrel lenyegeben ugy csavarod a nyelvet, ahogy nem szegyelled). Viszont egy template-magiat egyszeruen lehetetlen normalis ido alatt visszafejteni (aki olvasott mar Alexandrescu-konyvet, az tudja, hogy nehany oldalnyi kodon orakat lehet merengeni, ami egyreszt elvezetes, masreszt uzleti kornyezetben eleg ritkan indokolt, hogy pl. valaki forditasi idoben rendezzen tipuslistakat). Ezert ha el akarsz terni a konvencioktol, akkor arra hozz igen jo indokokat (az, hogy neked jobban tetszik, az keves).
- a patternek vak alkalmazasanak az a vege, hogy marha jo interjukerdeseket fogsz tudni feltenni, ellenben sose leszel kesz :). Pl. ha epp visitor patternre lesz szukseged, akkor megcsinalhatod 'butan' (klasszikus visitor pattern) vagy 'szepen' (aciklikus visitor). Ha az utobbit nem tudod fejbol, viszont total biztos vagy benne, hogy csak harom kulonbozo vizitalando tipusod van es lesz, akkor felesleges azert egy orat uldogelni az objectmentor.com elott, hogy ne legyen cirkularis referencia a kododban (amit egyebkent ot perc alatt megirsz).
- elvaras, hogy egy programozo ismerje a patterneket es a technologiakat, de valojaban senki nem ismeri jol az osszeset (meg a fontosakat sem). Ezert minel jobban ragaszkodsz az alapveto dolgokhoz (elsosorban a nyelv alap frameworkjehez), annal egyszerubben atadhatod valakinek a kodod.
- Ne felj a sajat megoldasoktol, akkor sem, ha mar valaki ezt megcsinalta. Ugyebar van olyan antipattern, hogy 'not invented here', ami epp arra hivja fel a figyelmet, hogy elvezetbol/arroganciabol ne talald fel allandoan a kereket, ne irj ujra valamit, amit mar nalad okosabbak ezerszer megcsinaltak. Peldaul ne irj quicksortot Javaban, mert ugysem lesz jobb, mint a beepitett algoritmusok. Ez maximalisan igy van, azonban ha joval tobb ido lenne megtanulni a 3rd party megoldas hasznalatat, mint irni egy ujat, akkor esetleg celszeru csinalni egyet. Pelda: adatsorokat szeretnel rajzolni .Netben a kepernyore. Erre van ezer es egy 3rd party library, viszont nagyreszuk bonyolult, nehezkes, agyonkonfiguralhato es bugos. Ha te pontosan tudod, hogy mi az az use case, amit le szeretnel fedni, raadasul ebbol maga a vonalrajzolas egy minimalis feladat, es a problema nagyobbik resze az adatok megfelelo rendezese, szurese, satobbi (ami altalaban jellemzo pl. a realtime vizualizaciora), akkor siman lehet, hogy megeri irnod egy sajat grafikon-osztalyt, aminek az interfesze kenyelmesen illeszkedik ahhoz az adatforrashoz, ami neked rendelkezesre all.
- utolsokent: a vilag nem tokeletes, es nem programozok alkottak. Ergo siman lehet, hogy egy szingleton pontosan kifejezi azt, amit te le szeretnel programozni, mert a mogotte allo uzleti logika pontosan ennek felel meg. Persze az X konyv tiltja, ezert te inkabb nem hasznalod, szigoruan ragaszkodsz az OOP megkozeliteshez -- ennek az lesz a vege, hogy ugyanugy csinalsz egy szingletont, csak epp elrejted egy rakas OOP-katyvasz moge, es ha valaki leul a kod ele, akkor nem lesz trivialis, hogy egy szingletonrol van szo. Pl. javaban miert kell a main() fuggvenyt egy osztalyon belulre irni? Semmi valodi ertelme nincs.

----------------------
while (!sleep) sheep++;

Latom itt sokan beleestek az OOP vs SP kerdeskorbe.

Amit fontos tudni, hogy a jelenleg hasznalt OOP, szemben az idealisztikus Alan Kay-fele OOP-tol nem utodja a strukturalt programozasnak, hanem resze.

Igy fordulhat elo az, hogy igenis vannak olyan interfeszeink, amik tisztan adattagokbol, masok tisztan muveleti tagokbol allnak.

Azt gondolom, A Dahl-Dijskta-Hoare fele Strukturalt Programozas c. konyv (ami egyfelol a vallasi haboruk alapjait kepezte evtizedeken keresztul, masfelol a harmadik resz masodik feleben bevezeti az osztaly fogalmat, tulajdonkeppen a ma ismert es hasznalt formaban) eleg jol lefedi ezt.

Nem mendemondakat kell ismerni, meg mendemondakat ismero forumtarsakat kerdezni, hanem elolvasni azokat a forrasokat, amik miatt az egesz kiepul, aztan gondolkozni.

Pl. patternekrol leginkabb Christopher Alexander-t, Peter Gabriel-t es Jim Coplien-t kene olvasni, nem korbekerdezgetni...

A vilag kodjainak tulnyomo tobbsege valamilyen szempontbol hibas, tokeletes kod nincs, nyilvan lehet tulpatternezni, meg lehet alultervezni (az esetek 95%-aban az utobbi jellemzo). Ez van.

A kedves forumtarsak pedig ha nem mendemondakbol ismernek a patterneket meg az OOP-t, lehet hogy tobbet hasznalnak...

sub

Globális változóra tényleg érdemes figyelni és szerintem kerülni is - az ördög sose alszik.

Nem nagy dolog, de épp ez miatt szívtam majd' egy órát, lua nyelven - awesome ablakkezelő, az egyik widget állandóan rossz értéket jelenítette meg, nem értettem, miért.

Nagy nehezen leesett számomra, hogy épp egy "globális változó"-szerű probléma okozta ezt, ui. mint akkor megértettem, lua esetében minden függvényben a nem local-lal bevezetett/elért változó mindig globális. Pl. az alábbi kód lefuttatása után talán meglepő módon, de 10 fog megjelenni (én legalábbis meglepődtem, mikor erre nagy nehezen rájöttem).

function test()
    x=10
end

function test2()
    x=12
    test()
    return x
end

print(test2())

A local szavakat az értékadások elé (az x elé) beírva a "várt" 12 fog az arcunkba ugrani.

Ebből persze egy másik tanulság: nem árt, ha tisztában van az ember a nyelv apróságaival is :)