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: 9581 | Odgovora: 101 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

negyxo
Aleksandar Perkuchin

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



+171 Profil

icon Re: Prelaz od C ka OO programiranju02.12.2018. u 19:43 - pre 27 meseci
@Predrag

Upadas u "zamku" kao pre par godina kada smo diskutovali o interfejsima. Nije potrebno da diskutujemo o tome kako se interfejsi pravilno koriste, taj deo je jasan, ono sto izgleda nije jasno je kada se interfejsi svuda koriste da bi ti ceo code bio "decoupled", da bi ispunio neki design pattern. Sad, nema smisla da ti odgovaram na svaku recenicu, ako pokusas da razumes ovu prethodnu recenicu onda ce ti biti jasno zasto.
 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 5957

Sajt: pedja.supurovic.net


+1446 Profil

icon Re: Prelaz od C ka OO programiranju02.12.2018. u 20:52 - pre 27 meseci
Ok ali ako ti pišeš kod onda valjda ti o tome odlučuješ i ne može ti programski jezik biti fašistički zbog toga što ima interfejse. Kako ćeš da ih koristiš to je tvoja stvar.

Što više slobode jezik daje to više "sra*a" mogu da se mašravi u njemu.


 
Odgovor na temu

negyxo
Aleksandar Perkuchin

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



+171 Profil

icon Re: Prelaz od C ka OO programiranju02.12.2018. u 23:07 - pre 27 meseci
Prvo, nisam ja pisao o tome sta je fasisticki a sta ne, dao sam samo svoj komentar po pitanju interfejsa i njihovo koriscenje.

Drugo, ja koristim interfejse na isti nacin kao sto si i sam opisao, i nemam problem sa zloupotrebom... ali, sta mislis sta se desi kada nisi ti vlasnik projekta, ne odlucujes ti sta ces pisati, ne radis samo ti, nego 10 programera i code nije trivijlan od par desetina fajlova? Jel sad mozes da zamislis situaciju zasto je bolno kada sve po automatizmi pokusvas da "decoupled-ujes"?

Trece, ne slazem se oko slobode - treba da je ima sto vise i da je jasno definisana. Ono sto "ti" kao programer treba da radis je da pises sto striktnije a ne jezik da bude striktniji, da te ogranicava u opsiu problema. Sad, ovo je jako tesko definisati da budem iskren. Neke slobode su jednostavno destruktivne (recimo promena vrednosti promenljivi, sad je malo integer, pa je malo string, pa je malo datetime itd), no u duhu slobode, treba ostaviti svakom izbor da ima nacin da podesi sta mu odgovara i to je to.
 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 5957

Sajt: pedja.supurovic.net


+1446 Profil

icon Re: Prelaz od C ka OO programiranju03.12.2018. u 06:48 - pre 27 meseci
Citat:
negyxo: Prvo, nisam ja pisao o tome sta je fasisticki a sta ne, dao sam samo svoj komentar po pitanju interfejsa i njihovo koriscenje.


nisam ni miilsio na tebe, nego na taj pristup. Izvini ako nisam bio jasan.

Citat:

Drugo, ja koristim interfejse na isti nacin kao sto si i sam opisao, i nemam problem sa zloupotrebom... ali, sta mislis sta se desi kada nisi ti vlasnik projekta, ne odlucujes ti sta ces pisati, ne radis samo ti, nego 10 programera i code nije trivijlan od par desetina fajlova? Jel sad mozes da zamislis situaciju zasto je bolno kada sve po automatizmi pokusvas da "decoupled-ujes"?


Siguran sam da se svaki dugogodišnji programer sretao sa takvim stvarima, ali ne mislim da za to treba kriviti jezik nego onog ko je tako nešto napravio.

Na primer, mnogo ćeš pre nailaziti na gomilu svinjarija u jezicima koji dozvo9ljavaju "on the fly" kreiranje struktura, funkcija, ili čega već, nego u nekom jeziku koji ima interfejse. Pogledaj na primer JavaScript. Od ionako ružnog jezika napravili su papazjaniju upravo takvim pristupom.

Citat:

Trece, ne slazem se oko slobode - treba da je ima sto vise i da je jasno definisana. Ono sto "ti" kao programer treba da radis je da pises sto striktnije a ne jezik da bude striktniji, da te ogranicava u opsiu problema. Sad, ovo je jako tesko definisati da budem iskren. Neke slobode su jednostavno destruktivne (recimo promena vrednosti promenljivi, sad je malo integer, pa je malo string, pa je malo datetime itd), no u duhu slobode, treba ostaviti svakom izbor da ima nacin da podesi sta mu odgovara i to je to.


I ja se slažem da treba imati što više slobode, nego sam rekao da to nije garancija da će loši programeri pravili bolji kod nego najverovatnije baš obrnuto.

Kao i u mnogim drugim stvarima, veća sloboda teba onima koji znaju. Oni koji ne znaju je bolej da imaju u nekim stvariam vezane ruke da ne bi pravili budalaštine - dok ne nauče.

 
Odgovor na temu

negyxo
Aleksandar Perkuchin

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



+171 Profil

icon Re: Prelaz od C ka OO programiranju03.12.2018. u 07:46 - pre 27 meseci
Citat:

Siguran sam da se svaki dugogodišnji programer sretao sa takvim stvarima, ali ne mislim da za to treba kriviti jezik nego onog ko je tako nešto napravio.


Slazem se sa ovim kada se kaze uopsteno, to je jednostavno tako i da kazemo "normalno" stanje. No, kada govorimo o konkretnom slucaju, onda mozemo da uputimo i kritiku (sad da li je objektivna ili ne, to je sad vec u oko posmatraca :))

U slucaju interfejsa, bar za C#, ja mogu da kazem da su bespotreban konstrukt. Ne, ne njihovo koriscenje, nego konstrukt. Drugim recima, sve to mozes i sa klasama osim u jednoj stvari - a to je visestruko nasledjivanje. To je vestacki nametnuto, i ne mozes da promenis, i onda te jezik tera da koristis nesto jer nemas drugu opciju. Sad ti ces mozda reci da nemas potrebe sa visestrukim nasledjivanjem, ali to bas nije istina. Pogledaj kod sebe u code-u i pogledaj da li imas vise od jednog interface-a implementiranog u jednoj klasi. Posto si spominjao IEnumerable onda ti je poznat List<T>, kako izgleda ta klasa?

Code:

public class List<T> : IList<T>, ICollection<T>, IEnumerable<T>, IEnumerable, IList, ICollection, IReadOnlyList<T>, IReadOnlyCollection<T>


Zatim, pogledaj sledeci feature (bar je bio u najavi), default interface implementation. Pa kako je sada odjednom OK da imamo implementaciju u interfejsu? Ne, nikakva magicna igra reci ("znas, to je default metod") nece promeniti cinjenicu da ces sada da dobijes frankestajna samo zato sto nisi na prvom mestu odmah podrzao visestruko nasledjivanje. Bice interesatno sada kada pokusas da objasnis pocetnicima zasto da koriste interfejs sa default impelementacijom umesto klase :)

I da, sa ovim moze da se zivi, i kao sto rekoh negde ranije, meni je ovo manji problem nego non-null referentni tipovi.
 
Odgovor na temu

negyxo
Aleksandar Perkuchin

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



+171 Profil

icon Re: Prelaz od C ka OO programiranju03.12.2018. u 07:59 - pre 27 meseci
Citat:
Predrag Supurovic:
Na primer, mnogo ćeš pre nailaziti na gomilu svinjarija u jezicima koji dozvo9ljavaju "on the fly" kreiranje struktura, funkcija, ili čega već, nego u nekom jeziku koji ima interfejse. Pogledaj na primer JavaScript. Od ionako ružnog jezika napravili su papazjaniju upravo takvim pristupom.



Hehe, na ovo moram da odgovorim. Cak sta vise slazem se 100%, ali nisu svi jezici isti po tom pitanju, pa tako iako deluje isto, razlika je prilicno velika (probaj TypeScript, prijatno ces se iznenaditi).
 
Odgovor na temu

Shadowed
Vojvodina

Član broj: 649
Poruke: 12705



+4688 Profil

icon Re: Prelaz od C ka OO programiranju03.12.2018. u 09:44 - pre 27 meseci
Opet moram da izigravam drvenog advokata :))
Posto vidim da se ne kapirate...

Negyxo je jednostavnim primerom prikazao forsiranje interfejsa. Ocigledno je da tu nije potreban interfejs. Dovoljno funkcija trazi ili 4 parametra ili klasu/strukturu koja ih sadrzi. Ovakvo guranje interfejsa da bi se zadovoljio neki pattern ili "da bi bilo `aligned` sa ostatkom projekta" je primer cestih overarchitectured situacija sa projektima koje se srecu u enterprise aplikacijama. Ja sam se takvih stvari nagledao. Doduse, ne toliko ovih sa interfejsima ali to je samo jedan primer.

Razlog zasto je dao taj primer je navodjenje kako Go i Rust nemaju klase nego sve rade preko interfejsa (ne znam da li je tako, nisam ih koristio, ali je tako receno prethodno). To bi znacilo da ne samo da ces moci da imas situaciju kada se nepotrebno forsiraju interfejsi (kao u datom primeru) vec ce to u tim jezicima biti garantovano.


Bar sam ja tako razumeo.
 
Odgovor na temu

Branimir Maksimovic
Senior Software Engineer

Član broj: 64947
Poruke: 5175
82.117.201.*



+1025 Profil

icon Re: Prelaz od C ka OO programiranju03.12.2018. u 09:53 - pre 27 meseci
Go i Rust ne vezuju implementaciju interfejsa za strukturu. Znaci mozes implementacije razlicitih intefejsa staviti u razlicite fajlove a same
strukture takodje nemaju nikakve veze sa interfejsima...
press any key to continue or any other to quit....
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4541



+709 Profil

icon Re: Prelaz od C ka OO programiranju03.12.2018. u 10:28 - pre 27 meseci
Citat:
negyxo:
U slucaju interfejsa, bar za C#, ja mogu da kazem da su bespotreban konstrukt.


Samo ću ostaviti ovo ovde... :D

https://stackoverflow.com/ques...dant-with-multiple-inheritance
 
Odgovor na temu

Branimir Maksimovic
Senior Software Engineer

Član broj: 64947
Poruke: 5175
82.117.201.*



+1025 Profil

icon Re: Prelaz od C ka OO programiranju03.12.2018. u 10:35 - pre 27 meseci
Samo da dodam u Go i Rust-u interfejsi nisu nasledjivanje a samim tim nikakva multiple inheritance nije u pitanju. Interface je prosto protokol i nista vise.
Moze se implementirati interface kako za strukturu tako i za proste tipove.
press any key to continue or any other to quit....
 
Odgovor na temu

negyxo
Aleksandar Perkuchin

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



+171 Profil

icon Re: Prelaz od C ka OO programiranju03.12.2018. u 11:15 - pre 27 meseci
@jablan

Citat:

That said, I'm quite happy with single inheritance most of the time. Eric Lippert makes the point earlier in the same volume (p. 10) that the choice of single inheritance "... eliminates in one stroke many of the complicated corner cases..."


Haha, dobio si odmah odogovor sa "...ali I am quite happy" :D

Interesantno je da jedan broj koji se javio nije razumeo tvoje pitanje.
 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 5957

Sajt: pedja.supurovic.net


+1446 Profil

icon Re: Prelaz od C ka OO programiranju03.12.2018. u 21:28 - pre 27 meseci
Citat:
negyxo:
U slucaju interfejsa, bar za C#, ja mogu da kazem da su bespotreban konstrukt. Ne, ne njihovo koriscenje, nego konstrukt. Drugim recima, sve to mozes i sa klasama osim u jednoj stvari - a to je visestruko nasledjivanje. To je vestacki nametnuto, i ne mozes da promenis, i onda te jezik tera da koristis nesto jer nemas drugu opciju. Sad ti ces mozda reci da nemas potrebe sa visestrukim nasledjivanjem, ali to bas nije istina. Pogledaj kod sebe u code-u i pogledaj da li imas vise od jednog interface-a implementiranog u jednoj klasi.


Mislim da sam samo jednom razmisljao o tome da bi mi trebalo višestruko nasleđivanje ali sam brzo odbacio tu ludu misao :)

Mešaš nasleđivanje i implementaciju. Nasleđuju se objekti, interfejsi se implementraju, to su potpuno različite stvari. Čak i da C# ima višestruko nasleđivanje to ne bi isključilo potrebu za interfejsima. Tek sa interfejsima objektno programiranje ima punu snagu.

 
Odgovor na temu

negyxo
Aleksandar Perkuchin

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



+171 Profil

icon Re: Prelaz od C ka OO programiranju03.12.2018. u 21:49 - pre 27 meseci
Da kojim slucajem C# ima visestruko nasledjivanje, interfejsi bi od mene dobili srednji prst :D

Mislim, vidis, i ti kazes nije to nasledjivanje nego implementiranje. Sve je to nepotreban noise. Sta je onda apstraktna klasa sa samo apstraktnim metodma? Jel se implementira ili se nasledjuje :) Mislim, to su samo reci, sustina je, da je interfejs samo jedan unapred definisan fixni contract, koji bas nema mnogo podesavanja. Klasa, sa svojim svim atributima i modifierma daleko vise ti omogucuje da fine-tuning-ujes sta ce da se nasledjuje.

BTW. Pogledaj jablanovo pitanje na SO da bi razumeo zasto interfejsi postoje.
 
Odgovor na temu

dusans
Stojanov Dušan
Pančevo

Član broj: 9551
Poruke: 1335
*.dynamic.sbb.rs.



+309 Profil

icon Re: Prelaz od C ka OO programiranju03.12.2018. u 22:14 - pre 27 meseci
Interfejsi formalno omogućavaju najstrože i najčistije vidove polimorfizma i enkapsulacije.
 
Odgovor na temu

mjanjic
Šikagou

Član broj: 187539
Poruke: 2092



+587 Profil

icon Re: Prelaz od C ka OO programiranju03.12.2018. u 22:38 - pre 27 meseci
Par insteresantnih odgovora na: https://stackoverflow.com/ques...bstract-class-and-an-interface
i par odgovara sa tog linka:
From MSDN:
Citat:
By using interfaces, you can, for example, include behavior from multiple sources in a class. That capability is important in C# because the language doesn't support multiple inheritance of classes.
In addition, you must use an interface if you want to simulate inheritance for structs, because they can't actually inherit from another struct or class.

I relativno pojašnjeno, da ne prevodim:
Citat:
There are technical differences between Abstract Classes and Interfaces, that being an Abstract Class can contain implementation of methods, fields, constructors, etc, while an Interface only contains method and property prototypes. A class can implement multiple interfaces, but it can only inherit one class (abstract or otherwise).

However, in my opinion, the most important difference between Interfaces and Abstract Classes is the semantic difference.

An Interface defines what something can do (how it behaves), and an Abstract Class defines what something is.

Take for example IEnumerable, the semantic meaning behind this is that anything that implements IEnumerable is enumable, it doesn't mean that it's an enumeration, but that it can behave like one (can be enumerated).

Contrast that with the washing machine example, anything that inherits it is a type of washing machine. Anything that inherits it would be a type of washing machine, a top loader, or side loader, etc.

Instead, if you had an interface called ICanWash, which could contain a method called Wash. You could have various things implement ICanWash, be it a Person, an abstract washing machine class, etc, where the actual implementation does not matter, just you need to know that the behavior is that it can wash things.

In summary, classes define what something is, interfaces define what something can do.


U tom smislu, ne znam kod C++, nisam u njemu ništa radio od 2002. ili 2003. godine, ali mi se čini da ovo baš i ne važi za C++ jer kod njega ne postoji ključna reč za deklaraciju interfejsa kao npr. kod C#, pa odatle zabuna. Jednostavni zavisi od jezika do jezika.
Blessed are those who can laugh at themselves, for they shall never cease to be amused.
 
Odgovor na temu

Shadowed
Vojvodina

Član broj: 649
Poruke: 12705



+4688 Profil

icon Re: Prelaz od C ka OO programiranju03.12.2018. u 22:50 - pre 27 meseci
Citat:
Predrag Supurovic:Čak i da C# ima višestruko nasleđivanje to ne bi isključilo potrebu za interfejsima. Tek sa interfejsima objektno programiranje ima punu snagu.

Ne bi iskljucilo potrebu za onim sto donose interfejsi. Medjutim, to bi moglo da se postigne sa cistim apstraktnim klasama (onim kod kojih su sve metode, propertiji i eventi apstraktni).Interfejs kao koncept bi ostao ali interface kao kljucna rec ne bi bila neophodna. Ne kazem da bi trebalo tako ali da bi moglo - moglo bi.

Edit: s druge strane, sad kad uvedu default implementacije u interfejse, skoro pa ce postici obrnuto - da apstraktne klase budu suvisne. Kazem skoro jer apstraktne klase mogu imati npr. implementirane protected clanove.
 
Odgovor na temu

negyxo
Aleksandar Perkuchin

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



+171 Profil

icon Re: Prelaz od C ka OO programiranju04.12.2018. u 03:54 - pre 27 meseci
^Upravo. Koncept bi bio isti, samo ne bi postojala ta rec ali bi sa MI mogao da odlucis kada je nesto za nasledjivanje a kada je samo potreban oblik, sa malo tweakovanja jezika, to bi bilo jako prosto, poput extends i implements u typescriptu. E sad u vecini slucajeva, ne treba ti nasledjivanje, treba ti nesto poput mixina (mislim da bi u ts-u bilo odlicno da su ubacili jos jednu opciju pored extends i implements, recimo "deep implements" ili tako nesto).
 
Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8410
*.mediaworksit.net.



+2728 Profil

icon Re: Prelaz od C ka OO programiranju05.12.2018. u 11:44 - pre 27 meseci
Citat:
mjanjic: U tom smislu, ne znam kod C++, nisam u njemu ništa radio od 2002. ili 2003. godine, ali mi se čini da ovo baš i ne važi za C++ jer kod njega ne postoji ključna reč za deklaraciju interfejsa kao npr. kod C#, pa odatle zabuna. Jednostavni zavisi od jezika do jezika.

Ovaj deo nije tačan za C++:
Citat:
A class can implement multiple interfaces, but it can only inherit one class (abstract or otherwise).

C++ klasa može da nasledi proizvoljan broj klasa. Na primer:
Code (cpp):

class A
{
    ...
};

class B
{
    ...
};

class C : public A, public B
{
    ...
};
 

To je razlog zašto C++ nema ključnu reč za interfejse. Kad imaš višestruko nasleđivanje klasa (C++ i Python ga imaju), interfejsi su nepotrebni jer su specijalan slučaj klasa.
Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.
 
Odgovor na temu

mjanjic
Šikagou

Član broj: 187539
Poruke: 2092



+587 Profil

icon Re: Prelaz od C ka OO programiranju05.12.2018. u 11:59 - pre 27 meseci
Pa i napomenuo sam da ne važi za C++ (bar nije važilo pre 15 godina, ne znam ove revizije 2014 i novije da li su unele neke novine), onaj drugi citat se mislim tamo na stackoverflow odnosio na prethodni, tj. na C#.
Blessed are those who can laugh at themselves, for they shall never cease to be amused.
 
Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 895
77.46.200.*



+171 Profil

icon Re: Prelaz od C ka OO programiranju06.12.2018. u 21:32 - pre 27 meseci
@mjanjic
Htedoh da odgovorim na tvoj pretposlednji post ali usled obaveza nisam stigao...

Elem, to je prilicno dobar odgovor na SO zasto su "potrebni" interfejsi iz ugla nekog idealnog OOP modela... ali, nedostaje onaj praktican deo, sta se desi kada zelis da implementiras na isti nacin tu funkcionalnost? Da, zelis da ti je code decoupled, pa samim tim prebacujes funkcionalnosti u razlicite delove, ali kako to onda iskoristiti a da ne moras uporno da ponavljas code? Mislim da je ovo problem na koji dizajneri interfejsa nisu mislili ili su mislili da to nije neki issue na koji ce se ljudi zaliti (a kao sto vidimo, sa ovim defaults interface implementation upravo pokusavaju, ja bih rekao na polovican nacin, da rese).

Recimo, da vidimo iz ugla code-a, kako to izgleda:

Code:

interface ICanWash 
{
    void Wash();
    bool IsDirty;
}

class Person {
    string Name;
    Date Born;    
}

class Car {
    string Model;
    int Year;
}


Imamo dve klase, imamo jedan interfejs (contract) koji nam definise sta mozemo da radimo/implementiramo (ne nasledjujemo) sa tim objektima. Ako probamo da implementiramo:

Code:

class Person : ICanWash {
    string Name;
    Date Born; 
    bool IsDirty;

    Wash() {
       // do some common functionality
       IsDirty = false;
    }
}

class Car : ICanWash {
    string Model;
    int Year;
    bool IsDirty;

    Wash() {
        // do some common functionality
        IsDirty = false;
    } 
}


Iz ovog primera, vidimo da imamo redudantan code. Sta mozemo da radimo? Pa apsolutno nista, mozes common functionality da prebacis u neku common klasu i odatle implementiras interfejs (i opet imas redudantan code). Naravano, u ovom primeru bi mogli da namesitmo apstraktnu klasu i nasledimo je, ali to nije poenta, zato sto: prvo, zelimo da imamo cist OOP model, ne zelimo nasledjivanje, i drugo, ovaj primer nema u klasama Person i Car base klasu, da kojim slucajem ima, onda opet ne bi mogli da iskoristimo klasu.

E sad, kako bi code izlgedao sa klasom:


Code:

class CanWash {
   bool IsDirty;

    Wash() {
       // do some common functionality
       IsDirty = false;
    }
}

class Person : CanWash {
    string Name;
    Date Born;
}

class Car : CanWash {
    string Model;
    int Year;
}


Hm, iz mog ugla ovo je daleko elegantnije nego ovo sa interfejsima ali... imamo jedan problem, mi smo nasledili, tamo gde treba da implementiramo, opet nekako to nije to ali... kako se implementira interface, recimo u C#, a kako se nasledjuje klasa:

Code:

// interface implementation
class Car: ICanWash

// class inheritance
class Car: CanWash



WTF? Pa zar ovo nije igra reci onda? Nije naravno, onaj odgovor na SO nam govori suptilnu razliku.

OK, ali onda, trebalo je tu suptilnu razliku eksplicitno naglasiti, pa bi onda valjda i oni pure OOP concept zealoti bili zadovoljeni.

I, sad cu se osvrnuti na TypeScript. Nisam pratio razvoj TypeScripta, ali cini mi se da su tamo upravo ovo hteli da naglase, plus, imamo skoro proof-of-concept kako bi ovo moglo da funkcionise da su sve klase.

U TypeScriptu postoje dve kjlucne reci extends i implements, i to nas dovodi do:
- klasa moze da nasledi klasu, ali ne moze interface
- klasa moze da implementira interface
- klasa moze da "implementira" klasu
- interface moze da nasledi interface
- interface moze da "nasledi" klasu

i code:

Code:

interface ICanWash 
{
    void Wash();
    bool IsDirty;
}

class Person {
    string Name;
    Date Born;    
}

class Car {
    string Model;
    int Year;
}


ako pokusamo da implementiramo

Code:

class Person implements ICanWash {
    string Name;
    Date Born; 
    bool IsDirty;

    Wash() {
       // do some common functionality
       IsDirty = false;
    }
}

class Car implements ICanWash {
    string Model;
    int Year;
    bool IsDirty;

    Wash() {
        // do some common functionality
        IsDirty = false;
    } 
}



ako pokusamo da nasledimo:

Code:

class CanWash {
   bool IsDirty;

    Wash() {
       // do some common functionality
       IsDirty = false;
    }
}

class Person extends CanWash {
    string Name;
    Date Born;
}

class Car extends CanWash {
    string Model;
    int Year;
}



Voila! Ali smo prekrsili onaj koncept sa SO, mi smo nesto nasledili, umesto implementirali ali TypeScript dozvoljava da se klasa impelementira, u kom slucaju, se ne nosi default implementacija, nego se nosi samo njen implicitni "interface":


Code:

class Person implements CanWash {
    string Name;
    Date Born; 
    bool IsDirty;

    Wash() {
       // do some common functionality
       IsDirty = false;
    }
}

class Car implements CanWash {
    string Model;
    int Year;
    bool IsDirty;

    Wash() {
        // do some common functionality
        IsDirty = false;
    } 
}


Sto ce reci, da je isto kao da imamo i interface, jer TypeScript, iako postoji klasa CanWash, gleda samo fasadu te klase (interface) ne i implementaciju.

E sad, TypeScript, bas kao i C# i Java ne podrzava MI, pa samim tim, onda je uvek safe bet da se ide na interface, ali da koji slucajem podrzava, onda bi interface-i bili totalno bespotrebni. TypeScript ima mixine zato, ali kada bi otisli korak dalje, mixini bi mogli da se implementiraju kroz implements direktivu, tj. neku novu, kao sto sam spomenuo, "deep implements".


Code:


// Mora da se implementira CanWash, iako je CanWash klasa sa implementacijom, 
// jer smo rekli da hocemo fasadu te klase
class Person implements CanWash {
    string Name;
    Date Born; 
    bool IsDirty;

    Wash() {
       // do some common functionality
       IsDirty = false;
    }
}

// ne mora nista da se implementira, vec je implementirano sa "deep implements",
// ovo je razlicito od "extends" extends nasledjuje, "deep implements" implementira,
// deluje pomalo smesno, kada se gleda code, samo su reci razlicite, ali u runtime
// to bi se moglo manifestovati tako da kada ispitamo:
//    Persion is CanWash -> false
//    Persion is implements CanWash -> true
//
class Person deep implements CanWash {
    string Name;
    Date Born; 
}


Sorry na poduzem postu.

edit: typo, IsDirty

[Ovu poruku je menjao negyxo dana 07.12.2018. u 05:29 GMT+1]
 
Odgovor na temu

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

Strane: < .. 1 2 3 4 5 6

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

Postavi temu Odgovori

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