Prelaz od C ka OO programiranju

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.

Potpis

I saw a USO last night.

Mozda sam zaboravio za debagera za PHP. Ono sto bih savetovao pocetnicima je samo paljenje error reportinga, bice sasvim dovoljno za pocetak.

Potpis

THE ONLY EASY DAY WAS YESTERDAY

okay imacu to u vidu. poslao sam ti sliku dokaz da sam pribavio tesku artiljeriju jer sam stekao utisak da mislis da te foliram.

Potpis

I saw a USO last night.

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

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

u redu ubedili ste me vracam se PHP odmah.

Potpis

I saw a USO last night.

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.

Potpis

Blessed are those who can laugh at themselves, for they shall never cease to be amused.

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.

@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.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

@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.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

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

Upropastiste coveka

Potpis

Nebojsa Milanovic:
-Trumpa smatram vrhunskim predsednikom i voleo bih da živim u državi na čijem je on čelu
-Rusija ne laže, ne vodi osvajačke ratove
-Trump je svetla tačka u USA blatu
-Elon Musk, možda najpametniji i najtrezveniji Amerikanac

To ti je ono put oko sveta programskih jezika za 10 dana ;)

Skoro pa prvi komentar :D




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).

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?

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

Potpis

I saw a USO last night.

Slobodno postavljaj pitanja o C++-u na forumu ;)

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).

"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?

@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.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Moze, naravno, lakse je kroz primere.

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



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:



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.