Ja prezivljavam i bez njega, ali mislim da ne bi skodilo da postoji.

Možda ne bi bilo loše da je omogućeno, pa ko voli - nek' izvoli.

mislim da to krsi neke koncepte objektnog programiranja. skoro sam procitao u nekom pc presu, mogu da pronadjem u kom, ako je bas frka...

inace radim javu, pored .net-a, koja podrzava interfejse, pa ako hocces da visestruko nasledjujes dodajes interfejse.

da li postoji nesto slicno u .net-u? mislim na interfejse (java interfejsi mogu da nasledjuju klasu, ali u njima ne mogu biti definisane metode...)

Jel Vi kazete da ovo ne moze???

class FirstClass {...};
class SecondClass {...};
class ThirdClass {...};

class LastClass : public FirsClass,
public SecondClass,
public ThirdClass {
......
};


Nisam siguran da ne moze !??!

@DarkoR:
Can you inherit from multiple classes in C#? Simply put, this cannot be done. However there are ways around it.

@bunker:
From a design perspective we must choose a different design. C# supports what is called "Multiple Implementation", which is to says a class can implement more than one interface.

U svojoj profesionalnoj praksi (cca 9 godina) sam samo jednom upotrebio višestruko nasleđivanje (ne računajući višestruko nasleđivanje iz apstaktnih klasa, što odgovara Java/C# interfejsima), ali je tada to zaista bilo sa dobrim razlogom. Inače, mnoge C++ biblioteke (ATL, WTL) interno koriste višestruko nasleđivanje pa sam ga "indirektno" koristio više puta.

Odgovor je dakle: svakako treba da postoji, što ne znači da bih ga često koristio.

[Ovu poruku je menjao Dragi Tata dana 02.06.2003. u 10:53 GMT]

U principu ljudi koji rade u nekom jeziku koji nema neku mogućnost, dokazuju kako je ta mogućnost ne samo nepotrebna, već i štetna. Tako si u mnogim tekstovima o VB 6 programiranju mogao da čitaš zašto je nasleđivanje loša stvar. Naravno, kad su u VB.NET dodali nasleđivanje, cela priča je prestala. Sindrom kiselog grožđa :)



Interfejsi su samo u specijalnom slučaju zamena za višestruko nasleđivanje.



Ne da je slično, nego skoro isto (kao i mnogo šta drugo :) )

To što si napisao je standardni C++, i tu naravno može. Međutim, u .NET okruženju ne može.

Postavljam pitanje zato sto imam jedan konkretan problem: Radim neki program sa dosta UIa, i to vrlo specificnog UIa: prakticno svaki UI element (edit box, button, itd) treba da se overloaduje i napravi specificna verzija. Ok nema problema, to barem nije tesko uraditi. Onda se poslodavac seti kako bi bilo lepo da ENTER moze da se koristi kao TAB. Ok nema problema, sada cu ja da overrideujem PreProcessMessage i eto toga. Medjutim, nastupa problem. Ja sada treba taj kod za taj override da copy&paste-ujem u svaku kontrolu koju sam overrideovao (ima ih desetak). Nedelju dana kasnije, odluci se da background color disabled kontrola treba da bude tamno plav - nema problema, sad cu ja za cas da overrideujem BackColor i ForeColor. Ups, eto jos jednog copy&paste-a. Onda smo dosli do toga da bi bilo jako lepo kada bi svaka kontrola imala specijalan bool IsValid() metod (sa istom implementacijom return true; za pola kontrola), tako da ajde i to da copy&pasteujemo svuda. .... itd.

Jedino sto pomaze je #region u C#u. Da nije toga, kod bi izgledao mnogo gore :D

čekaj be reljam.. zar nije bilo lakše da nasledite neku generalnu UI klasu (apstraktnu po mogućstvu) ako ste već počeli da radite specijalizovani UI.. to mi prvo pada na pamet.. posle bi ste sve te zajebancije implementirali u vašu osnovnu klasu.. zato služi OOP ;)

dalje, mislim da postoji i drugo rešenje za tvoj prob, ali ček prvo da odgovorim nemanji ;)


dakle, mogu se složiti da MI može nekome da koristi, ali mogu i tvrditi da se sve može uraditi i bez njega ;) (svaki turing-complete jezik može...) ali neću.. pošto si poznat po flejmu ;) (nazivaš nas ovcama... c c c..)

pitanje je da li postojanje i potreba za MI opravdava moguću zbrku koju može da proizvede.. sam kažeš da si ceo jedan put koristio to direktno.. a što se indirektnog koršćenja, moraš se složiti da su vekotori i slične klase sigurno mogle da budu implementirane i bez istog ;)


elem, u javi (a sigurno i u c#, mada nisam dotle stigao ;) postoji jedna fina opcija koja je po meni u kombinaciji sa interfejsima vrlo adekvatna zamena za MI. to su tzv inner klase.. (delphi ima nešto slično, gde property može da implementira intefejs, a da nasledi klasu, ali to je druga priča..)

elem, da ne dužim, neću da učim nikog inner klasama, ali reljam, ako me razumeš, možeš da imaš inner klasu koja implementira neki od interfejsa, a usput i nasleđuje neku drugu klasu (a samim tim i preuzima zahtevano ponašanje nasleđeno iz te klase..). mislim da bi to moglo da ti reši prob..

Otvoren sam za sugestije, ja nisam mogao da se setim boljeg resenja. Problem je u tome sto bih ja hteo da umesto sto uradim:

... -> Control -> Button -> MyButton

da uradim

... -> MyControl -> Button (i opcionalno MyButton, ako je potrebno).

To trenutno ne moze da se uradi u C#u (ili ja ne znam kako). Postoje varijante preko MIa koje bi to uradile. Ima i varijanta sa jednom klasom koja odradjuje veliki deo funkcionalnosti pa onda iz stubova u toj gomili klasa pozivas metode iz te glavne klase, ali vecina ovih funkcija su ili one-lineri ili se zasnivaju na nekim static-ima iz tih klasa tako da ni to bas ne radi.

Nezgodno.

Postoji vise od jednog nacina na koji moze da se uradi MI. Da bi se izbegao problem sa visestrukim putanjama do roota (object), moze se uvesti koncept primary inheritance chaina - znaci MyButton je izveden iz Buttona kao primary chain, a iz recimo myControl kao secondary. Tako da ne moram da eksplicitno kastujem kasnije. U svakom slucaju ima vise od jednog nacina da se uradi MI.

Zombie, nisam siguran da te inner klase rade to sto ti kazes, ili barem ne u .NETu. Daj jos malo informacija ako mozes.

Naravno da može. Može i bez jednostrukog nasleđivanja. Može i bez funkcija, u čistom asembleru. To međutim ne znači da je MI nepotreban, opasan, itd. Postoje situacije, kada je logičnije, čitljivije i elegantnije koristiti MI. Ako imaš klasu pauk sa funkcijom pleteMrezu i klasu covek sa funkcijom hoda, vrlo je logično da klasa spiderman bude izvedena iz obe pomenute klase. Može i drugačije, ali je ovako logično i čitljivo.



Nema ih u C#-u i nisu adekvatna zamena za MI. MI jasno odražava programerovu ideju: klasa C izvedena iz klasa A i B je istovremeno i A i B (spajdermen).

(uz napomenu da možda nisam razumeo šta tačno misliš)

Radi se o tome da reljam ne radi specijalizovani UI od nule, nego bi da nasledi npr. gotovu klasu Windows.Forms.Textbox i još nešto pride, pa Windows.Forms.Button i opet ono pride.. Dakle, ako sam dobro razumeo relju, on bi da zajednicku funkcionalnost ovih klasa izdvoji u posebnu klasu i onda nasledi iz nje plus da nasledi potrebnu klasu iz windows.forms.

Kako smo se (skoro) složili, bilo bi dobro da je MI na raspolaganju, a niko te ne tera da koristiš isto.

nemanja, što volim ovakva poređenja ;)

ajde baš da pogledamo spajdermena.. da li je spajdermen čovek ili pauk. ti bi rekao i jedno i drugo. ja bi rekao, ni jedno ni drugo. (zavisi gde postaviš granicu ;)

da li on jede kao pauk. da li hoda kao pauk. da li izgleda kao pauk.. ne, on samo ima neke (ili većinu -- sve) elemente ponašanja pauka. isto tako i za njegovu čovečnu stranu ;)

dakle, on spolja izgleda (ne fizički, već po ponašanju) kao I čovek I pauk. e tu je razlika. to kako on spolja izgleda (po ponašanju) definiše njegov Interfejs prema okolini..

znači, ne možeš naslediti pauka, jel metoda Pauk.Jedi(), ili Pauk.Hodaj(), ili ... se ne može primeniti..


heh.. rekoh da volim ovakva poređenja.. prava gimnastika za mozak ;)




nažalost, ako ih nema u c#, glupo je da raspravljamo o teme..

Dobro zombie, ovo si lukavo izveo, ali pretpostavimo da ipak postoji klasa covek koja ima samo funkciju hoda() i klasa pauk koja ima samo funkciju pleteMrezu(), a tebi treba klasa spiderman koja ima tacno te dve funkcije (i možda jos neku pride, ali to je nebitno). Koji je najlakši, najlogičniji i najčitljiviji (obrati pažnju da ne kažem "jedini mogući") način da se to odradi?

Najčitljivije je onda da napišeš novu spiderman klasu sa hoda() i pleteMrežu() i zaboraviš na nasleđivanje. :)

Inače, svaka čast za spiderman primer, baš je "plastično".

Aha, Gojko, i kad trebam klasu spiderwoman onda sve pišem ponovo, je li? :)

Ili ako treba da izmenim metod pleteMrezu() onda moram na dva mesta (spiderman, spiderwoman) to da radim, umesto na jednom (spider)?

Ipak, nije to poenta ove rasprave: čak i da je višestruko nasleđivanje omogućeno ništa te ne bi spečavalo da uradiš kako ti hoćeš - sa ili bez, izbor bi bio samo do tebe.

[Ovu poruku je menjao degojs dana 04.06.2003. u 10:34 GMT]

Ovaj, a kakve bi jos to metode spiderwomen trebalo da ima?...

Aj, posto je ovo anketa, da odgovorim.
Do sad mi nije bilo potrebno ali bi bilo bolje da postoji (svaka dodatna mogucnost je dobrodosla).

Svašta, govorimo generalno, a spiderman i spiderwoman su samo primer.
Recimo da praviš igricu i znaš ono izabereš npr. spiderman pa igraš igru, a možeš da izabereš i spiderwoman pa igraš igru sa tim likom.. njihove mogućnosti bi bile malo drugačije itd, itd. Pri čemu bi recimo spider mogućnosti bile iste, ali man vs woman različite itd itd...

Šalim se ja, super je nasleđivanje i nemam ništa protiv njega. A spiderwomen možeš da naslediš od spiderman-a i dodaš polje žensko=true. :)

Ma kontam, bre... zezam se... ;)

A usput moraš da promeniš i AI za ženski lik - dodavanjem gomile grananja u zavisnosti od dobivenog slučajnog broja.

e da.. setih se.. zašto je MI neprirodno.. i još jedan razlog zašto primer ne valja:

pojam višestrukog nasleđivanja ne postoji u prirodi ;) znači, nema spajdermena, nema spajderwomena, i sličnih stvari..

geneologija ne poznaje mutante ;). znači, ne postoje bića koja su istovremeno i insekt, i sisar, ili ptica i sisar ili slično ;). nasleđivanje je samo jednu stranu ;)

(dobro, mutanti iako se ponekad pojave, obično su retki, kratkog veka i smatraju se greškama prirode ;)))


ali zato priroda poznaje interfejse. slepi miš je u stvari sisar, ali ima mogućnost letenja, znači izgleda i leti kao ptica ;))

A šta velite za klasu iostream iz standardne C++ biblioteke?

http://www.cplusplus.com/ref/iostream/iostream/

Ona je istovremeno i istream i ostream, pa je (vrlo logično) izvedena iz obe pomenute klase. Ili možda Bjarne nije znao šta radi?

Bjarne nije znao šta radi!


;)

Evo interesantnog dodatka. Koristeci Visual UML 3.10 modelujem visestruko nasledjivanje i odaberem za jezik C#. Po exportu koda dobijam:

public class SampleChildClass : Parent1, Parent2, Parent3
{
...
}

Ko kaze da nema?

Evo ja kazem da Visual UML 3.10 ne konta C# bas najbolje :D. To su interfejsi, nisu klase.

Osim sto ja nisam modelovao entitete kao interfejse nego klase...

Pa da, ne konta :-)

Pa da ste malo vise citali OOP-u znali bi ste cemu sluzi visestruko nasledjivanje a ne ste se raspisali odje. Samo cu vas pitat sledece: sto su bazne virtualne klase i cemu sluze... ako znate odgovor znate i svrhu visestrukog nasledjivanja, ako neznate to vam je znak da uzmete knjigu u sake i pocnete da citate, bez polimorfizma i virtualnih klasa niste objektno orjentisani vec objektno "bazirani" programeri :)

naravno ovo se tice C++-a a ne c#-a

Evo, ja ne znam šta su to "bazne virtualne klase". Da li bi nam objasnio?

dragiTata :) ako stvarno nemas knjigu o OOP-u evo cu ti ja objasnit ukratko, a ti potrazi detaljnije na netu.

Prvo zamisli da imas baznu klasu (primjer iz moje zadnje igrice) DirectX (koja implementira dalje directDrow, direct3d... nebitno). E tu klasu DirectX treba da naslijede klase avion, auto, teren, oruzja... a njih treba da naslijedi klasa igra. Da se ne bi klasa DirectX instancirala vise puta veze potomaka klase DirectX se deklarisu kao virtualne (run time linking... to ne treba valjda objasnjavati). evo i primjer i iste igre:



poslao bi vam diagram za jasniju sliku, a mozete ovaj kod inportovati u RationalRose i uraditi inverzan izenjering ko hoce da vidi jasnije... dosta od mene...

Baš kao što sam i mislio - reč je o virtuelnom nasleđivanju i virtuelnim baznim klasama, a "bazne virtuelne klase" jednostavno ne postoje. Više o tome na

http://www.parashift.com/c++-faq-lite/multiple-inheritance.html

Uzgred, potcenjivački ton tvojih poruka nikako nije u skladu sa duhom ovog foruma i predlažem ti da to izmeniš. Hvala.