btw, u medjuvremenu sam "shvatio" prednosti sablona u programskom jeziku ;p. i dalje mislim da nisu nesto "revuliconarno", ali je stvarno fina opcija za imati u vasem omiljenom programskom jeziku (nijedan moj omiljeni prog. jezik je nema ;(
no,
Citat:
Dragi Tata:
Druga stvar koja mi često pada u oči je idealizovanje OOP-a. Ljudi zaboravljaju da OOP nije samo sebi cilj, već služi da olakša organizaciju koda i upravljanje projektom. Zbog takvog "OO idolopoklonstva" često izbegavam da koristim funkcije koje nisu članice klase, mada to ume da vodi boljem i čitljivijem kodu (pogledajte
http://www.cuj.com/articles/2000/0002/0002c/0002c.htm ) - jednostavno se bojim da neki "OO fanatik" ne drekne "ovo nije objektno orijentisani kod". OOP treba koristiti tamo gde ima smisla i u meri u kojoj ima smisla, ali ne treba mu staviti krunu na glavu, ili još gore izgubiti posao zbog njega.
mada se mogu generalno sloziti sa tobom, ovaj clanak mene ne bi mogao da ubedi u isto (da se vec ne slazem sa tobom).
prvo "formalno definise" da je jedna tehnika implementacije nekog problema "enkapsuliranija" od druge (fali mi prevod), ako njeno menjanje kvari manje funkcija, a zatim izvlaci zakljucak da je klasa vise enkapsulirana od druge, ako ima manje metoda.
zatim daje primer koji bash kosi njegovu prethodnu definiciju. metoda koja ne mora da pristupa privatnim delovima klase (znaci ne mora biti friend ili member) se nece pokvariti ako se promene privatni delovi klase, sto znaci da njeno prisustvo/neprisustvo u klasi ne menja njenu "enkapsulaciju"..
ovo ponistava razlog na kome bazira ostatak svog clanka, pa samim tim ceo clanak pada u vodu (dobro, skoro ceo. onaj deo oko podele utility funkcija u posebne .h fajlove za spavanje, jedenje i disanje je i dalje validan...)
mozda ja nesto nisam dobro shvatio (posto nisam native-cpp-speaker ;), ali ne bi me ubedio onom pricom...