Nasledjivanje samo izmedju interfejsa

Razmisljao sam nesto, ako bi imali jezik u kojem nije moguce imati nasledjivanje kao relaciju izmedju klasa. Nego samo izmedju interfejsa.
Cini mi se da bi time bilo koji framework bio dosta primoran da se pise na nacin da je mnogo fleksibilniji, agilniji, laksi za testiranje.

Interesuju me vasa misljenja o mogucim ogranicenjima, problemima koji se mogu javiti...

Ne vidim kako bi bio agilniji, sem ako posmatras samo hriznotalnu separaciju na potpuno razlicite funkcionalnosti. Uzmi scenario da imas recimo baznu klasu koja servira osnovno procesiranje za 10 difereciranih pod klasa, i imas zahtev da preomenis odredjeno ponasanje tih 10 klasa na osnovu tih zajednickih oepracija. U OOP menjas samo baznu kalsu u tvom scenariju moras da promenis svih 10 klasa. Nista ne fali OOPu za reusability, problem je sto ljudi preteruju sa time.

Potpis

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Ne bi morao u ovom slucaju sto sam ja predlozio da menjas svih 10 klasa. Nego bi imao dependancy na tu osnovnu klasu u svakoj i onda bi samo opet trebao da promenis samo tu klasu koja je kompozicija u svih 10.

Znam da ne fali, tj da moze da se sve to realizuje i kroz trenutni OOP, ali bi ovako ljude primorao boljem dizajnu, tj kad kazem bolji mislim fleksibilniji i pogodniji za testiranje i odrzavanje.

Pa to ti se svodi na isto, zar ne.

Po definicij "potpis" klase je njen implicitni interfejs, nasledjivanje nije nista drugo do implicitne kompozije nad baznom klasom (tvoja i bazna kalsa dele "this", ali svaka ima svoj deo v-table i metod koji nije overriden se poziva direktno u baznoj klasi). U osnovi morao bi rucno da radis sve stvari koje ti implicitno omogucava nasledjivanje, tj morao bi da za svaku subklasu implementiras identican ili uvecan interfejs gde bi vecina metoda bilo nista drugo do poziv u denendency base.

Ne znam, mozda ja ne vidim iz tvog ugla zasto je nasledjivanje nefleksibilno i tesko za testiranje i odrzavanje? Naravno, opet se ogradjujem, kad se ne preteruje (mada mozes da preteras i sa interfejsima i kompozicijom ) Ili je rezon da je simuliranje nasledjivanje kroz kompoziciju pain pa ce te to naterati da pises manje klase

Potpis

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Da, ovo sam i ja skontao da bi bio problem, tj bilo bi dosta nepotrebnog pisanja trivijalne implementacije.



Ja sam evo na primer to uocio kod primene Dependancy Injection paterna, ili kod MVP paterna. Cesto se desava da GUI jednostavno nije implementiran tako da koristi interfejse i onda se mora raditi wrap oko postojece implementacije koja ce usput da implementira neki interfejs koji ces ti koristiti u definiciji view interfejsa. Naravno, ovo se moglo uraditi i sa trenutnim jezicima, ali nije jer niko ne primorava interfejse pa mogu da se i izbegnu. U slucaju gde nema hijerarhije izmedju klasa svaka klasa bi imala neki interfejs ili vise njih koje je implementirala.

Postoje takvi jezici. Od popularnih, npr VB6, ili Googleov novi jezik Go.

Potpis

IOCC

Sto rece mmix, problem je sa ljudima, i iz mog iskustva mogu ti reci da je apsolutno u pravu - itekako je problem sa ljudima. Mislim da sam ja bas pre jedno dve, tri godine imao taj problem sto nisam mogao da svarim interfejse. Secam se da sam i jednu temu otvorio ovde.

Elem, problem sa interfejsima je sto ljudi preteruju, recimo ja licno smatram da se interfejs ne treba nikad ni definisati dok god ti se ne ukaze potreba za istom funkcionalnosti (tacnije, fasadom funkcionalnosti :)) na jos jednom mestu. Inace, mislim da su interfejsi totalno zlo, ne vidim zasto se ne bi se sve resilo kroz klase. Sa interfjesima samo se povecava code jer ces uvek morati da pises implementaciju tamo gde koristis interfejs.

negyxo, grešiš

Sad, kad bi rekao i sta gresim... bas nisi mogao manje reci da napises :-)

Dobri su interfejsi. Koristim ih u C# i pomažu mi da pravilnije razmišljam kad razmišljam o tome kako da rešim problem.

Ako mene pitas, interfejsi su dobri taman za toliko koliko je C# osakacen. Posto nema visesturkog nasledjivanja izmedju kalasa ti si prisiljen da koristis interfejse, iz tog razloga interfejsi jesu korisni, kako bi imao bar kakav takav objektno orijentisan code, ali kao sto rekoh, sve je to posledica osakacenosti jednog jezika.

Koristim ja i C++, i to mi je prvi, da kažem, produkcioni jezik. Nikad u svom radu nije mi se ukazala potreba za višestrukim nasleđivanjem, a kad sam i imao višestruko nasleđivanje u kodu, to je zapravo bilo nasleđivanje apstraktnih klasa (to jest interfejsa).

Vidis, ako pises sto kompozitniji code, a da je pritom objektno orijentisan, potreba za visestrukim nasledjivanjem ima. Ono sto je problem kada poredis C++ i C# nije u njihovim feature-ima nego u upotrebi, C++ ce vise radi za sistemsko prgramiranje, dok C# uglvnom za neke business aplikacije, bas zbog toga se onda i stvara drukcija potreba izmedju koriscenja nekih feature.

Ja sam recimo milion puta morao da koristim INotifyPropertyChanged interfejs, i milion puta sam morao da pisem uvek istu implementaciju, iako trivijalna, morao sam da je napisem. Smatram da ko god se bavi programiranjem i radi copy-paste metodu za resavanje problema, taj il' je pocetnik ili mu mesto nije u programiranju.

Meni je u trenutnom C++ projektu zatrebalo višestruko nasleđivanje i mogao sam da se slikam sa tom mogućnošću C++ jezika zato što bibliotečka klasa nije izvedena virtuelno iz svoje osnovne klase, pa sam problem morao da rešavam na sasvim drugačiji način.

Potpis

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

Kako bi visestruko nasledjivanje pomoglo kod koriscenja INotifyPropertyChanged?

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

Manje bi pisao code. Ajde, da ne ispadne samo da sam zapeo za taj intefejs, posto je prilicno prost, ali uzmi bilo koji drugi i videces ako ti treba na vise mesta ista implementacija cista je ludost to kopirati i stalno pisati iznova.

Elem, a propo INotifProertyChanged interfejsa



Evo, Class1 i Class2 imaju identicne implementacije za PropertyChanged, mi po nekom standaradu za svaki event dodamo metod On_EventName_(). Da kojim slucajem postoji visestruko nasledjivanje, sve sto bi napisao je:




No, ovo je samo jedan interfejs, koji je prost, za iole kompleksnije stvari ovo je jos grdje.

Za to ti služi pretprocesor.

Potpis

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

@negyxo, napravis klasu koja implementira interfejs pa te dve BaseClass1 i 2 nasledis iz nje pa ove dve iz BaseClass. Mada, ok, ima situacija kada bi ovo moglo biti nezgodnije nego u tvom primeru.

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

Pa u tome je i fora, sto ne mozes uvek da implementiras u baznu klasu, nego vec imas koju moras da nasledis.

Nedeljko, moze mali primer na sta mislis.

Nisam siguran da li sam pomešao C++ i C# sintaksu, ali na ovo sam mislio.

Potpis

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