Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Prelaz od C ka OO programiranju

[es] :: Art of Programming :: Prelaz od C ka OO programiranju

Strane: 1 2 3 4 5 6

[ Pregleda: 9576 | Odgovora: 101 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Whitewater
dummy workshop

Član broj: 339178
Poruke: 339



+130 Profil

icon Re: Prelaz od C ka OO programiranju30.11.2018. u 04:56 - pre 27 meseci
zlatni:

pa istina je da sam vas tamo 6 strana pitao kako da postavim IDE za PHP sa debugger i onda sam kao to batalio.

Privremeno. Privremeno. Nebojse ja cu opet doci da vas nerviram )))

Sto se tice C, pristup Prate i vecine knjiga nije dobar jer objasnjavaju pointerv preko array. Tu se ne vidi prava prednost pointera. Ali posle sam pitao i onda sam nasao strukturu podataka LIST i konkretno implementiju preko pointera. E tako moze da se razume zasto koristimo pointere, recimo kod polinoma koji nemaju sve stepene monoma itd... dinamicka vs staticka alokacija memorije...

Tu sam jedno 10tak dana potrosio, cak sam sisao i do nekih stvari u Assembleru, nacinu alokacije memorije i da sad ne davim dalje... citao developer manual sa AMD web site jer imama AMD E1 processor.

Mislim da se vracam PHP za nekih 7 dana, a onda cu malo cackati i taj DELPHI.




Rest of world: This is what we think of America.
America: We don't think about you at all !
Prikačeni fajlovi
 
Odgovor na temu

Zlatni_bg
Nikola S
Beograd

Član broj: 65708
Poruke: 4263
*.dynamic.sbb.rs.



+489 Profil

icon Re: Prelaz od C ka OO programiranju30.11.2018. u 05:09 - pre 27 meseci
Mozda sam zaboravio za debagera za PHP. Ono sto bih savetovao pocetnicima je samo paljenje error reportinga, bice sasvim dovoljno za pocetak.
THE ONLY EASY DAY WAS YESTERDAY
 
Odgovor na temu

Whitewater
dummy workshop

Član broj: 339178
Poruke: 339



+130 Profil

icon Re: Prelaz od C ka OO programiranju30.11.2018. u 05:12 - pre 27 meseci
Citat:
Zlatni_bg: Mozda sam zaboravio za debagera za PHP. Ono sto bih savetovao pocetnicima je samo paljenje error reportinga, bice sasvim dovoljno za pocetak.


okay imacu to u vidu. poslao sam ti sliku dokaz da sam pribavio tesku artiljeriju jer sam stekao utisak da mislis da te foliram.
Rest of world: This is what we think of America.
America: We don't think about you at all !
 
Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8410
*.ptt.rs.



+2728 Profil

icon Re: Prelaz od C ka OO programiranju30.11.2018. u 18:21 - pre 27 meseci
Citat:
jablan: Dobar indikator da je knjiga (tutorijal, kurs...) o OOP loša, je kad krenu da pričaju o klasama na primeru Pas -> Životinja ili Trougao -> GeometrijskaFigura. Nije mi jasno zašto ne uzmu bilo koji primer iz bilo koje standardne OOP biblioteke (Rational -> Numeric, File -> IO itd)

Da mi je znati šta je loše u uzimanju opšte poznatih primera.
Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.
 
Odgovor na temu

Whitewater
dummy workshop

Član broj: 339178
Poruke: 339



+130 Profil

icon Re: Prelaz od C ka OO programiranju30.11.2018. u 18:28 - pre 27 meseci
u redu ubedili ste me vracam se PHP odmah.
Rest of world: This is what we think of America.
America: We don't think about you at all !
 
Odgovor na temu

mjanjic
Šikagou

Član broj: 187539
Poruke: 2091



+586 Profil

icon Re: Prelaz od C ka OO programiranju01.12.2018. u 00:04 - pre 27 meseci
Citat:
Nedeljko:
Citat:
jablan: Dobar indikator da je knjiga (tutorijal, kurs...) o OOP loša, je kad krenu da pričaju o klasama na primeru Pas -> Životinja ili Trougao -> GeometrijskaFigura. Nije mi jasno zašto ne uzmu bilo koji primer iz bilo koje standardne OOP biblioteke (Rational -> Numeric, File -> IO itd)

Da mi je znati šta je loše u uzimanju opšte poznatih primera.


Veoma retko se koriste u praksi, tako da početnici nauče to kao pesmicu, a nemaju pojma gde se u praksi koristi nasleđivanje niti šta je svrha.

Problem je što je proces u praksi obrnut - prvo se u projektovanju pojave pojedinačne klase, pa kad se utvrdi da neke od njih imaju značajan broj istih atributa (i eventualno metoda), onda se vrši generalizacija - kreira se apstraktna klasa iz koje se izvode odgovarajuće klase.

Zašto, šta je problem imati sve to bez nasleđivanja?
Pa, šta ako rešite da neki od atributa umesto tipa Float budu Double, ili umesto Int budu String (tokom refactoring procesa ili iz nekog drugog razloga)? Ako je jedan od tih atributa deklarisan u svakoj klasi nezavisno, ko će da juri gde se on sve nalazi kako bi promenio deklaraciju? Lakše je ako je deklarisan u apstraktnoj klasi (ne mora da bude apstraktna u smislu kao kod Jave).


Ali, opet ni to nije očigledno kod jednostavnih klasa.
Dovoljno je pogledati GUI aplikacije, svaki dijalog ima isti oblik (pravougaonik), okvir, moguće kontrolne elemente... lakše je napraviti jednu klasu pa izvođenjem kreirati različite vrste dijaloga, nego raditi sa 100 različitih klasa koje se razlikuju za po jedan atribut, jer u slučaju da treba nešto izmeniti kod svih 100 vrsta dijaloga, samo se izmeni u apstraktnoj klasi.


Zato se početnicima zada problem sa 30 različitih tipova knjiga (koje imaju deo istih atributa i metoda, čak metode mogu biti i sve iste), pa videti da li će kreirati 30 različitih klasa ili koristiti nasleđivanje.
Onima koji naprave 30 različitih klasa reći da sve knjige imaju još 10 novih atributa, a kad i to odrade, kažete im da se zahteva još 50 novih vrsta knjiga.

Ako sve to i urade, onda im pokažete primer sa nasleđivanjem i pitate ih koji bi kod radije održavali i unapređivali.
Blessed are those who can laugh at themselves, for they shall never cease to be amused.
 
Odgovor na temu

Branimir Maksimovic
Senior Software Engineer

Član broj: 64947
Poruke: 5171
109.72.51.*



+1025 Profil

icon Re: Prelaz od C ka OO programiranju01.12.2018. u 06:38 - pre 27 meseci
https://codeburst.io/inheritan...vil-stop-using-it-6c4f1caf5117

edit Apropo ovoga Go i Rust su potpuno izbacili nasledjivanje kao koncept a sa tim i klase, ono sto samtraju ispravnom praksom a to su interfejsi
to su ostavili.
press any key to continue or any other to quit....
 
Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8410
*.ptt.rs.



+2728 Profil

icon Re: Prelaz od C ka OO programiranju01.12.2018. u 07:40 - pre 27 meseci
@mjanjic

Pa, valjda treba da razumeju koncepte, a ne da nabubaju napamet veze između bibliotečkih klasa.

Dao si primer sa vrstama knjiga, koji je sličan primeru sa životinjama po tome što je zasnovan na nečemu opšte poznatom iz stvarnog sveta.
Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.
 
Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8410
*.ptt.rs.



+2728 Profil

icon Re: Prelaz od C ka OO programiranju01.12.2018. u 08:01 - pre 27 meseci
@Branimir Maksimovic

Meni se gade ti fašistički jezici, koji me prave budalom i uče me šta i kako treba da radim. Zato nikada nisam mogao da se prebacim sa C/C++ na nešto drugo, sem Python-a za sitno. Dobro, imam i neke bash skripte. Takođe, radio sam u drugim jezicima (npr. Java) za posao, koristio JS za frontend. Međutim, za OOP, samo C++. Pruža mi svakakve mogućnosti, tako da mogu da biram šta ću da koristim. Kada jednom navikneš na slobodu, posle ne možeš u konc-logor.
Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.
 
Odgovor na temu

Branimir Maksimovic
Senior Software Engineer

Član broj: 64947
Poruke: 5171
109.72.51.*



+1025 Profil

icon Re: Prelaz od C ka OO programiranju01.12.2018. u 08:23 - pre 27 meseci
Ne kapiram, kakvi su to fasisticki jezici? Jezici koji nemaju klase i nasledjivanje su fasisticki ili je to neka druga paradigma?
Go i Rust autori su videli kako funkcionalni jezici lepo zive bez toga, pa su i oni krenuli tim putem... jos pre 10 godina su ljudi uvideli
da je duboka hijerarhija klasa anti-patern i da nasledjivanje ne treba da ide vise od jednog nivoa u dubinu. Logican zakljucak
je da onda ne treba nikakve podatke stavljati u baznu klasu, pa iz toga sledi da su interfejsi jedina logicna implementacija
nasledjivanja u modernom OOP-u. Iz toga sledi da je nasledjivanje potpuno nepotrebno, i et orezultata ;p
Procitaj onaj tekst koji sam linkovao ;p

press any key to continue or any other to quit....
 
Odgovor na temu

Shadowed
Vojvodina

Član broj: 649
Poruke: 12705



+4688 Profil

icon Re: Prelaz od C ka OO programiranju01.12.2018. u 08:51 - pre 27 meseci
Citat:
Whitewater:
u redu ubedili ste me vracam se PHP odmah.

Upropastiste coveka
 
Odgovor na temu

Branimir Maksimovic
Senior Software Engineer

Član broj: 64947
Poruke: 5171
109.72.51.*



+1025 Profil

icon Re: Prelaz od C ka OO programiranju01.12.2018. u 08:53 - pre 27 meseci
To ti je ono put oko sveta programskih jezika za 10 dana ;)
press any key to continue or any other to quit....
 
Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 893
77.46.175.*



+171 Profil

icon Re: Prelaz od C ka OO programiranju01.12.2018. u 09:06 - pre 27 meseci
Citat:
Branimir Maksimovichttps://codeburst.io/inheritan...vil-stop-using-it-6c4f1caf5117

edit Apropo ovoga Go i Rust su potpuno izbacili nasledjivanje kao koncept a sa tim i klase, ono sto samtraju ispravnom praksom a to su interfejsi
to su ostavili.


Skoro pa prvi komentar :D

Citat:

Inheritance is fundamental base of OOP, what you try to say is stop using OOP but in fact you demonstrate „I don’t know how to use it properly“.



Od kada je pocela ova trka oko funkcionalnih konstrukta (u svim jezicima), odjednom OOP postaje losa opcija.

Sto se tice interface-a, sve zavisi za sta, kako i gde ih koristis (recimo u nominalnom type sistemu, interfejsi su vise zlo nego korist, opet ne zbog samih interfejsa nego zbog zloupotrebe, dok u strukturalnom type sistemu, interfejsi imaju mnogo vise smisla zbog fleksibilnosti).
 
Odgovor na temu

Branimir Maksimovic
Senior Software Engineer

Član broj: 64947
Poruke: 5171
109.72.51.*



+1025 Profil

icon Re: Prelaz od C ka OO programiranju01.12.2018. u 09:21 - pre 27 meseci
Najveci razlog zbog koga se prelazi na funkcionalnu paradigmu je multi threading. OOP podrazumeva mutable shared state sto se smatra za zlo kada se threadovi ukljuce u igru.
Sto se tice interface-a ne vidim kakve veze to ima sa type sistemom. Haskell i Rust imaju nominalni type sistem a interfejsi se tu odlicno uklapaju u genericko programiranje,
zato sto su u ovom slucaju genericki parametri ograniceni interfejsima koje implementiraju. Moguce je naravno i upotrebiti ih u dinamickom bajndovanju i ne vidim nista
sto tu smeta i kako bi se moglo zloupotrebiti vise nego inheritance.
Da ne bi sad pricali sta bi bilo kad bi bilo, da li mozes da navedes primer zloupotrebe interfejsa u jeziku sa nominalnim type sistermom, pa da znamo o cemu pricas ;p?
press any key to continue or any other to quit....
 
Odgovor na temu

Whitewater
dummy workshop

Član broj: 339178
Poruke: 339



+130 Profil

icon Re: Prelaz od C ka OO programiranju01.12.2018. u 09:46 - pre 27 meseci
hvala vam na brojnim savetima malo sam pogledao predloge: Ruby, Smalltalk sisao i do Simule stare dobre, razmisljao o Object C i Swift... Jednom se mora preseci, a ja sam presekao:

idem na C++ !

glavin razlog je sto je Prata napisao C i C++ knjigu, a svidja mi se kako je uradio C mada me smorio sa pointerima. Stekao sam poverenje u njega jer detaljno objasnjava...

pozdrav veterani.

odlazim u noc u mecavu, pokusacu da se probijem. Ako zaginem niko me se nece secati, a ako prezivim uci cu u legendu.

ja sam ovaj na lokomotivi 2:20




Rest of world: This is what we think of America.
America: We don't think about you at all !
 
Odgovor na temu

Branimir Maksimovic
Senior Software Engineer

Član broj: 64947
Poruke: 5171
109.72.51.*



+1025 Profil

icon Re: Prelaz od C ka OO programiranju01.12.2018. u 09:47 - pre 27 meseci
Slobodno postavljaj pitanja o C++-u na forumu ;)
press any key to continue or any other to quit....
 
Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 893
77.46.175.*



+171 Profil

icon Re: Prelaz od C ka OO programiranju01.12.2018. u 10:51 - pre 27 meseci
Citat:
Branimir Maksimovic:
Najveci razlog zbog koga se prelazi na funkcionalnu paradigmu je multi threading. OOP podrazumeva mutable shared state sto se smatra za zlo kada se threadovi ukljuce u igru.
Sto se tice interface-a ne vidim kakve veze to ima sa type sistemom. Haskell i Rust imaju nominalni type sistem a interfejsi se tu odlicno uklapaju u genericko programiranje,
zato sto su u ovom slucaju genericki parametri ograniceni interfejsima koje implementiraju. Moguce je naravno i upotrebiti ih u dinamickom bajndovanju i ne vidim nista
sto tu smeta i kako bi se moglo zloupotrebiti vise nego inheritance.
Da ne bi sad pricali sta bi bilo kad bi bilo, da li mozes da navedes primer zloupotrebe interfejsa u jeziku sa nominalnim type sistermom, pa da znamo o cemu pricas ;p?


Hm, mutability ne bi trebalo da ima veze sa paradigmom, tj. i nema. Immutable tipove podataka mozes da imas u kom god hoces jeziku, i cak sta vise, imas dosta dobrih implementacija u OOP (recimo, u C#, Roslyn ima jako lep immutable API, dok recimo neki od js librarary imaju toliko los API da ti se "zgadi" immutable pristup, iako to nema veze sa patternom, nego sa losom imeplementacijom).

Sto se tice interfejsa, u nominalnom type sistemu, problem je kada definises da ocekujes odredjeni interface (contract) on mora biti tog tipa i samim tim imas manje fleksibilnosti po pitanju prosledjivanja vrednosti, dok u strukturalnom nemas ovo ogranicenje, jer ti nije bitno kako se zove interfejs, nego njegov oblik. E sad, naravno, to sto definises u nominalnom type sistem koji interfejs ocekujes i nije toliki problem (u smislu da mora biti bas taj), nego je problem, kada neko uzme i pocne da koristi "design patterne" i "best practices", tako sto za svaku, skoro svaku, stvar uzme i definise interfejs. To je silovanje type sistema. To u prevodu znaci, da ti imas bukvlano interface pa implementaciju, ne postoji na primer klasa koja nema bazni interfejs. Sve to ludilo dolazi od dependency injection patterna (i containera), ljudi su skontali da je savim cool da mozes da injectujes po potrebli sta ti treba, sto naravno nije lose, ali je lose da radis sa svim stvarima to (od recimo 100 klasa, ti recimo imas potrebu mozda za 5 klasa da budu injectovane, ali zasto da bude prosto kada moze da bude komplikovano, pa onda zarad onih 5% predizajniras celu aplikaciju i svuda gurnes interfejs). No da budem iskren, ovo ludlilo najvise sam vidjao u "enterprise" aplikacijima i firmama koje se oslanjaju na .NET I Java (nije ni cudo sto posle ljudi imaju averziju prema ovim tehnologijama kada od proste stvari namestis azdaju kojoj ne znas ni gde joj je pocetak ni kraj).
 
Odgovor na temu

Branimir Maksimovic
Senior Software Engineer

Član broj: 64947
Poruke: 5171
109.72.51.*



+1025 Profil

icon Re: Prelaz od C ka OO programiranju01.12.2018. u 11:10 - pre 27 meseci
"Sto se tice interfejsa, u nominalnom type sistemu, problem je kada definises da ocekujes odredjeni interface (contract) on mora biti tog tipa i samim tim imas manje fleksibilnosti po pitanju prosledjivanja vrednosti, dok u strukturalnom nemas ovo ogranicenje, jer ti nije bitno kako se zove interfejs, nego njegov oblik"

Nije mi jasno o cemu pricas. Moze neki primer?
press any key to continue or any other to quit....
 
Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8410
*.ptt.rs.



+2728 Profil

icon Re: Prelaz od C ka OO programiranju01.12.2018. u 12:02 - pre 27 meseci
@Branimir Maksimović


Pročitaj naslov teme. Kakvi crni funkcionalni jezici! Nemam ja ništa protiv njih, ali tema je OOP, a funkcionalna paradigma je off topic.

C# je fašistički jezik jer zabranjuje višestruko nasleđivanje klasa, već samo interfejsa. Isto važi za sve jezike koji uvode pojam interfejsa, koji je potpuno suvišan kada imaš višestruko nasleđivanje klasa.

Java je fašistički jezik uz dodatan razlog što nema prenošenje prostih tipova po referenci, a složenih po vrednosti i nema složene vrednosne tipove.

Python je fašistički jezik iz sličnog razloga. Ne da mi da biram šta de po vrednosti, a šta po referenci, nego moram da doproramiram kopiranje.

D je fašistički jezik jer su mu stringovi immutable i nema druge stringove koji bi bili mutable.


Kada jednom navikneš na C/C++ slobodu, ne želiš više nikada u konc-logor.
Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.
 
Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 893
*.dynamic.isp.telekom.rs.



+171 Profil

icon Re: Prelaz od C ka OO programiranju01.12.2018. u 12:29 - pre 27 meseci
Citat:
Branimir Maksimovic:
"Sto se tice interfejsa, u nominalnom type sistemu, problem je kada definises da ocekujes odredjeni interface (contract) on mora biti tog tipa i samim tim imas manje fleksibilnosti po pitanju prosledjivanja vrednosti, dok u strukturalnom nemas ovo ogranicenje, jer ti nije bitno kako se zove interfejs, nego njegov oblik"

Nije mi jasno o cemu pricas. Moze neki primer?


Moze, naravno, lakse je kroz primere.

Elem, recimo da imas neku funkciju koja prima interfejs, recimo ovako:

Code:

interface ISize 
{
   int x;
   int y;
   int width;
   int height;
}
void DrawRectangle(ISize size) { .. }


Da pozoves ovu f-ju iz nominalnog type sistema, imas dve opcije:

- da pronadjes ko implementira ovaj interface
- da sam implementiras interface

Kako god okrenes, neko mora da implementira interfejs jer tako je definisano kroz type sistem.

Ako pogledas strukturalni type sistem, onda nemas ovo ogranicenje, posto te ne zanima tacno da ispunis contract po imenu i obliku, nego samo po obliku. Drugim recima, mozes da konstruises "on the fly" interface i prolsedis, recimo:

Code:

DrawRectangle({
    x: 10,
    y: 10,
    width: 100,
    height: 50
})


Ovde u sustini koristis anoniman tip, ali to nije core feature, posto anonimne tipove imas i u nominalnim type sistemima, ali posto je tamo striktnije, ovo nece proci.

 
Odgovor na temu

[es] :: Art of Programming :: Prelaz od C ka OO programiranju

Strane: 1 2 3 4 5 6

[ Pregleda: 9576 | Odgovora: 101 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.