Mislim da je sledeca faza ubacivanje sto vise tzv. deskriptivnog programiranja ( logicko , a takodje na neki nacin i funkcionalno). Neke stvari koje se u proceduralnom programiranju rade sa dosta linija koda, mogu se opisati sa jednom smislenom linijom logickoj paradigmi. (potraziti QuickSort u Haskellu ili Prologu)

Kao dokaz ovog je recimo novi C# 3.5 koji je dobio lambda izraze,kao nesto tipicno iz sveta funckionalnog programiranja.

Ne verujem da ce OOP nestati ili biti zamenjen, bice samo muljano i doradjivano i dodavano unutar OOP koncepta, kao sto su pomenute lambde, ili recimo AOP (Aspect OP). Ali fundamentalno, nista sto sam ja video do sada ne preti da istera OOP i ucini ga zastarelim.

#mmix

To isto se govorilo i za kompozitno programiranje, tacnije za naredbu go to. Kada je E.Dijkstra napisao clanak o tome kako ta naredba nema buducnost,
tadasnji strucnjaci su ga ismijali govoreci da ce go to trajati jos najmanje 30 godina. To je bilo 1968. a naredba nije izdrzala ni tri godine.

http://portal.acm.org/citation.cfm?doid=362929.362947

Kompozitno programiranje je bilo pogodno za pocetak IT-a kada je nizak hardver omogucavao takav pristup resavanju problema. Usloznjavanjem hardvera stvoreni su preduslovi za razvoj softvera. Kada se broj gresaka u softveru povecao do te mjere da se nisu mogle svesti na tolerantni nivo nesto se moralo mjenjati. Dijkstra je uvidio problem sa naredbom go to, pa je razvijen koncep strukturnog programiranja koji je, kada je dostigao svoj maksimum, zamjenjen(obogacen) objektno orjentisanim.

Ne vjerujem da ce u skoroj buducnosti biti bitnih promjena, ali ovi ciklusi su periodicni(svakih dvadesetak godina), pa sad ce to.

Pominje se aspektno programiranje i vec ima nekoliko implementacija. Kao sto oop nije u potpunosti zamenio sve svoje prethodnike, tako verovatno ni oop nikada nece biti u potpunosti zamenjen svojim naslednicima.

Pa porediti goto naredbu i OOP kao paradigmu je malo deplasirano.

Ako zanemarimo hardcore OOP koncepte, jednostavno receno ono sto OOP izdvaja od ostalih paradigmi je mogucnost modelovanja realnih situacija, procesa i objekata u informacioni model, i to je ono sto je nedostajalo u strukturnom prpogramiranju, znaci ne sam kod (jer kad pogledas OOP se generalno oslanja na druge pardigme za sam kod) vec prisustvo metadata opisa u sorsu. I u tom pogledu nema neke velike potrebe niti mesta za radikalnu promenu i ne vidim sto bi morao da propadne OOP samo zato sto postoji vec par decenija.
Analogije radi, tockovi na vozilima postoje vec milenijumima i sluze svrsi i vrte se i bili su drasticna promena u odnosu na vucenje prikolice bez tockova (ili sa kockastim tockovima ), i radi se na tome da se naprave bolji, efikasniji, laksi, naj, naj tockovi ali niko ne pita sta posle tocka?

Pa ne kazem ja da treba napraviti elipsaste ili trouglaste tockove!!!
Kazem samo da se mogu dodati pomocni tockici u OOP.

Dobro si primjetio da se kod zasniva staroj paradigmi.
Konkretno u C++ je dodan objektno orjentisani dio na C-a i dobijen C++. Nista se nije drasticno izmjenilo u samom C-u, osim vracanja vrednosti funkcija preko liste parametara, sto je ,naravno, poboljsanje.

Sam kocept OOP se zasniva na uporednoj dekompoziciji algoritama i struktura podataka. U definiciji strukturiranog programiranja ne postoje strukture podataka, i sami tvorci strukturiranog programiranja su bili svjesni tog nedostatka, cak je i C.Hoere(jedan od zasnivaca ovog koncepta) definisao osnove OOP.
U strukturiranom programiranju jednostavno nije bilo moguce vrsiti istovremenu dekompoziciju algoritama i struktura podataka. Moralo se birati izmedju jednog ili drugog, pa su obicno posebni timovi (priredjivaci projekta) prije samog pocetka rada na programiranju odredjivali gotovu strukturu podataka koju bi prosljedili programerima koji su na osnovu nje pisali programe, ili djelove programa, zavisno za sta su zaduzeni. Sami programeri nisu mogli da prave svoje strukture podataka jer bi tada dolazilo do nekompatabilnosti, u velikim projektima bi se 99% zadesilo da se naprave dvije razlicite strukture za istu stvar od strane dva programera koji pisu dva odvojena dijela programa.

Ne kazem da OOP nevalja, naprotiv. To je do sada najbolja metodologija razvoja softvera, do koje se doslo dugogodisnjom evolucijom softverskog inzenjeringa.
Mene zanima koji su mu eventualni nedostatci, sta bi se tu moglo doraditi?

Koliko znam, svaka sledeća paradigma je proširivala prethodne, a nije ih zamenjivala u smislu odbacivanja starih koncepata. Verovatno će tako biti i sa OOP.



Znači li ovo da se u strukturnoj paradigmi nisu mogli modelirati realni procesi ili da OOP nema nedostataka ili nešto treće?

Zar ne bi trebali teziti ka hovercraftu?? Nisi gledao Povratak u buducnost?

Hovercraft vec postoji i zove se helikopter, pa opet nije parkiran ispred svake kuce Jeste brzi ali je i neoptimalniji i samim tim nece postati mainstream a isto ti i dalje vazi za nadolazece paradigme. Da nastavimo filozofiranje, nadji mi hovercraft koji ce vrsiti rad u toj meri da se izbori i sa gravitacijom i da mi omoguci kretanje i da to radi za manje od 5.5l ECo dizela na 100km i ja cu se prebaciti Isto vazi i za paradigmu koja ce zameniti OOP



Paradigmi ima desetine za koje sam ja cuo i verovatno jos par puta toliko paradigmi za koje nikad nisam ni cuo (iverovatno nikad ni necu), i nisu sve hirearhijski poredjane i vecina jezika koji su danas mainstream su zapravo implementacije vise paradigmi. OOP je samo jedna od njih i iako smo navikli da na OOP gledamo kao na naslednika strutkuralnog programiranja, on i nije nastao u toj formi (smalltalk nije strukturalni jezik) i uopste nije neophodno da jezik koji je OOP bude i strukturalni.
I da, u strukturnoj paradigmi nisi mogao da predstavis nikakav model, mogao si samo da odradis implementaciju (!=model), i to ne uvek i ne uvek elegantno.

Vidim da se ova tema svela na nabrajanje prevoznih sredstava!? Zasto prave vozove na magnetni pogon i izbacuju im tockove?

Pitanje je koji su nedostatci OOP i ima li ih uopste???

Pa ti si nastavio taj pravac razgovora a i ode u masstransit, pa jel voze ljudi magleve po ulicama?, prave ljudi i spaceshuttle koji leti bez tockova pa i dalje nije mainstream. Propustio si da uocis ono sto sam hteo da ti kazem a to je da je pitanje "koje su mane OOPa i kad ce zastareti?" isto kao i "koje su mane tocka i kad ce zastareti?"

A nedostatci OOP-a. To zavisi koga pitas, posto OOP generalno nema striktnu definicijiu, vise je neki skup slabo povezanih pravila koja se parcijalno ili u potpunosti implementiraju u odredjenim razvojnim sistemima, sto i nije losa stvar jer je fleksibilan i stalno evoluira i zbog toga i nece biti zastareo. OOP koji danas imas nije isti kao OOP koji je nastao u simuli i smalltalku 60'ih, banalno receno jednog dana je neko zakljucio da OOP nije dobar za decoupled sisteme jer obe strane moraju da imaju punu implementaciju klase i kao resenje tog problema dobili smo interfejse, itd, itd. A posto za konkretnu implementaciju koda zavisi od drugih paradigmi OOP je otvoren za bilo koji broj i kombinaciju paradigmi unutar sebe (strukturalno, kompozitno?, funkcijsko, lambda, ...).

Koliko sam do sada video protiv OOPa su se uglavnom bunili "stariji" akademski informaticari koji jos ceznu za fortranom, a razlozi su im uglavnom vezani za odredjene implementacije u specificnim jezicima. Npr, po jednom C++ ne valja jer je komplikovan, a po drugom Java ne valja zato sto oduzima programeru kontrolu nad memorijom, ko da ista od toga ima veze sa OOP-om. Generalno postoje nacini na koje mozes da napravis veoma ozbiljne bugove u OOPu kao cista posledica OOPa bez obzira na implementaciju, npr subclassing uvek povlaci za sobom subtyping sto nije uvek tacno i sa stanovista tipova i sa stanovista modelovanja realne situacije.

Ja se izvinjavam na offtopic-u, ali nisam mogao da odolim - GoTo is not dead. Koliko pre 3-4 dana sam cistio pomenuti iz aplikacije na kojoj radim (a na kojoj je ranije radio neko drugi) :(

OOP nema veze sa struktuiranim programiranjem
koliko je nadogradnja na proceduralno programiranje.

Dakle u pocetku je bio spageti kod pa su onda
od toga napravili struktuirane blokove.

Paralelno sa time od asembler rutina nastaju potprogrami
i na kraju procedure.
E tad se uocilo da algoritmi funkcionisu
nezavisno od tipova podataka sa kojima se radi.
Da bi se to omogucilo uoceno je da pristup
samom podatku ne sme ici neposredno nego
preko grupa f-ja koje enkapsuliraju
detalje o cemu se radi.
I nastao je OOP. Prakticno procedure koje su
uzimale kao kljucni parametar neku strukturu
pridruzili smo podatku.
Drugi deo OOP-a je polimorfizam, tj mogucnost
da se poziva odredjena verzija f-je na osnovu tipa
podatka. Na taj nacin se upotpunjava generalnost
algoritma.
Medjutim tu nastaje problem.
Vezivanje f-ja sa podatkom podrazumeva
da se dispatch radi samo na osnovu jednog parametra.
Drugo ne mozete svu f-onalnost vezati u jednu
strukturu pa tu dolazi do ogranicenja
i koliko je sam algoritam genericki jer
f-onise samo na odredjenoj klasi struktura.

E onda se pojavilo genericko programiranje
kao resenje nedostataka OOP-a.
Recimo bas kod c++-a glavna paradigma i gde
najvise ide razvoj je genericko programiranje
ne oop. STL je komplet baziran na generickom programiranju.
Zasto.
Pa genericko programiranje prakticno nudi isto
sto i oop ali ne zahteva da su f-je vezane
za odredjenu klasu podataka.
Ono sto se zahteva je da podaci imaju odredjenu
f-onalnost ali ne moraju medjusobno biti
ni u kakvoj relaciji.
Dakle ne zahteva se da protokol f-je budu
vezane za sam podatak tj da sve bude izvedeno
iz jedne bazne klase.
Dakle imamo f-ju koja generalizuje algoritam
nezavisno od tipa podatka sa time da se bas kao
i kod OOP-a moze specijalizovati slucaj za odredjene
tipove.
Recimo ocigledni nedostatak oop-a je kod generalizovanja
algoritama za kontejnere.
Sa obzirom da nema smisla smestati sav protokol u baznu
klasu dolazi do potrebe da se programiranje vraca
na proceduralni nivo tako sto bi elemente recimo liste
kastovali u izvedeni tip i onda radili sa onim sta nam
treba.
Genericka lista omogucava da se tacno zna tip koji je
smesten u listu a samim tim i interfejs.
Dakle neki put ima smisla grupisati f-je po jednom
podatku a neki put nema.
Zato volim c++ ;) a mrzim javu ;)
E sad na kraju da bi se resio problem f-ja
koje pripadaju vise klasa koje medjusobno
nemaju nikakvu zavisnost i sprecila redundantnost
koda u OOP-u su nastali paterni kao sto je visitor
i command. Tj tzv "double dispatch" i multiple dispatch.
Te probleme resava aspektno programiranje,
tj ono sto oo programeri sada moraju rucno da rade
kako bi izbegli redundantost sa obzirom da se ne moze
sve strpati u baznu klasu.
A aop ce valjda biti ugradjeno u sam jezik?


Pozdrav!

To je sve ok, samo sto su templates/generics van oop-a prilicno rudimentarni i osnovni i sve sto se sa njima moze uraditi je vec u bibliotekama kao sto je STL (ono vece, manje, jednako, +, -, , itd). I mozes da ignorises OOP dok god genericke funkcije barataju osnovnim tipovima i strukturama i dok ih samo negde slazes i preslazes. Ako hoces da radis neke kompleksnije operacije nad "instancama" tipa koji se salju u specijalizaovani generics onda neces daleko stici bez OOP-a (tj mozes, ali opet sa spageti kodom), da se ne lazemo i sam STL u velikoj meri koristi operatore a kako ces da nalepis operator na strukturu podataka ako ne preko klase (struct i class su bukvlano isto u C++ bar sto se tice OOPa tako da deklarisati nesto sa struct ne znaci izbeci OOP) da ne pominjem npr iteracije nad polimorfnim generickim listama koje se duboko zanivaju na OOPu. Dakle opet je OOP kriticna komponenta, a templates su samo jos jedna paradigma koja se koristi unutar OOP-a.

A inace, STL nije samo kolekcija template funkcija, veci deo STLa je implementiran kroz OOP i poprilicno koristi i subclassing i polimorfizam, ukljucujuci i list<T> koji pominjes:



A template imas i u Javi (mada u malo izmenjenom obliku i zovu se generics, ali funkcionalno rade slicno), ne vidim sto je diskvalifikujes zbog toga. Sem sto pravi programeri programiraju u asemb.., ovaj, C++-u




Nije ni strukturalno programiranje mrtvo

Možeš li ovo da pojasniš.

Slika govori hiljadu reci

[att_img]

Ovaj dijagram je u 1:1 vezi sa OOP strukturom programa sorsom i sasvim je ocigledno sta modeluje. Sama implementacija metoda moze biti strukturalna, kompozitna, funkcionalna, u C#-u, cobolu ili ruby-u, biraj, ali OOP je taj koji definise shemu entitea, procesa i asocijacija sto strukturalno programiranje ne moze samo po sebi.

Miljane nije poenta da li se genericko programiranje moze mesati sa
oo proragmiranjem nego to sto za genericko programiranje
nije neophodan oop.
U c++-u mozes definisati operator f-je
koje nisu pridruzene klasi, no naravno glupo je
sad eliminisati oop u slucajevima kad je on prirodno resenje.
Sto se tice jave dovoljno je da vidim abominaciju kao
sto je public static void main pa da mi se povraca ;)

Pozdrav!


edit: eh sad ulete ova slika.
miljane ne mozes modelovati po oo principu za funkcionalno programiranje
pogotovo ti ne treba get/set jer tu nema nista mutabilno.
U stvari ako pogledas haskell on prirodno podrzava parametrijski
polimorfizam tj genericko programiranje ali ne i oop. Drugo
u f-skom programiranju same f-je su first class sitizeni bas
kao i podaci.

edit2: eh da
struktuirnoa programiranje kao control flow ili struktuirano programiranje
u smislu proceduralno / oo?
Ti u c-u mozes bez problema da programiras kao u nekom OO jeziku
ali je pravi nightmare ;)


_{[Ovu poruku je menjao Branimir Maksimovic dana 12.10.2008. u 22:21 GMT+1]}

Problem sa OOP nastaje kad se posmatra kompleksna hijerarhija izvedenih klasa
nijedna klasa iz hijerarhije ne moze se posmatrati odvojeno tj. ne moze se lako ponovo iskoristiti bez
detaljnog poznavanja ostalih klasa iz hijerarhije i metoda koja ona nasledjuje ili pozajmljuje
tako da je reusability i enkapsulacija funkcionalnosti (sto je ustvari i ideja OOP-a) na nivou jedne klase tj. objekta diskutabilan.
Da li ste nekad koristli visestruko nasledjivanje u C++-u ?
Ne bih ga preporucio ni najgorem neprijatelju :)

Mislio sam na controlflow, a znam da moze C da "imitira" OOP do neke mere, dok sam svojevremeno kopao po implementacijama OOPa u C++ u i Delphi-u pravio sam svoje vTable strukture i popunjavao ih u konstruktoru cisto kao proof of concept

A dijagram je bio za Nedeljka, ne za tebe, al kad si vec odgovorio moram da priznam da se Haskell-om nisam bavio, nisam nesto lud za funkcionalnim jezicima i dovoljno mi je bilo sto sam se petljao sa Ruby-em da se naucim konceptu, kad i ako Haskell postane mainstream potrudicu se da naucim detalje (like that will ever happen ). Al ajde, daj mi primer kako bi modelovao taj dijagram u pure-functional jeziku bez oop-a i kako bi odrzavao two-way asocijaciju kad nemas state i kako bi modelovao asinhrone operacije.




Da, da, razumem te potpuno, ovo dole izgleda mnogo prirodnije i citkije

Pazi u pure f-nalnom jeziku uopste ne mozes da razmisljas
u smislu uml dijagrama ;)

Sve f-je sa sajd efektima i imperativnim kodom morao bi da zavrapujes u monadu
tj prljavi deo koda ;) A kad uletis u monadu to se vuce jedno za drugo kao
lepak pa da bi pozvao te f-je iz neke ciste, moras da zoves unsafePerformIO ;)
Naravno, jedino hibridi kao sto su sml, ocaml i f# (e da tu je i scala) mogu imati uspeha zato sto smo
svi navikli da razmisljamo u smislu varijabli i imperativnog koda ;)
No haskell je pure, ali i prilicno tezak, mislim da je daleko komplikovaniji
od c++-a. Heh pazi tu uopste nemas petlji, tj petlje implementiras preko rekurzije tako sto radis
rekurzivni prolaz kroz listu gde bi vrednost brojaca bili elementi liste ;)
No pazi kad u haskellu mozes da imas prave pointere da pokujes po memoriji
i da formiras c nizove pa i da direktno c tebe zove ili ti direktno da zoves
C bez hakova kao sto je JNI. Mnogo je mocniji od jave.
E da u oop-u sve je objekt u f-ionalnom sve je f-ja ;)

Sto se tice navedene f-je nisam mislio sta je lepse sta nije,
nego bre onemoguciti slobodne f-je pa moras main da stavljas kao static
metodu klase na to sam mislio ;) Mislim ok oop ali brate onemoguciti
free f-je to mi se ne svidja.

Pozdrav!

Paralelno programiranje?

http://msdn.microsoft.com/en-us/magazine/cc872852.aspx

Paralelno programiranje je ql, ali ima jos da se nacekamo za to bar sto se MSa i .NET/VC-a tice, mada C#4/VS2010 je tu iza coska
Iskreno ne znam dal ce to uopste biti zasebna paradigma (onda bi morali da kazemo i da su LINQ, WPF, MFC, itd paradigme). Efektivno ti vec sada mozes da radis paralelno programiranje samo uz malo vise koda, morao bi sam rucno da odradis parcijalizaciju podataka i iniciranje posebnih threadova koji ce da obradjuju parcijalni set. Vec sada ima nekih implementacija PP-a mada nisam isprobavao jer mi je sve to zigledalo previse experimentalno za instaliranje na devbox, pa ne mogu da pricam.

Ono ste ce "zvanicno" paralelno programiranje doneti u C#4 je cisto supported biblioteka tog koda uz neke izmene lambda sistema jezika da se dalje pojednostave paralelni izrazi (bar u slucaju C#-a). Generalno odlicna ideja ako mene pitas, ali daleko od paradigme (da ne pominjem da sve to i dalje radi pod OOPom ). Mene najvise samo brine sto ce buduci bagovi biti monstruozni, jedino sto nas je do sada spasavalo od sampiona u multithreadingu je to sto multithreading nije bio jednostavan pa sampioni cesto nisu mogli ni da pokrenu thread, sa PP podrskom i mogucnoscu da raspale milion threadova jednim izrazom, sampioni ce dobiti novu dimenziju postojanja.

OK, UML dijagrami. Znam ja sta ti hoces da kazes, ali moze se to gledati i sa druge strane. Opisao si strukture podataka, interfejse i veze izmedju struktura, a da nisi napisao ni liniju koda. Ja ipak mislim da se sve to moze prestaviti kroz kod, ali ces ti reci da to nije to, jer ukljucuje implementaciju, a iz UML-a je mozes ispaljivati Java, C++, C# kod itd.

Ja prednosti OOP-a sagledavam drugacije: Nasledjivanje olaksava ponovnu upotrebu koda, enkapsulacija olaksava trazenje gresaka (jer znamo gde u programu neka promenljiva moze biti menjana), polimorfizam ne treba ni komentarisati itd.

E sad da ti otkrijem istinu, nisam nacrtao ovaj dijagram, napisao sam C# kod i pustio VS da mi izgenerise class diagram (i malo ga doradio da se asocijacije vide direktno), dok sam sors nema nikakve implementacione detalje i sastoji se cisto od sheme. Sta vise sors (okacen kao att da ne pravim guzvu) mi zapravo otkriva jos neke non-UML implementacione detalje koje dijragram nema (npr da je Rad() virtuelni metod, a da OdradiPosao() nije). Svako ko se bavi OOP-om u bilo kom programskom jeziku (doduse imperativnom) razumece sta sors modeluje i sta vise znace kako da ga adaptira za svoj OOP jezik. Kad bi sve operacije odavde odradio zaobisavsi OOP u potpunosti, veoma bi bilo diskutabilno sta bi od ovog modela bilo jasno i nedvosmisleno.



Ok, prodao si mi ideju, kupljen sam. Ajd sad sa mnom kod mog klijenta bankara (inteligentan cova ali nije programer) i da mu objasnis da je taj funkcionalni blob hijeroglifa koje se rekurzivno lepe jedan za drugog u stvari model njegovog buduceg motora za procesiranje kamata u loan-processing sistemu. Uz jedan uslov, zabranjeno je na njegova pitanja odgovarati sa "pa kako ne vidis to!". Ne-programeri vole dijagrame, veoma. Nazalost za sve ljubitelje ekperimentalnih jezika, da bi nesto postalo mainstream biznis mora da prihvati koncept da bi taj koncept bio adekvatno finansiran.


Nema niceg loseg u statickim elementima, sta vise oni su kljucni za implementaciju nekih mehanizama i paterna (kao sto je npr singleton), naravno ne treba preterivati jer ako su ti sve metode staticke onda nisi daleko otisao od imperativnog. Sta bi konkretno dobio time sto bi Main morao da bude instance metod? Samo to da inicijalizacija aplikacije mora jos i da instancira klasu u kojoj je Main i da na stek odvuce i instancu pri pozivu.

@fresh.bm: Vidim da si pažljivo slušao profesora PJ1 prošle subote na ETFu. :)

@mmix

Nisam se najbolje izrazio, a mislio sam na sledece:

Kada prodajes svoju aplikaciju, korsnika ne interesuju ni programski jezici ni paradigme. Njega zanimaju samo dve stvari: funkcionalnost (u koju ubrajam i izgled i UI itd.) i cena. Sve sto se moze uraditi u jednoj paradigmi moze i u bilo kojoj drugoj, a isto vazi i za jezike. E, sad, cemu onda razne paradigme i razni jezici? Pa, zato sto je konkretan posao lakse uraditi na jedan nacin nego na drugi, zato sto se jedan kod lakse ponovo koristi nego drugi i zato sto se jedan kod lakse odrzava od drugog, sto utice i na broj gresaka (funkcionalnost) i na cenu, a to korisnika zapravo zanima.

Mislim da kod bankara vise ide na to koja se baza koristi nego koji jezik. U tom smislu osim ako
ne koristis oo bazu uml dijagrami mu nece nista znaciti ;)
Sto se tice eksperimentalnih jezika, pa f-onalno programiranje postoji odavno i polako
postaje main stream. Svi ovi hibridni OO jezici polako uvode elemente f-onalnog programiranja.
Recimo iznenadio bi se koliko je genericko programiranje pokupilo iz te paradigme.
Da ne govorim o closure-ima i lambda f-jama.
Pa evo mikrosoftov f# koji se nedavno pojavio, je indikator.



Nisam na to mislio. Kao sto vidis nelogicnost da main bude member f-ja tako ja vidim nelogicnost
da main bude static member f-ja. Mislim cemu praviti takvu klasu ;)
Drugo imas f-je kao sto je recimo racunanje hash-a stringa ili neke operacije
koje radis na vise objekata razlicitih klasa koje se logicki ne mogu pridruziti ni jednoj
klasi a ipak moras zato sto nemas izbora. To je po meni forsirani dizajn error.
U principu java klase koristi i kao namespace za f-je i kao strukture podataka sto je po meni
greska. C++ je to ispravno odradio.
E cek sta podrzumevas pod imperativnim kodom.
Pazi programiranje se deli na imperativno i f-onalno.
Imperativni kod ti je niz izraza koji se izvrsava sekvencijalno u programu.
F-onalni kod se sastoji iz samo jedne linije gde se imperativni kod simulira
tako sto se ide kroz listu f-ja.
Dakle
int i = 5;
i = i +1;
je imperativni kod i to ne postoji u cistom f-nalnom jeziku.
Takodje nemas ni tzv destruktivne update tj operaciju dodeljivanja vrednosti,
a naravno ni petlje jer su i one imperativni kod i podrazumevaju destruktivni update ;)

Pozdrav!

Osnovni nedostatak OO metodologije jeste upravo njena strukturna usmerenost. Sve ide dobro dok se radi o skolskim primerima. U realnosti veze izmedju objekata stvaraju enormnu kompleksnost. ZaN objekata,brojmogucih veza je N!/2.

Eve me na dialupu

@MC: Tu si u pravu, ali koje resenje ti predlazes? Ako treba da imas povezanost, onda treba da imas povezanost, ne vidim zasto je to negativna strana OOPa? To je kao reci da ne treba praviti zgrade zato sto su komplikovane i da umesto toga treba da se prave samo jednosobne barake. Upravo ta kompleksnost je dobra jer omogucava kompleksne modele i resavanje kompleksnih problema.


@branislav: Sad cu ti dati konkretan razlog zasto static metode, bar sto se tice .NETa (prica je sigurno slicna i za Javu). U C++ je bilo OK imati free f-je zato sto je metadata klasi i funkcija setan preko include fajlova sto je ukinuto u CLI-u; metadata se sad setao kroz sam kompajliran asembli sto je olaksavalo reuse, medjutim nesto se moralo zrtvovati. Izmedju ostalog to je bio format metadata bloka. Metadata klasa nije samo "oklop" za propertije i metode, on takodje nosi code-security informacije, atribute, JIT hintove, itd i reseno je da free funkcije nece biti deo metadata opisa jer bi to zahtevalo promenu type sistema CLI-a (svaka f-je bi morala da postane poseban CLI tip) bez realne potrebe. To je prvi razlog.
Drugi razlog je ambiguity. Vec sada u vecim C++ projektima sigurno povremeno nailazis na situacije da se u dve biblioteke koje moras da koristis nalaze dve funkcije sa identicnim imenom i vrlo verovatno istim potpisom (narocito ako nema parametara), i to resavas sa namespace-ovima. Ako onda pogledas, to vise nije free f-ja, ona je deo namespace-a i cak se i poziva u istoj formi kao staticka metoda U .NETu su staticke metode deo klase i nije problem ako se zovu isto posto se pozivaju preko imena klase (sto i dalje nije namespace, mozes imati i dva razlicita namespace-a sa istom klasom i istim metodoma za sledeci nivo resavanja).
Mislim da se secam i neke spike o tome da je i jedan od razloga bio i GC, tj da bi ostavljanje free f-ja dodatno usporilo GC proces, ali ne secam se detalja bas, ako iskopam na netu ponovo okacicu.

I i nije mi jasno ovo "U principu java klase koristi i kao namespace za f-je i kao strukture podataka sto je po meni greska. C++ je to ispravno odradio"? Klasa nije namespace za f-je u Javi, a nije ni samo struktura podataka. i zasto bi C++ implementacija bila bolja? Subjektivno zastupas C++ iako kad pogledas objektivno sa funkcionalne strane i generisanog native code-a ne postoji razlika izmedju poziva free f-je i statickog metoda klase.

A to da se programiranje deli na imerativno i funkcionalno E da si ziv i zdrav, pogledaj samo spisak ovde pri dnu strane, a sigurno ih ima jos pride, moraju masteri u CSu na necemu da zarade PhD, gde bolji nacin nego izmisliti neku paradigmu . Neki su zanimljivi, neki dosadni, itd, itd, ali malo njih je mainstream. Pure functional je inace deo deklarativne paradigme, ciji proizvod upravo sada koristis (HTML je deklarativni jezik i mnogo je vise rasprostranjen nego bilo koji OOP, imerativni ili deklarativni jezik).
A i necu da se ovo pretvori u pissing contest imperative vs functional, tu temu smo vec imali ovde relativno skoro. Ajd da se vratimo na OOP

@mmimix

ne predlazem nikakvu alternativu OO programiranju. Vise veza stvara dodatnu kompleksnost, imajuci u vidu da se ne radi o prostim vezama vec da svaka od njih poseduje odredjeni kontekst. Stvari se mogu posmatrati i ovako: mali broj objekta predstavlja nisku granulaciju, tj granice i domeni onjekata su lako prepoznatljivi. Mnostvo objekata stvara konfuziju. Tu se postavlja potreba za hierarhijom. Ali hierarhija implicira interface viseg apstrakktnog nivoa.Odredjene funkcije bivaju sakrivene. Smatram da je resenje uvek jednotavniji dizajn.

A sta mislite o MDA? Ne vidim da je neko to vec gore spomenuo

Miljane, sto se tice CLI prica ti ne stoji posto CLI bez problema podrzava free
varijable, konstante, i f-je. Dokaz ti je C++/CLI.
To sto drugi jezici ne podrzavaju tu mogucnost, nije kriv CLI niti C++.

Drugo namespace nije isto sto i klasa zasto sto ti mozes ubaciti f-ju u namespace
iz drugog source file-a. Sintaksa je ista ali semantika potpuno drugacija.
Da, namespace-i su uvedeni da rese problem ambigitija, tacno.
E sad java ima package sto je prakticno isto sto i namespace u c++-u
sa daleko skromnijim mogucnostima,
ali u cemu bi bio problem da ubacis koju free f-ju u javi i to da nazoves package?

Trece to nema nikakve veze sa gc. Mozes imati gc i za C++ bilo CLI bilo obicnu varijantu.
gc je prosto program koji "baby situje" dealokaciju memorije i nema veze
sa kodom, vec sa podacima.

Cetvrto sto se tice f-onalno vs imperativno hteo sam da usaglasimo terminologiju.
Na osnovu ovoga sto si rekao:

Vidi se da pod imperativnim programiranjem podrazumevas nesto drugo od uobicajene
definicije, tj nesto zastarelo u osnovu na nesto novo,sto nikako ne stoji, pa sam prosto naveo da se programiranje
deli na f-onalno vs imperativno kako bi razjasnio situaciju. A OO programiranje je u svakom slucaju
imperativno.
E sad dal je f-onalno programiranje i deklarativno i koliko jos deklarativnih stilova postoji,
nije bitno u ovome slucaju, to je samo razvodnjavanje poente.

Pozdrav!

Stryder, sta podrazumevas pod mda prvo to reci?

Pozdrav!

Model-driven architecture

Nedostaci:

1.) Ne postoji dovoljno flexibilan nacin za opisivanje modela (UML je jako daleko od toga)
2.) Generatori koda su isto jos uvjek na niskom standardu

PS:
Mada ja to ne bih ovdje ubacivao kao programersku paradigmu vec vise kao sto i samo ime kaze u arhitekturu i pomocno sredstvo.

@mmix
Kao prvo, ako gledamo native kod, onda jeste ista stvar imati statičku metodu u klasi i f-ju u namespace-u, ali je vreme kompajliranja malo duže (čitao sam to negde, okačiću gde...) zato što se dodatno vrši neki type cheking i rešava pitanje padding-a, zato što takvu klasu ipak možeš da instanciraš).

Paketi u Javi na neki način vezuju logičku i fizičku strukturu (čitaj: raspored dir-a na disku. Zbog toga i mislim da su ograničili da može da postoji samo jedna public klasa u paketu) što sa assemblijima u .NETu nije slučaj.

E sada, namespace-ovi su, kao što Branimir reče, "otvoreni" i možeš praviti i aliase tih namespace-ova. (Gde je nešto kao typedef u Javi?)
A i lepo možeš da koristiš "using" (i u nekom drugom namespace-u ili nekoj klasi) i onda će implicitno moći negde da postoje podrazumevani namespace-ovi... Ja se ne sećam da je moguće u Javi bilo gde sem na početku uključiti pakete (ispravite me ako grešim).

Deklaracija statičkih f-ja u klasi (bez ikakvih drugih podataka, dakle samo f-je) je vrlo korisna ako datu klasu koristiš kao Policy klasu, tj. s njom parametrizuješ neki templejt, što sa namespace-om ne bi mogao.

--

Video sam negde da pominješ da su genericsi i templejti slična stvar. Zapravo, oni imaju neku sličnu početnu priču, ali su "ispod žita" dva potpuno različita sveta.

I da, ovo sad čisto onako pitam, ne toliko vezano za celu priču: Da li možeš da uradiš refleksiju nad nekim instanciranim (čiju deklaraciju ne znaš, nije ti dostupna...) generc-om, da sačuvaš info o tome koji je generic u pitanju i da odmah posle toga instanciraš taj generic nekim drugim tipom (parametrom)? Koliko se ja sećam, do neke verzije u Javi su metapodaci o genercs-ima bili siromašni, ako se nisu i gubili skroz.

@Branimir Maksimovic

Kao sto rece bags, mislio sam na Model Driven Architecture koji zastupa Object Management Group. MDA je prilaz razvoju softvera korišćenjem modela. Osim UML-a koristi i Meta Object Facility (MOF) kao i Common Warehouse Metamodel (CWM). MDA podrazumeva razvoj softvera na višem nivou apstrakcije gde se najpre definiše model koji je nezavisan od platforme (Platform Independent Model - PIM). PIM se potom transformiše u Platform Specific Model i odatle se potom generiše kod i vrši se implementacija.

Ok, mislim da ovde vrlo lako mozes da mi dokazes da nisam u pravu, napravi mi managed DLL u managed C++ koji ima free funkciju deklarisanu u metadata bloku. Mislim da ces imati problem da tako nesto ostvaris, al ajde, mozda si u pravu a meni je nesto promaklo.


Pa nije bas, i za to razmisljanje su uglavnom krivi MS i Sun svojim populistickim reklamiranjem tehnologije, GC je u oba slucaja malo kompleksnija zivotinja koja veoma invazivno trackuje alociranu memoriju i njihov lifetime ako su objekti. Ti to ne vidis, ali svaki put kad npr lokalna varijable u retail codu izadje iz scope-a (npr vise se ne koristi posle toga), JIT ce generisati kod koji ce o tome obavestiti GC podsistem. I ne mogu da nadjem taj blog/clanak, ubi me ovaj dialup.


Ja to nisam rekao, sta vise ja se skoro necu preorijentisati sa imperativnog programiranja (I like my state ) i uopste ga ne smatram zastarelim, ali OOP nije imperativno programiranje, nije ni funkcionalno, to je paradigma za sebe; ako vec treba da ga uokviris negde onda mu je mesto pre pored f-nalnog jer je OOP sam po sebi deklarativan, shema klasa i njihovih veza pre odredjuje "sta", nego kako, a konkretna implementacija klasa u nekom jeziku moze biti preko imperativnog ili funkcionalnog koda (ili nekog treceg) u zavisnosti od toga u cemu radis. Mislim da ti konstantno ovo potenciras zato sto vezujes OOP za jezike a to nije slucaj. Istina jeste da OOP bez state-a nije nesto preterano koristan (al ako cemo tako ja to mislim generalno za funkcionalno programiranje), ali koliko vidim po netu postoji primer funkcionalnog OOP jezika (O'Haskel).


Samo utoliko sto moras da sacekas JIT ili da istrpis interpeter, typechecking je compile-side (jedan od benefita strongtyped jezika) a implicitni konstruktor je istina prisutan u outputu ali je neaktivan jer tu klasu ne instanciras (bez obzira sto mozes). Kad kod dodje do trenutka da se staticki metod pozove, sve to je nevazno jer se svodi na call bez pushovanja instance pointera na stek (ili u registar) sto je isto kao i poziv free f-je.


To sve manje vise stoji, ali ja vec par poruka pokusavam da se izvucem iz off topic rasprave of free funkcijama al neuspesno. Ajd, priznajem poraz, free funkcije su svete i nezaobilazne, ajmo dalje


ne znam za Javu jer nisam radio nista slicno u Javi, ali u CLR-u mozes, doduse mislim da moras da emitujes novi tip (strong type) pre nego ga instanciras, provericu, ali refleksija nosi pune runtime informacije o genericsima. (Btw, znam da template i generics nisu isto )

Miljane, sto se managed c++ tice, dovoljno je da on postoji ;)
Ne moram da pravim nikakve dll-ove niti mi je to sad jednostavno posto nit
radim u windows-u niti imam instaliran visual studio ali quick search
mi daje sledece:


Tako da tvoja tvrdnja ne stoji.

Sto se tice gc-a ne mogu da vidim nikakvu vezu sa free f-jama i gc-om.
Bilo kako da je sam gc uradjen f-ja bilo free bilo ne free je kod i nista drugo.
E sad ako cli generise kod koji notifikuje gc kad god neka f-ja izlazi
opet ne vidim razliku izmedju member i free f-je.
Konceptualno izmedju static member, member i free f-je nema apsolutno
nikakve razlike osim sto se member poziva na drugi nacin i sto ima podrazumevan
prvi parametar.
Inace sama member f-ja se ni po cemu ne mora razlikovati od non member f-je.
Ne znam, sto hoces da kazes sa ovim primerima ali tu nikako ne moze
biti neke razlike u tom smislu.



Kako nisi rekao, sta sam ja onda citirao ;)
Nema veze bre sad je terminologija uskladjena, kad si rekao imperativno verovatno si mislio na proceduralno
. Sto se tice OO i f-onalno, naravno da se sad prave
hibridi. No OO deo price ide u paketu sa imperativnim programiranjem ;) pa tako
u tom o'haskelu nalazis monadic objects, a monade su u haskelu nacin da zavrapujes
imperativni u f-onalni kod ;) E sad sa cistim f-onalnim kodom ne mozes daleko dogurati
posto tu ne mozes imati IO ;) O tome ti pricam i mislim da se tu kapiramo.

Na kraju moram da dam demonstraciju zasto mi je muka od member f-ja
i tog forsiranja da sev ide u klasu.
Prvo citat:


http://en.wikipedia.org/wiki/Multiple_dispatch

E sad da napravim kranje glup ali ilustrativan primer manjkavosti c++-a i jave.


Dakle da bi nas programer 2 to odradio elegantno on mora da menja
kompletnu hijerarhiju klasa, tj da dodaje member f-je ili ako vise volite
metode ili message itd i da radi double dispatch.



E sad to je dispatch na dva parametra, zamislite sad da treba na tri ;)
E onda ne preostaje nista drugo negao kao u c-u sto se pravi
OO tako da se iz OO pravi OO tj da se formiraju tabele
pointera i da se trazi presek kombinacije ;)

Pozdrav!

Ovde jednu funkciju namespace-a niko ne pominje. Sećate se onih neimenovanih prostrora imena, koji vam garantuju da ništa iz njih ne ide u objektni fajl?

E, konacno sam se docepao svoje radne masine i kompajlera i sad mozemo konkretno da razgovaramo



E, ko sve nema MVP danas Necu da napadam coveka, ali ovo mu nije jedini omasaj na tom blogu (btw, okaci link sledeci put da ne moram da ga jurim). Ja mozda ne znam sve nijanse CLI C++-a, ali znam kako funkcionise CLS type system i u isti ne mozes da uteras free-f-ju.

Elem, sledeci kod:



je proizveo DLL koji sam zakacio za poruku. Ako pogledas metadata blok i izboris se sa gomilom djubreta koju je C++ nabacao unutra, videces da MojaFunkcija nije free f-ja, ona je deklarisana u IL-u kao:



dakle privatni staticki metod privatne klase <Module>. I to je nacin na koji rade "free f-je" u C++/CLI-u, kompajlerskom prevarom, sve su staticke metode ove klase a namespace se simulira dot-separacijom u samom imenu metoda. Jel sad treba i dokaz da ovu "free-fju" mogu da pozovom preko refleksije u C#-u sad kad znam u kojoj klasi je? To sto je C++ kompajler mufte sve markirao kao private da sakrije svoju prevaru od ostalih CLS compliant jezika ne znaci da mu se ne moze doakati.

Kad pogledas implemenatciju GCKlasa::Poziv() dobices sledeci kod poziva staticke metode:


Q.E.D.



Jbga, ne mogu da nadjem taj post, mozda vise i nije online, u svakom slucaju bilo je to jos u doba nastanka CLSa i radilo se o organizaciji GC-a i vezivanju root-va kreiranih objekata za tipove klasa, sto free f-je ne bi imale pa bi za njih morao da se radi posebni GC model sto bi isti usporilo pa su free f-je izbacene iz CLS-a jer ionako istu funkcionalnost postizes sa static metodama, i da je slicna prica vazila i za Javu, to je sve cega se secam. U principu i nije toliko vazno, necu se opirati mnogo.




Slazem se, multiple dispatch ne funkcionise automatski i jeste ogranicenje OOPa, ali ne vidim ni kako bi mogao da radi jer je totalna antiteza polimorfizmu (tj da vazi ono sto ti hoces, da je OO baziran na free f-jama, onda polimorfizam ne bi radio)
Bar koliko sam ja vidjao do sada, pribegavanje multiple dispatch-u je uglavnom bilo posledica loseg OO planiranja i adhoc razvoja sto je izmedju ostalog i tvoj primer. Vidis samim tim sto si uveo raznorodne operacije (kako rece, uvrnuto sabiranje ) nad istim operatorom+ uveo si sa OOP stanovista da klase D1 i D2 modeluju objekte cija + operacija ne potice iz base klase i samim tim + operator vise ne pripada u base klasi niti moze da se koristi polimorfno, pride (mada ne toliko vazno za ovaj primer) uveo si da + vise nije asocijativna operacija (sto je inace razlog zasto se operator "lepi" za levi operand).

Sve je ovo moglo da se organizuje i drugacije i ne bi ti trebao multiple dispatch i to je do sad uvek bila situacija i sa ostalim ozbiljnijim multiple dispatch problemima.


PS: Zaboravih da okacim DLL, evo ga sada.

_{[Ovu poruku je menjao mmix dana 20.10.2008. u 14:52 GMT+1]}

Gde ti covece pitas o nedostacima "objektno orijentisane metodologije"! Kao prvo ne postoji nista sto se zove "objektno orijentisana metodologija" i nigde to tako nije definisano, moze biti nacin misljenja i jos po nesto drugo ali nikako metodologija, metodologija je waterfall, agile, itd., a kao drugo o tim nedostacima se raspravlja u ozbiljnim softverskim i naucnim krugovima, dakle trebalo bi ovde ref. na radove sa konferencija i ozbiljnih (ISI) casopisa o paradigmama softvera da bi se o tome ozbiljno moglo raspravljati, a ne ovde na forumu na kom se raspravlja od kobasica do lokomotive.

Miljane, ok shvatio sam poentu. Posto CLR to odradjuje preko tog modela,
sta hoces sa time da kazes, da model free f-ja ne valja ili da je to jedini
ispravan model? ;)
Izgubio sam nit diskusije.

Sto se tice gc-a takodje je moguce da su gc pravili oko modela, ali sta sa time
hoces takodje da kazes? Pokazao si da clr implementira free f-je kao static metode.

Sto se tice polimorfizma, on ti je prosto mogucnost da proturis razlicite tipove podataka
kroz isti interfejs. Imas u sustini dve vrste, polimorfizam izgradjen na hijerarhiji
klasa i polimorfizam u f-onalnom izgradjen na bilo kojim tipovima koji se zove jos i genericko
programiranje u OO terminologiji. I to je sve. Ogranicenje polimorfizma
na samo jedan parametar ne znaci opet da je to jedini ispravan nacin i da su svi
slucajevi kad dodjes do potrebe da radis dispatch na vise od jednog parametra
dizajn error. Upravo suprotno mislim ;)


Pozdrav!

Pa ni jedno ni drugo, procitaj thread opet . U osnovi ti si tvrdio da CLR podrzava free f-je zato sto ti CLI C++ dozvoljava jezicku konstrukciju free f-je, i kao dokaz si citirao blog onog nesrecnika. Ja sam ti dao konkretan dokaz da free f-je ne postoje u CLSu, a sve kao deo price zasto Java i CLS nemaju free-fje. Obrati paznju na casu


Opet, ovo je deo price o tome zasto Java i CLS nemaju free-fje, ovaj deo price nije posledica, vez jedan od uzroka. Ali kao sto rekoh malopre, ne mogu da nadjem dokaz za ovo, pa ko da nisam ni rekao.


Mocan ovaj wiki Zapravo imas dosta vrsta polimorfizma, ali onaj koji nas interesuje u multi-dispatch prici je inheritance ili subclassing. To je onaj koji bi bio unisten sa multi-dispatchom, zbog cega ga i nemas u modernim OOP jezicima, a kao sto ti volis fre f-je i multiple-dispatch, tako ja volim svoj subclassing i koristim ga mnogo mnogo vise nego sto bih ikad koristio multiple-dispatch. Sa obzirom na to da samo Lisp ima automatski multiple-dispatch rekao bih da se i vecina ostalih slaze sa tim vidjenjem.


Ajd se prvo raspitaj sta je metodologija pre nego izneses ovako tvrd stav. OO itekako jeste metodologija, samo nije metodologija upravljanja softverski projektima sto su waterfall i agile vec metodologija modelovanja i izrade softvera. I ne vidim zasto se ovde ne bi vodila rasprava o nedostatcima OOP-a i zasto ES nije ozbiljan softverski kruzook . Mi svi koristimo OOP u realne svrhe i vecina nas prehranjuje porodice time, i smatram da je nas stav o tome vazniji od onoga sta o OOPu misle teoreticari programskih jezika koji o tome teoretisu troseci drzavne grant-ove. Jer vidis, na kraju krajeva, ljudi kao sto sam ja ce dati konacni sud o tome na sta ce firma da potrosi pare a zakon trzista ce odraditi ostalo, i iako se ja trudim da imam otvoren stav prema nadolazecim teorijama i da prepoznam nesto upotrebljivo (citaj profitabilno) u tome, isto tako imam uvid u to kako funkcionise taj akademski svet i kakve se sve gluposti i "cuda od tri dana" izmisljaju da se opravda trosenje grantova.

Miljane, malo je verovatno da su dizajneri c# i java jezika mislili na run time platformu
kad su pravili jezik. Mislim da je stvar upravo suprotna.

Tu uporno tvrdis da je nedostatak free f-ja posledica neke realne implementacije
i zbog toga potrebe. Kazem ti, nema nikakve razlike izmedju free, static member
i member f-je. Jedina razlika postoji kod closure f-ja zato sto se one
pakuju zajedno sa argumentima, pa ili se implementiraju kao run time generisani kod
ili se takva f-ja pakuje u strukturu koja vezuje parametar i f-ju.
No ni to nema neke veze sa gc-om, mada ako je platforma tako
zamisljena naravno verujem ti da ima mogucnost optimizacija
koje se koriste.

malo u off : no sa pojavom multicore procesora tesko da ce ikada
bilo kakav threadovani gc skalirati bolje od dobre stare rucne alokacije ;)
Zamisli samo u netu gc mora da zaustavi threadove, pa da muvne memory
blokove pa da izapdejtuje sve reference + sve ostalo sto
standardan gc mora da uradi. To znaci zbogom performanse i korovi ;)
[end off] ;)

Sto se tice polimorfizma, da wiki mora da bude tu, kako bi inace usaglasili terminologiju ;)
Sto se tice vrsta polimorfizama, koje su to druge u programiranju?
Sto se tice multiple dispatch tu se ne slazemo ocigledno ;)


Pozdrav!

@mmix: upravo o tome govorim, ljudi na ovakvim forumima opsteg tipa gde sa raspravlja i o kobasicama i svemu i svacemu razgovaraju o nedostacima neke "metodologije" koja je pre svega zasnovana na teoriji. Sta je metodologija, pogledaj ovde: http://bs.wikipedia.org/wiki/Metodologija. Vi mozete da raspravljate o nedostacima neke konkretne tehnologije, ali o nedostacima cele jedne paradigme raspravljati ovde bez ikakvih referenci je ili smesno ili imate previse slobodnog vremena u prehranjivanju vasih porodica ovim "metodologijama". U svakom slucaju je neozbiljno da neozbiljnije ne moze biti, cak i za jednu (tehnoloski) smesnu zemlju kao sto je ova. Imate strucne forume i mesta gde se moze argumentovano raspravljati o tome. To je moje misljenje a svakako nije ni ovde zabranjeno raspravljati o naslozenijim naucnim i usko strucnim teorijama, to svaki nas covek voli da radi.

I ES je strucan forum*. Ima raznih oblasti, ali se ljudi obicno koncentrisu oko nekoliko onih koje ih interesuju. Madzone ne treba mesati sa tim ;)

*Druga je stvar sto je prosecna strucnost opala zbog porasta kvantiteta.

Milase pusti ti teoriju. Po teoriji idealno programiranje je funkcionalno
iako u praksi sa time ne mozes da napravis ni prost IO.
Po teoriji ne valja ni goto iako se ostavlja u jezicima na ovaj ili onaj nacin.
Jedno je teorija drugo je praksa. Svi jezici koji se se cisto pravili
po teoriji nikada nisu uspeli u praksi. Pragmaticni jezici
koji su zapostavili teoriju na ustrb mogucnosti da se nesto
i prakticno odradi sa time su uspeli. Nije ni cudo sto danas
sve imamo jezike sa viticastim zagradama umesto begin end
blokovima ;)

I na kraju prakticari ce pre videti sta ne valja u teoriji nego teoreticari ;)

Pozdrav!

edit: i da ako si bez blama izjavio kako je diskusija neozbiljna sad bi red bio
da argumentovano ukazes na neku neozbiljnost ili ne?


_{[Ovu poruku je menjao Branimir Maksimovic dana 21.10.2008. u 14:50 GMT+1]}

Dizajneri C#-a mozda i nisu (mada indirektno jesu posto je na jezik drasticno uticala Java), ali dizajneri Java runtime-a i CLR-a apsolutno jesu jer oni zapravo sadrze kljucne sisteme na koje se ovi jezici oslanjaju (posto svi CLS jezici a i Java ne proizvode native vec intermediary bytecode). Ako CLR ili Java runtime ne podrzavaju neku tehniku ili metodu onda jezik moze ili da je ne implementira (kao sto C# ne implementira f-je) ili da nekom prevarom napravi workaround (kao C++).


Pa ne tvrdim vise zar nisi procitao, ne mogu da nadjem dokaz za to sto sam rekao i odustao sam od te tvrdnje.

A i GC se mozda ne skalira tako lepo kao manual alloc, ali se zato memory leakovi bolje skaliraju sto je narocito vazno kod 24x7 core servisa.

Pa pogledaj wiki , ionako nisu vazni za ovu raspravu



@milas:
Pa eto vidis, ja kao nas covek volim da analiziram i raspravljam o najslozenijim naucnim i usko strucnim teorijama (sto OO inace nije) jer mi je mama rodila mozak da ga koristim. Ako tebe na neki nacin nervira sto sam se ja drznuo da to radim iako nemam dva post doktorata u polju i nisam izmislio svoju paradigmu, onda mozes slobodno da ignorises moje postove; medjutim ono sto sigurno ne mozes je da odredjujes o cemu ce ko da raspravlja i kakva ce pitanja da postavlja. I ovaj sajt mozda jeste raznorodan, ali forum u kome sad pises se zove "Art of Programming" i u njemu se ne raspravlja o kobasicama. Na kraju, samo za tvoju informaciju, cilj nijedne rasprave na ovom forumu nije da se doprinese nauci, niti su postovi naucni radovi da moraju da imaju reference, citate i parafraze. Cilj je da se razmene iskustva i da se dodje do nekih tehnickih (inzenjerskih ako hoces) zakljucaka. Ako mislis da neki argument nije osnovan i da ti znas bolje, a ti doprinesi svojim argumentom umesto sto stojis sa strane i pis*s na nas.

A inace, ovaj link ti je carski Odmah sam se prisetio mladosti i idiotluka koji vlada nasim akademskim svetom. Zasto jednostavno kad moze ekstremno komplikovano. Ako ces vec da nas ucis sta je metodologija onda bar citiraj iz onog jezika koji ga je izmislio i shodno bransi koju kritikujes, ne ova nasa bulaznjenja filozofa o tome sta je filozofska metodologija.

Miljane, sto se tice c++ na clr mislim da je to jeftin trik da se privuku c++ programeri ;)

Sto se tice gc, verujem ti to sto si rekao.

Pozdrav!

Ne bih se baš složio da je to samo jeftin trik da se privuku C++ programeri, već rešenje razmišljanja o tome kako da se ne baci u vodu postojeći C++ kod i lagano prebaci kompletno u "clr:safe" režim. A drugo, dizajnerima biblioteka se stavlja u ruke možda jedan od najmoćnijih i najfleksibilnijih (potencijalno i najopasnijih) jezika trenutno.

@Miljan, mmix
I ovako i onako isto "košta" i free f-ja i statička i mislim da niko nije ni tvrdio drugačije, ali je fino imati free f-ju na nivou source-a kako se, na kraju krajeva, nebi petljao s tim da kreiraš klasu, kako bi stavio par f-ja unutra, a usput možeš da nabasaš (vremenom) i na neku koaliziju imena klasa.


Što se tiče polimorfizma, ne vidim zašto je loše imati mogućnost (ili zašto to ruši OO koncept) da polimorfno posmatraš i argumente, a ne da samo objekat pozivajuće f-je bude povlašćen u tom smislu. Tako da, multiple dispatch je zapravo odlična stvar u datom trenutku. Mislim da nema onoga kome u životu nije zatrebao barem double dispatch u nekom OO jeziku.
E sada, ne znam da li biste se složili ili ne, ali ako je negde moguće uvesti multiple dispatch (u vidu biblioteke) na najelegantiji način, onda je to baš C++. Probajte da napišete multiple dispatch u nekom drugom mainstream OO jeziku danas, bilo bi to poprilično teško (a da usput postignete da skoro nema ikakvog nepotrebnog performance hit-a).

Pa sad nisa mbas siguran da postojeci c++ kod mozes da koristis bez problema
gde ti gc pomera memoriju ispod nogu ;)

No verovatno se klasicna alokacija tamo ne kolektuje.
U principu u braku izmedju c++-a i cli-ja ne vidim nista osim problema.

A da je c++ veoma opasan u clr environmentu to svakako da ;)

Pozdrav!

Što se tiče same teme, evo, funkcionalno programiranje se polako javlja u nekim OO jezicima radi elegantnijeg zapisa nekih konstrukcija koje su se vremenom razvilie, ali ne vidim da će se OO paradigma ugasiti u potpunosti ikada jer je to verovatno za sada "najprizemniji" način opisivanja svakodnevnih tokova i problema.

--
@Branimir
Ma nema nikakvog problema što se tiče sprege native C++ -> C++/CLI. Uz malo pažnje ne može ništa preterano da pođe naopako.
Tamo gde treba da koristiš postojeći C++ kod, tamo ćeš pored marshalling-a i pinnovati objekte, tako da ne vidim što bi GC onda bio smetnja.

Ok, jednostavan primer, pseudo code, sve metode su subclassing polimorfne:


Sta ce se desiti? Inheritance/subclass polimorfno, dobices "A => Base", ako ukljucis doubledispatch zaobicices inheritance polimorfizam i dobices "A", a ovo je samo double dispatch i to u prvom stepenu nasledjivanja , sta cemo sa nekom klasom B koja nasledi A i doda jos jedan virtuelni metod?. Fora je sto sa implicitnim single dispatch u vecini modernih OO jezika mozes da kontrolises polimorfizam deklarativno i da odredis sta jeste a sta nije polimorfno, sa dodatnim dispatchom tu mogucnost vise nemas i kompajler/runtime mora da da prednost multi-dispatchu nad inheritance polimorfizmo. Govorimo naravno o automatskom dispatch-u bez potrebe za rucnim pattern match-om. Sve to lepo izgleda na papiru ali u praksi bi napravilo dar mar.

Mozda je to tacno da nekome bas zatreba multiple dispatch kao jedini moguci izlaz iz problema (meni je zadnji put zatrebalo pre par godina u jednom Delphi programu), ali u toj situaciji i u svim modernim OO jezicima uvek mozes sam da odradis pattern match i da pozoves odgovarajucu implementaciju; ali ne vidim te sporadicne potrebe kao razlog da se generalno upropasti inheritance i staticko/vTable linkovanje. Ako u pricu ubacis automatski multi-dispatch onda vise nijedan poziv metoda ne moze biti staticki/vTable linkovan vec svaki poziv MORA da prodje runtime matching pre poziva, sto je jos grdje od dinamickih jezika bar u smislu performansi.

Pitanje je sta je ispravno? Sa obzirom da si specifikovao slucaj
kad je kombinacija D,D ispravno bi bilo da se pozove ta f-ja
a ne varijanta kad drugi parametar odgovar Base ili nekoj drugoj
izvedenoj.

Evo recimo nije me mrzelo da implementiram najprostije
multi methods preko rtti-ja i variadic argumenata.
Izveo sam jos jednu klasu kako bi demonstrirao o cemu se
radi.

Kad se dispatch radi samo na jednom parametru polimorfizam
i ne funkcionise kako treba zato sto specifikacija
za D, D kombinaciju nikada nece biti pozvana.

Medjutim, u slucaju multi metoda cak i izvedena klasa
ce pozvati D,D kombinaciju kada je drugi parametar D
pod uslovom da napravimo takav model da se multi metodi
nasledjuju u slucaju da nisu overridovani za datu klasu.

U slucaju kad je drugi parametar najizvedenija klasa
a sa obzirom da sam uzeo model da samo Base mozemo racunati kao virtuelni
parametar (recimo predlozeni c++ model ukljucuje keyword virtual
uz parametar) f-ja koja najvise odgovara onda biva
ona sa Base drugim argumentom, pa kombinacija D, A ili A, A
zove D, Base.
E sad mozemo uzeti i model po kome je najvise odgovarajuca
f-ja koja najvise specijalizira izvednu klasu pa to moze
biti i D, D




No ovo je samo jedan primer kako to moze biti implementirano
.



E sad, ni ovo ti ne stoji. Sto ne bi mogao da specificiras
free standing f-ju i njen virtuelni overload.
Ne vidim nikakvih problema u tome.
Bilo bi sintaksno dovoljno naznaciti koje f-je overriduju,
tj implementiraju genericku f-ju a koje ne.
Izmedju ostalog imas CLOS i Dylan i jos neke jezike
koje imaju multi methods pa vidi kako je to tamo
odradjeno.




Pazi, nije bas sporadicna potreba. Ne mozes sve moguce f-je
strpati u fiksni interfejs jedne klase,
a pogotovo ne kad nisi autor i nemas prava to da diras.
Evo ti primer, odlican
clanak Scott Meyers-a u vezi toga.
http://www.ddj.com/cpp/184401197

Sto se tice same implementacije multi metoda linkovanje vazi
samo za staticki kompajlirane jezike. Medjutim cak i u tom
slucaju mozes generisati staticke tabele f-ja na osnovu
informacije iz object fajlova u vreme linkovanja. Efektivna implementacija
moze biti odradjena tako da ima konstantni run time cost
ili ne kao u ovoj mojoj naivnoj implementaciji.

Pozdrav!

edit: jos jedan clanak u korist ovog argumenta
http://weblog.raganwald.com/20...uch-of-good-thing-not-all.html
http://www.gotw.ca/gotw/084.htm

<sub>[Ovu poruku je menjao Branimir Maksimovic dana 24.10.2008. u 08:45 GMT+1]

[Ovu poruku je menjao Branimir Maksimovic dana 24.10.2008. u 08:53 GMT+1]</sub>

Nisi trebao da se maltretiras jer to nije bio problem (opet ti promakla nit ). Nije problem koji od ta dva je ispravan, nek bude ispravan taj koji ti kazes. Problem koji je demonstriran je da multidispatch i inheritance subclassing nisu kompatibilni jer konkurisu za isti poziv i da bi multi-dispatch uopste radio subclassing inheritance mora da se "povuce". To mozda tebi izgleda super (ne znam koliko koristis sublassing), ali meni ne izgleda uopste privlacno.


Opet se nismo razumeli, ne govorim o tome. U single-dispatch scenariu kompajler ima informaciju o svim detaljima tog dispatch-a i polimorffizmu jer to potice iz deklaracije, za svaki dodatni stepen dispatch-a te informacije vise nema, glupavo receno ne mozes konsultovati dva v-table-a i moras da radis pun runtime pattern match. Ako to radis onda subclassing inheritance vise nema nikakvog smisla i jezik zaista mozes da svedes na ono sto ti predlazes a to je dinamicki proceduralni nivo jer kad pogledas malo dublje tvoje klase vise nisu nista sem strukture sirovih podataka.
Ne znam kako CLOS i Dylan to resavaju, da u isto vreme imas inheritance polimorfizam i multidispatch polimorfizam i da se oni ne kolju, pa daj neki primer, valjda cu prokapirati



Haha, a imas pravo da dodavanjem extra multidispatch fja/metoda totalno poremetis osmisljeno funkcionisanje tih klasa? Vidis automatski multidispatch je retroaktivan, pa se promene ne odnose samo na tvoj kod, odnose se i na sve pozive koji vec postoje u tim klasama ciji nisi autor i koje ne smes da diras. Ako sklonimo sujetu programera na stranu (ono, niko ne moze da menja moj kod jer sam ja List<superlativ>) obicno postoji dobar razlog zasto je funkcionalnost enkapsulirana tako da ne mozes da je promenis kroz subclassing.

A za clanak, pa ima dosta stvari sa kojima se u tom DDJ clanku ne slazem, a najvise u vezi enkapsulacije. Iz nekog razloga skoro svi hardcore C++ programeri imaju zesci animozitet prema enkapsulaciji (pred velike ljubavi prema fjama ), valjda misle da ce sa njihovim kodom da bartaju samo drugi hardcore C++ programeri koji ce uvideti lepotu pa nema potrebe da se bilo sta 'skriva' . Realnost je mnogo surovija. Meni je npr enkapsulacija od velike koristi kako u modelovanju tako i u kontrolisanju sampiona.


Znaci ako dinamicki ucitas DLL u aplikaciju sa novim multidispatch implementacijama, one nece biti ukljucene? Sto ne? Uz najbolju volju ne vidim kako bi mogao da napravis univerzalni automatski multidispatch a da nema pun runtime pattern match.Ti to mozes malo da optimizujes kroz neko type indeksiranje, ali ne vidim mogucnost za konstantni runtime cost.

Tvoj argument da multiple dispatch iskljucuje single dispatch ne stoji.

Oba mogu koegzistirati zajedno. U kontekstu poziva single dispatch-a instanca.method()
radio bi se single dispatch, a u kontekstu genericmethod(instanca) radio bi se multiple
dispatch.
Takodje dao sam primer kako bi subclassing inheritance mogla da funkcionise.
Jednostavno kao i za single dispatch. Izabere se najspecijalizovaniji oblik
za izvedenu klasu i sa time napunis dispatch tabele. Nije nikakav problem.
To ti je isto sto radi i single dispatch.

Sto se tice tvog argumenta za linkovanje i slicno to ti uopste ne stoji.
Evo recimo imas konkretni proposal kako to da se implementira u C++
sa konkretnom sintaskom sa konkretnim izmenam u modelu i linkeru.
http://www.research.att.com/~bs/multimethods.pdf

Sto se tice agrumenta za fiskiranje interfejsa opet si okrenuo pricu naopako
i nudis pricu tipa c++ programeri ovo ili ono.
Ovo:


Ne razumem kako bi se ovo razlikovalo od toga kad overridujes neku f-ju iz bazne klase.
Sa obzirom da se behavior menja i u jednom i u drugom slucaju? To je ono sto hocemo, zar ne?
Medjtutim sada si proponent glomaznih i fiksnih interfejsa za koje se top strucnjaci
u ovoj oblasti slazu da su stvar proslosti.


Sve u svemu. Tvoji argumenti se sastoje iz dva dela. Jedan da je to neko narusavanje
OO principa , sto ne stoji zato sto je single dispatch samo specijalizovani slucaj mutli dispatch-a,
a drugo da je to tesko odraditi u praksi. No evo naveo sam konkretan predlog za staticki
kompajliran jezik i to sa konstant time izvrsavanjem, dakle ipak moze.
Sto se tice dll-ova nema veze, ti ionako prvo linkujes tako sto znas kako ce ti dll pozivi izgledati.
To sto se linkovanje odradjuje u run time-u ne sprecava kompajler
da izgradi tabele u kodu i pre toga.
Jedini slucaj kad to ne radi je kad ti rucno ucitas dll pa jedini interfejs koji imas je C api.
Ali tu ti ne radi ni single dispatch onda ;)
No mikrosoft ima com standard binarni interfejs pa com single dispatch radi ali to nema veze
sa ovim sto pricamo.

Pozdrav!


_{[Ovu poruku je menjao Branimir Maksimovic dana 24.10.2008. u 20:40 GMT+1]}

Mi se bas ne razumemo. Ne iskljucuje single dispatch (koji takodje radi pattern match) vec iskljucuje inheritance polimorfizam koji ne koristi pattern match vec koristi indirektni poziv preko vTabele. Nema veze koju implementaciju koristis inheritance polimorfizam moze da postoji samo do trenutka dok se ne pojavi metod sa matching runtime patternom i onda mora da se povuce inace multidispatch ne bi radio, to je jednostavno cinjenicno stanje i to sam ti dao u onih par linija koda, definitivno ne mogu oba metoda biti pozvana u isto vreme i stvarno ne vidim kako mislis da je to resivo?
Takav parcijalni inheritance je veoma opasan jer ne mozes da se pouzdas u to da ce raditi svoj posao cime takodje celokupan encapsulation pada u vodu jer ne mozes da zadrzis kontrolu nad tim kako ce tvoja klasa funkcionisati.

I taj clanak o openmethods je ok, i sve to stoji i nista o tome nisam ni pricao (a i ako pogledas u ovom sistemu vazi da dispatch gazi inheritance kroz om-tabelu). Inace, problemi na koje sam ja hteo da ti ukazem su lepo opisani u poglavlju 5 (Dynamic Linking). A sto se tice implementacije i performansi, zaboravljas da tokom runtime-a moras pri pozivu nekako da lociras poziciju unutar om-tabele, taj deo koda je patternmatching i mora da se uradi prilikom svakog poziva i progresivno je sporiji sa velicinom om tabele, nije fiksan.


Ma dobro, to je bilo zezanje, mada donekle. Izvini ako te to pecnulo, nije mi bila (zla) namera, ali niste ni ti ni Scott ni prvi ni poslednji C++ guru-i koji mi prodaju tu pricu. I sa teorijskog stanovista to zvuci veoma sareno i obecavajuce, ali nije (citaj dalje). I ja nisam proponent glomaznih interfejsa (mada fiksnih jesam) niti oni moraju da budu glomazni vise nego sto je to neophodno za njihovo zaokruzeno funkcionisanje, ali ta tvrdnja da si ti povecao enkapsulaciju i resio se glomaznog interfejsa time sto si metode prebacio u non-member f-je je naivno, jesi smanjio interfejs ali si povecao kolicinu spagheti-koda u programu i iz logickog OO koncepta klase kao zaokruzene celine si izbacio neku funkcionalnost kojoj je tu mesto (da totalno zaboravimo na neke nevazne zivotne olaksice kao sto je intellisense). I kad procesaljas kroz ceo sors, glomazni interfejs je i dalje tu samo sto ga vise ne koristis kroz instancu vec kao set slobodnih f-ja.


Razlikuje se utoliko sto kreator klase kontrolise access modiferima sta mozes i ne mozes da overridujes i time stiti svoju enkaspulaciju. Potreba za multi-dispatchom se bar iz mog iskustva pojavljuje kao rezultat frustracije sto nesto nisi mogao da odradis kroz subclassing a bas ti je zapelo za oko ili je autor klase bio kratkovid i pisao je kao da je sealed a nije. Pa ajde da zeznemo autora klase i da ga ispreskacemo . Time po meni prizivas djavola i trazis probleme.

subclassing i inheritance polimorfizam je u biznis aplikacije doneo modeling i pouzdanost tih modela, kad bih odustao od toga morao bih sebe da lisim pouzdanosti koju mi donosi:
- da znam uvek sta ce se i kako pozvati
- da znam pouzdan i stabilan nacin na koji se funkcionalnost i definicija prosiruju i da je to uokvireno u neke celine
- da niko sa strane (out of scope) to ne moze da izminira
- da determinizam poziva ne zavisi od toga koji moduli su ucitani u domen
- vezano sa tim, da mogu da u domen ucitam nasledjenu klasu bez da poremetim rad postojeceg koda.
- da zadrzavam enkapsulaciju i stavim korisniku klase (programeru) do znanja gde mu NIJE mesto.
- ako bas, bas, bas, BAS mora da se odradi neki multi-dispatch, skoro svi OOP jezici to omogucavaju kroz rucni patternmatch
- i last, but not least, da korenita promena u zahtevima postojeceg objektnog modela nece moci da se adhoc zakrpi vec ce izazvati obavezan povratak OO modela za drawing desk.

I ja pretpostavljam da ovo poslednje tebi najvise bode oci, i meni je svojevremeno (sta me cima ovaj projektant kad ja to mogu da zakrpim za 10 minuta), ali od kad sam vise poceo da se bavim arhitekturom i nekim drugim parametrima kao sto je pouzdanost, stabilnost, odrzivost, TCO, itd, iskreno manje eksperimentisem i vise kontrolisem sa cime se eksperimentise u projektima od kojih zavisi biznis firme. Sa tog stanovista multi-dispatch mi ne donosi nista fundamentalno korisno i nezamenljivo, samo potencijalne glavobolje i pored toga sto je mocniji i neke stvari resava bolje nego mainstream inheritance poly. U jednoj prosecnoj viseglavoj ekipi uvek ima sampiona, i uvodjenje multi-dispatcha (jos sa free f-jama) u takvu sredinu mi deluje kao davanje Hilti busilice maloj deci, nista dobro iz toga ne moze da izadje.
Tako da se vratimo na temu, to sto nema multi-dispatch-a u mainstream OO jezicima jeste nedostatak, ali je nedostatak sa kojim cu se rado pomiriti i sve i da ga ubace kroz dodatne sintaksne konstrukcije necu ga koristiti.

Da pocnem, jeste ne razumemo se.
Single dispatch moze postojati zajedno sa multiple dispatch-om
tako sto oba mogu koegzistirati. Obe funkcije zasigurno ne mogu
biti pozvane ali ima slucaja kad ti odgovara jedno ili drugo.
Nema nikakvih problema da se postojeci jezik nadogradi generickim
f-jama ali isto tako nema razloga da se eliminisu metodi zbog toga.

Sto se tice c++ predloga problemi o kojima si ti govorio sam
shvatio u smislu teskoca u pogledu implementacije samog
dispatch-a u okviru linkovanja,
a ovaj clanak govori o problemima detekcije gresaka
tj ambuigitija u slucaju kada vise f-ja odgovara jednoj
kombinaciji i mogucem resavanju istih.

Sto se tice spageti koda, i free f-ja, argument ti je da
na taj nacin razbacujes interfejs na sve strane umesto da
stoji na jednom mestu.
Propustio si da primetis koje su prednosti toga.
Prvo ne moras da linkujes i ucitavas kompletan kod koji ti ne treba.
Drugo ne moras da rekompajliras celu hijerarhiju radi dodavanja
jedne f-je. Trece programer mozda pise kastom kod koji samo
njemu koristi i nigde vise.

Sto se tice argumenta o menjanju ponasanja i razlici izmedju multi
metoda i single dispatch-a u okviru poziva virtuelnih
funkcija kazes sledece:


Pa ako stavis da je f-ja virtualna ne vidim nacina kako bi sprecio
nekoga da to overriduje ili ne?
Ako neces mogucnost da se radi multi dispatch napravis najobicniju
f-ju i pozoves je i nema override-a.
Nema cistih virtuelnih multimetoda ukoliko mislis da se to
separatno kompajlira i linkuje.
Dakle morao bi da napravis jednu virtuelnu i da je pozoves.
A cim si to imao na umu pretpostavio si da neko vec hoce da menja
ponasanje postojeceg koda zar ne?
Kako se to onda razlikuje od toga kad ti je member virtual?

E sad ono najbitnije, sto moram da citiram:


Doneo je odredjenu vrstu modelinga. Proglasio je podatak
za objekt, a objekte entitete koji mogu da aproksimiraju realne
objekte. Tacno, ali je uveo i nivoe apstrakcije i tehnike koji
zahtevaju daleko vise znanja nego sto je ranije bilo potrebno.



To u objektnom programiranju ne znas.
Sve sto znas je da saljes poruke nekim objektima
za koje ne znas ni kog su tipa.
Sve sto imas je interfejs koji se satoji iz mogucih
poruka datim objektima, a sta konkretno treba da se
desi nadas se po imenu;)


U okviru- OO hijerarhija jedini stabilan nacin da prosirujes
funkcionalnost je u oviru onoga koji je napravio dizajn.
Dakle ako prosirenje funkcionalnosti nije pokriveno dizajnom moras da menjas
postojeci kod.


dodavanje generic f-ja ne bi tu bio problem. one ionako ne bi imale prava
pristupa.



pa ovakvu garanciju nemas ni kod proceduralnih jezika.



to vec zavisi od dizajna


to neces postici tako sto ces onemoguciti korisniku da dodaje
f-je koje su mu potrebne.
enkapsulacija se ne narusava kodom koji ne razbija postojeci vec predstavlja
dodatak.


Ako cemo tako i OOP moze da se simulira kroz tabele pointera na f-je
i f-je koje za prvi parametar uvek uzimaju neku strukturu.


Povratak OO modela za drawing desk je priznavanje poraza,
a to kosta vremena i novca, pogotovo ako je veca aplikacija
u pitanju i pogotovo ako se klijentski kod oslanja na to.
Ne mozes back to scratch u svim uslovima.

No nisam siguran o kakvim hilty busilicama govoris.
Multi metodi i free f-je su prosto resenje da se sav
kod koji se razbacuje po razlicitim meotdama klasa
logicno organizuje i preuzme. Nema tu nikakvog narusavanja
necega jer te f-je nemaju prava pristupa podacima klasa,
a samim tim sto se sav pristup zasniva na pozivanju
metoda opasne su koliko i bilo koji kod, u bilo kojoj
drugoj metodi, bilo koje druge klase.
Pozdanost, stabilnost i odrzivost na koju se pozivas
zavisi upravo od ovoga o cemu pricamo.

Pozdrav!

edit:
sta bi onda rekao na AOP, mogucnost da patchujes kod na osnovu upita tipa
gde go metod pocinje sa tim i tim imenom izvrsi ovo pre ili/i posle
Ili tipa dodavanje metoda na klasu i slicno sto se radi u AOP-u ;)

ovo je opasno, a ne free f-je i genericki metodi ;)


_{[Ovu poruku je menjao Branimir Maksimovic dana 25.10.2008. u 06:03 GMT+1]}

Pa i nisam bas odusebljen AOP-om ali je to work in progress, pa pratim da vidim sta ce da se desi ;)


Pazi, mi ovako mozemo da se djroramo narednih godinu dana, poceo sam da spremam odgovore na tvoje odgovore na moje odrgovore... i provalio sam da opet pisem iste stvari. Cinjenica je da nista sto ti kazes nece promeniti moj stav i nista sto ja kazem nece promeniti tvoj, ali koliko vidim obojca smo izneli gomilu pro i cons za oba pristupa, tako da mislim da je vreme da se slozimo da se ne slazemo i da prepustimo citaocima da sami vide sta njima odgovara.

@ topic

Ne znam koliko OO pristup moze da podrzi upravljanje, razvoj i stalne promene. npr. Imas poveci broj objekata koji komuniciraju medju sobom, i sada se u jednom trenutku promeni nacin poslovanja, pa ti sada moras opet u kod da idesh da menjas i td..., to je potpuno neprakticno ako imas veliki broj ucesnika. Jednostavno ne znam koliko je ovaj pristup dobar na promene, da li na lak nacin moze da ih podrzi itd...

OOP je i zamisljen da resi ovakve situacije, da kada dodje do promene necega u sistemu, da se to nesto zameni lako i tako da korisnik to ne primeti.
Evo ovako: Recimo da imas neku aplikaciju, 3-tier, i za "data layer" si koristio klasu ciji objekti pristupaju MS SQL DBMS-u, i to je ok. Ali korisniku sine da umesto MS SQL odluci da koristi recimo "MS Access DBMS" i sve sada sto developer treba da uradi jeste da zameni klasu u "data layer-u".
Tako da ako se promeni nacin poslovanja obicno ima neko ko je vec napisao neku ako ne istu onda slicnu klasu koju mozes samo da nasledis i dodas sta ti treba.
OO je bas dobar za stalne promene.

PozZ

a ako si daš truda, u datalayer ubaciš klase za nekoliko baza, i promjenom imena baze u opcijama automatski se aplikacija kači na tu bazu.

Poenta objektno baziranog programiranja, a to je veci deo objektno orijentisanog programiranja, je da se veze izmedju entiteta jasno odvoje i vide. Konkretno, ono sto je stvar samog entiteta (klase u OOP) se vise ne vidi spolja, pa veze izmedju entiteta postaju jasne.

To nije nikakva nova ideja, tako su ljudi radili i pre OOP jezika (i pre OBP jezika, kakav je npr. VB6), ali nije bilo sintaksnih ogranicenja (npr. kljucne reci "private") da to zaista spreci programera da napravi da neka funkcija krene da "krlja" po strukturi koja joj je prosledjena, a gde se ocekivalo da ona samo procita neke podatke.

(Naravno, OOP je vise od ovoga, ali ovo - enkapsulacija - je verovatno najbitnija stvar OOP-a.)

Medjutim, nece OOP da te spasi loseg dizajna. A tipican primer loseg dizajna je kada je proces komunikacije izmedju objekata los. Na primer, kada jedan logicki kanal komunikacije (npr. logicki tok podataka, proistekao iz biznis logike) implementaciono razbijes na nekoliko, pa se onda pola koda svede na pokusaje sinhronizacije komunikacije, i kada svaka izmena zahteva da se sve to ponovo natera da radi.

Lako je naci programe u kojima postoji previse veza. Iako formalno postoji enkapsulacija, ona se krsi time sto su objekti/klase medjusobno previse spregnuti, jer objekat A prestaje da radi ako objekat B nije tacno u stanju X, koje se postize time sto se operacije a, b i c izvrsavaju tacno tim redom i nijednim drugim...

OOP pomaze da se stvari zaista zaokruze u nezavisne celine, ali ni jedan nacin programiranja, pa ni OOP ne moze da sam od sebe resi probleme loseg dizajna.

Dalje, zaokruzivanje stvari u celine (bilo preko OOP ili na primer, pravljenjem multi tier aplikacije) pravi probleme same po sebi. Ako kasno u projektu otkrijes da neki podaci nisu dostavljeni tamo gde bi trebalo da budu, to najcesce znaci da se mora menjati nekoliko entiteta. E, tu ljudima padaju na pamet razne ideje kako doturiti podatke.