C#, interfejsi i apstraktne klase

[Ivan]

Polako ulazim u svet C# i usavrsavam svoja OOP znanja, pa bih shodno time hteo da se bolje upoznam sa interfejsima i apstraktnim klasama.

Kontam donekle (mada je vec i kasno za bistro razmisljanje) ali bih bio zahvalan ako neko moze na primerima da objasnji kada, kako i zasto koristiti ove tehnike ?

Ako imate i linkove ka kvalitetnim diskusijama, prilozite. Verujem da tema moze biti korisna za sve

Hvala,
Ivan

[ivanhoe]

(cisto teoretski, posto konkretno u C# nisam radio, ali je to isto u svim jezicima):

pa recimo DB abstraction layer mi prvi pade na pamet. Imas klasu koja treba da radi sa bazom, i ti znas da mora da ima odredjene metode (npr. connect, query, itd..), ali posto ne znas unapred sa kojim bazama ce raditi nema nikakvog smisla da implementiras konkretne metode. Samo deklarises da moraju da postoje te i te metode, i ne ulazis dalje u detalje realizacije (to ostavljas onom ko bude radio implementaciju, sto mozes da budes ti ili neko peti) i onda slobodno mozes da razvijas ostatak sistema racunajuci da te metode uvek postoje i vracaju sta treba, jer ti sama OO arhitektura to garantuje.

[degojs]

Razliku između jednog i drugug možeš i sam da nađeš ako malo potražiš, a preporučio bih da kreneš od MSDN-a.

Ima jedna stvar na koju obrati pažnju: često će kao nedostatak interfejsa da se nabroji to da oni izazivaju lomljavu ako poželiš da ih izmeniš ili to da ne nude mogućnost za implementaciju, ali to baš više i nije tačno jer lako mogu da se prošire koristeći extension methods. Ako budeš nabavljao neku knjigu, dakle, obavezno obrati pažnju da je up-to-date sa novijim verzijama C# (3.0).

Inače, mnogo se koriste da se komponente sistema razdvoje - da jedna komponenta ne ovisi od konkretne implementacije druge. Šta to znači? Pa u ovom primeru što je pomenuo Ivanhoe, možeš lepo da programiraš "against interface" i baš te briga da li tvoj kod priča sa MySQL ili Oracle bazom - ti programiraš koristeći interfejs npr. IDatabaseCommand, a MySQLCommand i OracleCommand klase obe implementiraju taj interfejs pa tebe nije briga sa kojom konkretno od njih radiš (nećemo da biramo klijente na osnovu toga koju bazu oni imaju - neka firma može da već ima jednu, a neka drugu bazu, a mi lepo možemo da radimo za bilo koga od njih.. Nećemo da odbijemo posao samo zato što oni tamo već imaju npr. Sybase ili DB/2 ili zato što oni neće da na mrežu dodaju FirebirdSQL koji mi najviše volimo da koristimo). Pojednostavljeno objašnjenje

Ovakva postavka, "decoupling" između komponenti, je inače imperativ kod TDD-a. Opet, u tom gore primeru, lako ćeš da pišeš unit testove koristeći lažnu bazu (npr. koristiš neku FakeCommand klasu koja implementira IDataBaseCommand, da ne ulazimo u priču oko mock-ovanja. Vidi link dole za više detalja).

E da, evo ti jedan link, već su ljudi i ovde hvalili istu knjigu. Sa manje od 100 stranica i cenom $0, nekako je obavezno čitanje. Ako ti se čini da ne razumeš najbolje materijal u istoj, ne zaboravi da je pogledaš kasnije kad malo ukapiraš kako stvari rade.

http://www.novetehnologije.com/ShowN...ogramming.aspx

[merjadok]

Ukratko: http://en.csharp-online.net/Should_I...n_interface%3F

[jablan]

Najjednostavnije vidiš čemu nešto služi na konkretnom primeru. Dakle, uzmi bilo koji interfejs iz .NET frejmvorka, pogledaj čemu služi, videćeš zašto je definisan baš kao interfejs.

Npr. IComparable ti je baš knjiški primer: http://msdn.microsoft.com/en-us/libr...omparable.aspx

Bitno je imati u vidu da C# ne podržava višestruko nasleđivanje, tj. jedini način da tvoja klasa "nasledi" više klasa je tako što će implementirati više interfejsa.

[andrej]

Mozda kao interesantan primer moze da posluzi REST arhitektura, gde je implementacija putem HTTP protokola samo jedna od mogucnosti.
Znaci postoje neke metode (GET, POST, PUT, DELETE...), koje su zajednicke, tj. koje predstavljaju interfejs, tako da njihovim pozivom obavljaju se odredjene akcije sa istim rezultatom, neovisno o nacinu implementacije.