Prelaz od C ka OO programiranju

OK, dosta korisnih info i primera, ovo su stvari na koje bi trebali budući juniori i seniori da obrte pažnju, a ne samo da misle da je bitno naučiti što više sintakse nekog jezika i znati uraditi nekoliko šablonskih primera.
Poznavanje stvari kao što je ovo o čemu si pisao kod OOP čini tu bitnu razliku između običnog kucača koda i IT inženjera.

Potpis

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

Zapravo, ovakvi postovi su ono sto nam nedostaje. Svaka cast i hvala.

Potpis

THE ONLY EASY DAY WAS YESTERDAY

Samo da dodam jednu stvar, tj. ispravim sebe. U zadnjoj recenici u proslom postu sam rekao da bi mixini mogli kroz neki novi keyword da se implementiraju. To nije tacna definicija. Mixini bi i dalje imali ulogu, posto u dosta slucajeva zelimo on-the-fly da dodamo constraint na postojeci type, tako da cak i sa "deep implements" konstrukcijom ne bi iskljucili mixine iz upotrebe.

Razlika izmedju interfejsa i klase je u tome sto interfejs nema member varijable. Upravo zato i ne postoji problem kod visestrukog nasledjivanja jer nema duplih podobjekata baznih klasa. Prosto.
Osim toga interfejs ne mora biti vezan za klasu/tip uopste kao kod Rust-a i Go-a.

Mislis nema u nekim jezicima :)

I ono sto ne mogu da razumem vec u nekoliko tvojih postova - zasto je to u opste bitno?

Po meni samo dobijas manje fleksibilnosti. Mene kao programera zanima samo jedna, apsolutno jedna stvar kada treba da odlucim sta da uradim po pitanju nekog poziva - tip, oblik onoga sa cim baratam, pa sta god da je on ispod (struct, class, interface, trait)... iznedju ostalog ovo je i jedan od razloga zasto ne volim dinamicke jezike, jer moram da pretpostavljam sta je to sa cim baratam (moram test da pustim, da preturam po code-u) ne mogu da odlucim odmah u momentu dok pisem code.

U jeziku u kom se interfejs zove nesto sto ima member varijablu, klasa nema nikakvog smisla. Elem tamo gde se nasledjuje iz interfejsa kako bi se izbegao diamond inheritance problem sigurno nema member varijable u interfejsu.

Mismil da si ovde napravi pogresnu pretpsotavku.

Ovde se ne radi o zajednickoj funkcionalnosti. Interfejs sluzi tome da se moze komunicirati sa raznorosnim klasama. u ovom slucaju pranje osobe i pranje auta su potpuno razliciti procesi ali imaju istu svrhu.

Ne mozes da proces pranja rešiš osnovnoj klasi pa da je osoba i auto naslede jer se oni ne peru na isti način.

Uloga interfejsa je upravo u tome da on odredi da i osoba i auto znaju da se operu i spoljna klasa ce samo da im kaze da se operu ne ulazeci u to kako se to pranje zaista izvodi.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

Diamond problem - interfejsi, resenje za problem koji nikad niste imali :D

Nope, ponovicu ono sto je Nedeljko rekao, interface je specijalan slucaj klase, nista vise (trait u Rust-u, isto specijalan slucaj).

@Predrag

Slazem se da svako treba da ima svoju implementaciju, ali tamo gde treba. Tamo gde ne treba, dolazimo do redudancije:

primer:



Obe klase moraju isti code da implementiraju. Recimo da imas neku listu, kojoj hoces da prikazes persons i cars, treba ti opcija da mozes da mozes da chekiras item. Nema smisla ovo da se ponavlja (naravno, ovo je za neke stvari OK, za neke ne zelis da "gadis" tip, pa koristis mixine :)).

Jedna stvar je šta teorija OOP kaže o korišćenju interfejsa i klasa, ali to ne mora imati veze sa onim što su autori određenog jezika hteli da postignu.

Na primer, kod TypeScript-a korišćenje klase umesto interfejsa za type-checking rezultuje u prevođenju u JS ogromnom razlikom - kad se koristi klasa, dobije se gomila koda, a kad se koristi interfejs, ne dobije se ništa jer JS je loosely-typed jezik tako da je interfejs poslužio samo za proveru pri kompajliranju u JS.

Razlikuje se od jezika do jezika, tako da princip koji važi u jednom jeziku ne mora važiti u drugom. Inače bi postojalo nekoliko programskih jezika kao pre 40 godina.

Potpis

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

Pa ne moraju. Stavis jednu da implementira pa je stavis kao agregat u obe i u implementaciji samo delegiras. Tako mora u rastu jer nema clasa. U ostalim takodje zato sto nema visestrukog nasledjivanja.
Interfejs nije klasa, kao sto ni klasa nije specijalan slucaj strukture. A mozemo reci da je sve specijalni slucaj vartijable ako cemo da idemo dalje ;)

Klasa je korisnički (definisan) tip podatka, a interfejs ti se u nekim jezicima provlači kao tip podatka.

Dakle, možeš imati IButton interfejs i Button klasu koja implementira taj interfejs, ali ćeš onda negde u nekom kontruktoru, koristeći DI, imati slučaj da ti je parametar kontruktora podatak tipa IButton, a ne tipa Button. Dakle, u tom smislu, IButton je takođe korisnički tip podatka, pa se smatra klasom, a i kod nekih jezika se koristi "class" eventualno uz prefiks "interface" (npr. kod C#).

Razlika između obične klase i interfejsa je očigledna, ali mnogima nije tako očigledna razlika između apstraktne klase i interfejsa. Kod nekih jezika interfejs ne može sadržati atribute, pa se može koristiti apstraktna klasa. Inače, apstraktna klasa i služi isključivo da se na jednom mestu deklarišu/definišu zajednički atributi i metode za više klasa, dok sama klasa nikad neće biti instancirana (npr. klasa "Vehicle" nema potrebe da instancira objekte, jer za to koristimo izvedene klase "Car", "Truck", itd.).
Ili, u realnom primeru, imamo apstraktnu klasu "Document" iz koje su izvedene klase "Report" i sl.

Glavna prednost interfejsa je što može da se sakrije implementacija, ali kod nekih drugih jezika je to moglo da se uradi i drugačije - npr. kod C++ drugom članu tima date samo .hpp fajl gde je deklaracija klase i gde se vidi šta koja metoda radi i koje nazive i parametre ima, ali se ne vidi KAKO je implementirana), kao što je opisano ovde: https://stackoverflow.com/ques...ss-in-c-into-hpp-and-cpp-files

U nekim drugim jezicima, kao kod C#, interfejsi se koriste npr. za DI i tako injektovan interfejs tretira se kao "service" (bar je tako kod .Core 2 Web API), tako da tu nije moguće interfejs tek tako zameniti apstraktnom ili običnom klasom.

Potpis

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

"Klasa je korisnički (definisan) tip podatka, a interfejs ti se u nekim jezicima provlači kao tip podatka."

Pa i interfejs je korisnicki definisan tip podatka.

Razlika je u tome sto class-a moze imati i metode i atribute a interfejs samo metode, tako da nema problema da se visestruko nasledjuju.
To je ujedno i svrha postojanja interfejsa.

Izvinjavam se za taj drugi deo rečenice, izgleda da sam nešto menjao pa mi je ostao takav, sad pojma nemam šta sam hteo da kažem, verovatno da se u nekim jezicima i interfejs tretira kao korisnički tip podatka (kao što sam naveo za IButton).


Kod nekih jezika i interfejs klasa može sadržati atribute, tako da nije to suštinska razlika.
Suštinska razlika je za šta se koristi interfejs, a za šta klasa (i apstraktna klasa).

Međutim, ako sa C pređe na C++, to i neće biti baš tako očigledno. Ali kod novijih jezika, a posebno framework-a koji favorizuju određene paterne (kao Dependency Injection, koji se negde smatra tehnikom, modelom, a neki ga nazivaju pattern-om), interfejs često mora da se koristi da bi se nešto odradilo na određen način.

Sa druge strane, Typescript ima interfejs koji praktično služi samo za 'type checking'.

Potpis

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

Necu da delegiram ;)

Pa tako se upravo i radi, ako hoces bar malo redudanciju da smanjis ali kada ti jezik omogucava slobodu, onda imas jos manje posla (recimo, mogu da namestim mixin, i nemam onda nista da agregiram, samo definisem tip Checkable(Car) i imam isto to sa daleko elegantnijim code-om).

"Kod nekih jezika i interfejs klasa može sadržati atribute, tako da nije to suštinska razlika."

Ako si mislio na C# to su isto metodi. U svakom slucaju klasican naziv za interfejs zna se sta je.
Jezici koji klase nazivaju interfejs nisu relevantni.
C++ nema interfejsa zato sto podrzava visestruko nasledjivanje i oni ne bi imali svoju svrhu.

"recimo, mogu da namestim mixin,"

Na sta mislis kada kazes mixin? Jedino na sta me asocira je D jezik gde iz stringa generises kod.

Evo za typescript

Pa dobro, to je jedan nacin da napravis neku genericku implementaciju za postojece klase za taj jezik. U Rustu, recimo, mozes da genericki implementiras interfejs za sve strukture, potom da dodas default implementaciju
gde trazis da se implementira samo jedna on n metoda interfejsa, itd.
Ono sto sam napisao stoji u slucaju da nema drugog resenja.

Ja bih se bacio na C++ i osnove OOP-a. A posle toga imas veoma zanimljivu knjigu kao nastavak iz OO u dizajn paterne.
Cuvena knjiga Gang of Four Design Patterns: https://www.amazon.com/Design-...ofessional-ebook/dp/B000SEIBB8

Ako te mrzi da kupujes, mozes da je skines sa neta uz koji google-dork. Kucaj "GoF Design Patterns free pdf" i naci ces nesto.

EDIT:
O da i nemoj da zaboravis da pravis sopstvene projekte u kojima ces koristiti naucene stvari iznova i iznova i iznova.
To ti je najbolji nacin ucenja, posebno kada fejlujes 100 puta na tebi tesko shvatljivim stvarima pre nego sto dodjes do tacnog resenja a onda bacis sve cetri uvis, malo se odmoris i nastavis dalje sa malo vecim samopouzdanjem i osmehom na licu :D

Pattern-e da uči tek na kraju, ne na početku. I pre toga dobro da nauči UML, nije pod obavezno, ali je korisno.

Ovako, može da nauči napamet šta je Factory i čemu služi, a da u praksi nikad ne prepozna gde treba da ga primeni, a gde je njegova primena suvišna.

Potpis

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

Svakako. Dobar redosled je takodje bitan.


A takodje, moze da mu se desi i da sam dodje do tog (ili nekog drugog pattern-a) bez da je ucio o njemu. Ja sam imao situaciju da sam, kada sam saznao za design pattern-e i video neke primere, prepoznao dosta stvari koje sam vec radio na taj nacin pri cemu je meni je jednostavno bilo resenje nekih problema, nisam na to gledao kao na nesto standardizovano :)

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