Jump to content
Forumu Destekleyenlere Katılın ×
Paticik Forumları
2000 lerden beri faal olan, çok şukela bir paylaşım platformuyuz. Hoşgeldiniz.

C# interface olayi


reyou

Öne çıkan mesajlar

simdi IComparer diye interface imiz var mesela biz bunu bi class uzerinde kullandigimizda illede tanimlamis oldugu fonksyonu mesela doldurmamis gerekiyo yani kullanicaz class icerisindede e simdi mesela fonksyonu ben yazacaksam zaten neden illede interface uzerinden gidiyim?

yani bu sey icinmi mesela ben bi class yazdim ancak bu class da olmazsa olmaz fonksyonlar olmasi gerekiyo, 3 ayri interface den turettim diyelim baskasi gelip kodu yazdiginda illeki kullansin diyemi,

bi tam olarak oturtamadim su interface mantigini yani hic elim alisik degil bole paldir kuldur direk class larla yaziyorum napmak istiyosam ancak sunun mantigini iice kavrarsam daha ii olcak gibime geliyo.

ozetin ozeti; su interface olayini anneye anlatir gibi gibi anlatabilirmi o kadar kaynaktan okudum yok kafama girmedi, tum kitaplardada illeki kullaniyolar kendimi cok yalniz hissediyorum :(
Link to comment
Sosyal ağlarda paylaş

Interface, onu implement edecek seyden bekledigin genel ozellikleri tanimliyor iste.
Kullanmamak tabi ki mumkun, sana kod acisindan vs yarari olmuyor mesela abstract class gibi. Ama implement edecek tum classlarin belli bir yapida olmasini sagliyor.
Yani interface'de foo methodu varsa bu interface'i implement eden her class bu methodu da implement etmek zorunda.
Link to comment
Sosyal ağlarda paylaş

himm, o zaman bu .net te kodlama yaparken bi standartlasma gitme olayi gibi biseymi?

mesela 3 farkli class var canta, ayakkabi, sapka
simdi diyelim bunlarin ucundede kopyalama fonksyonlari olacak
biz bunlari ICloneable den turetirsek bunlar zike zike
Clone() fonksyonunu kullanicak iclerinide biz doldurucaz,
yani 3 ayri class ta ayni isi yapan fonkyonu farkli isimlerle adlandirip kafamizi karistirmicaz gibi bisey?

evetse; o zaman bunun makine tarafinda herhangi bir faydasi yok yani performans acisindan falan sirf insanlar daha iyi okusun, yonetilebilirligi kolay olsun kisaca standart olsun isimler gibisinden vs.

hayirsa; cidden koca kafaliyim.
Link to comment
Sosyal ağlarda paylaş

Kendi örneğini kendin çok güzel vermişsin. Ayakkabı, Çanta, Şapka
Hepsinin ortak bir özelliği var, Kıyafet olmaları.
Ve kıyafetlerin ortak özelliklerini yazacağın interface içerisinde tanımlayabilirsin. Renk, bayan-erkek, fiyat, marka vesaire.... Bunun dışında hepsinin bahsettiğiniz gibi Wear() diye bir metodu olabilir. Veya Sell()...

Ama mesela ayak numarası sadece ayakkabının kendisine ait farklı bir özelliktir. Veya şapkanın kışlık veya yazlık olup olmadığı... Bunları da kendi sınıfları içinde ayrıca tanımlarsın.

Bu kendilerine has farklı özellikleri yüzünden şöyle bir yöntemi kullanmak istemeyebilirdin: interface olmadan "Kıyafet" diye kendine bir sınıf tanımlardın, sınıfın içerisinde "kıyafet-türü" diye bir özellik tanımlayıp, ayakkabı mı şapka mı olduğunu burada tutardın. İşte bu yöntemden daha da object oriented olabilmek adına aynı interface'den farkılı sınıflar tanımlıyorsun.
Link to comment
Sosyal ağlarda paylaş

Ömrün boyunca code yazıp, bir defa bile interface kullanmayabilirsin.

Interface, Object ler arasındaki ilişkilerde kuralların enforce edilmesi yani object leri yazan, debug ve maintain eden n tane developer ın belli noktalarda code a bıraktıgı contract dır. Interface değişmedikçe code contract a sadıkdır, safe dir etc.

Obj. Ori. denizinde yüzerken, aşşağıda 50 API kullanıp tepeye 50 'interface' verirken code unuzda, ne işe yaradığını, yararının ne kadar buyuk oldugu anca anlaşılır.
Link to comment
Sosyal ağlarda paylaş

Arthur_HellsFire said:

şimdi düşünki liste gibi bir classın var onu foreach ile kullanmak istiyorsun, IEnumerable ve IEnumerator interfacelerini implement ettiğin vakit foreach o classı nasıl kullanacağını biliyor.
http://support.microsoft.com/kb/322022

bildiğin araç mantığı kol levye direksiyon falan :D


iste benimde kastettigim bu, simdi mesela adam
public class cars : IEnumerator,IEnumerable
seklinde tanimlamis, iide bu interface lerin implement
ettigi fonksyonlarinda iceriklerini ben yaziyom zaten, yani
framework bana ek olarak hazir fonksyonlar sunmuyo.
farzi misal en basitinden string.replace("param1","param2"); fonskyonu hazir olarak gelen bi fonksyon ve biz tek tek characterleri arayip
degistirecegimize for icinde fln bunu kendisi yapiyor
ama ben IEnumerator,IEnumerable den turettigim zaman bi
class i kendim

//IEnumerator and IEnumerable require these methods.
public IEnumerator GetEnumerator()
{
return (IEnumerator)this;
}

//IEnumerator
public bool MoveNext()
{
position++;
return (position < carlist.Length);
}


gibi fonksyolarin icini dolduruyorum, ha icleri dolu olarak
gelse tamam dicemde yani ben interface den turetecegime
direk bu fonksyonlari kendim yazar devam ederim zaten?
Link to comment
Sosyal ağlarda paylaş

Senin aklındaki soru interface in ne oldugu değil bu noktada, diyorsun ki interface define etmişler ama impl. ini koymamışlar. Apayrı bir konu bu.

Adamın sana sundugu API da veyahut framework de yaptığı işlerden bazıları için interface tanımlayıp impl. vermemişse, bu demektir ki bu interface lerin kullanım amaçlarına göre esnek davranışları olabilir, kullanıcı ya işine yarayan impl. alıp kullanır farklı bir adamdan yada kendisi implement eder.

Misal, ben oturur bir API hazırlarım. Benim adamım bir ses dosyasının alıp bitrate ini değiştirip beni ilgili obje den cagıran adama dönerim file i. Bu noktada Persist diye bir interface tanımlarım ve expose ederim code u.

Expose etmek den kasıt, aşşağıda bir yıgın encoding decoding yaparken beni cagıran adamın herhangi birşey den haberi olmaz. Expose ettiğim noktada kullanıcıyı dahil edip, impl et kardeşim Persist interface ini, bunun uzerinden transcode edilmiş dosyayı filesystem e mi, database emi nereye istiyorsan persist et derim.

Bana diyemezsin, impl i neden yok filesystem olsun database olsun vs vs, API nin scope un da değildir belki o.
Link to comment
Sosyal ağlarda paylaş

genelde interfaceler farklı classlara aynı özellikleri kazandırmak icin kullanılır.

bu sayede daha generic kodlar yazabilirsin.

aynı zamanda mevcut interfaceleri de implemete ederek birtakım kolaylıklardan yararlanmak mümkün.

atıyorum IComparable interfaceini implemente ettin.

elinde bir array var, Array.Sort dedidign zaman auto kendisi sort eder. iki objeyi nası kıyaslayacagını sen gösteriyorsun.
Link to comment
Sosyal ağlarda paylaş

bu ornekle anlarsin abi


public interface IPencil
{
void Write();

bool IsSharp { set; get; }
}



public interface IPencilSharpener
{
void Sharpen(IPencil pencil);
}


IPencilSharpener'i implement edecek class, Sharpen methodunu implement ederken pencil'in, hangi classa ait olursa olsun IPencil'i implement eden bir class'in instance i oldugu icin IsSharp 'i olacagini biliyor ve bu yuzden Sharpen methodunu implement ederken IsSharp'i kullanabiliyor.
Link to comment
Sosyal ağlarda paylaş

Penthesilea said:

Oyle yaparsan programinin calismasinda degisen birsey olmaz, ama bir libraryde parametre olarak ienumerable alan bir methoda yollayamazsin bu yazdigin classi. Cunku ienumerable aliyorsa bir method, ienuerable in zorunlu kildigi next zart zurtu kullanacak demektir, bu sekilde enforce ediliyor sana iste.


evet birde kafamin karistigi noktalardan biride bu, interface turunden objeler uretip bunlari kullanmak.
ya simdi ben herseyi gercek hayat ile bagdastirmaya calistigim zaman,
bir tasit fabrikamiz var, biz muhendisiz ve bize kalip olarak parcalar geliyo diyelim govde + tekerlek + boya bunlar birer property olsun sonra elimizde kullanicagimiz 3 fonksyon var, monteEt(), boya(), calistir() ok simdi bunlarda fonksyon ve biz araba, kamyon ve otobus ureticez bunlarda class oluyor. simdi bizim interface imizde daha onceden yapilmis bir prototip araba oluyor dimi?
cunku o prototip baktigin zaman bi ise yaramaz calismaz kutu gibi bisi ici bos yani (propertileri dolu degil, fonksyonlari bos) ama biz ona bakarak nasil monte edildigine nasil Boyandigina bakarak her uc farkli siniftaki arabayida ortak ozelliklere dayandirarak calistircaz.

peki buda guzel e simdi mesela bitanede baska ayri bir fonksyonumuz var modifiyeEt() buda diyelim tum class lar doldurulduktan sonra arabalarin govde ozelliklerini 30cm genislettigini dusunelim, e simdi bu interface turunden (yani prototip araba turunden) parametre alirsa
nasil alip islicek isi bos olan seyi? cunku govdesi belli degil sonucta interface bu, ama yok class alsa zaten ben doldurmusum o class in ozelliklerini o zaman istedigi gibi isler?

yani interface objelerinin gercek hayatta nereye oturtacagimi anlamadim.


Edit; cevaplar gelmis arada, onlarida bi okuyim belki yukarida yazdiklarimi daha ii anlarim, simdilik dursun burda :)
Link to comment
Sosyal ağlarda paylaş

reyou said:

diyelim govde + tekerlek + boya bunlar birer property olsun sonra elimizde kullanicagimiz 3 fonksyon var, monteEt(), boya(), calistir() ok simdi bunlarda fonksyon ve biz araba, kamyon ve otobus ureticez bunlarda class oluyor. simdi bizim interface imizde daha onceden yapilmis bir prototip araba oluyor dimi?
hayir, arac oluyor. sen fabrikanda arac uretiyorsun, bu arac araba da olur, kamyon da otobus de. kamyon araba'nin 5 kati, sirtinda dana gibi konteynir var, 8 tekerlekli zart zurt, ama o da ayni araba gibi monte ediliyor (Dikkat: ayni araba gibi derken arabayla ayni sekilde degil, nasil araba monte ediliyorsa o da monte ediliyor anlaminda), boyaniyor ve calistiriliyor. ama araba ve kamyon'un monte edilmesi, boyanmasi ve calistirilmasi birbirinden cok farkli. ornegin araba monte edilirken 4 tekerlek takiliyor, kamyonda 8 tekerlek takiliyor. burada monte et, boya ve calistir, senin fabrikandan cikacak herhangi bir aracta yapman gereken 3 islemi anlatiyor sana, sadece ve sadece o kadar.

said:
cunku o prototip baktigin zaman bi ise yaramaz calismaz kutu gibi bisi ici bos yani (propertileri dolu degil, fonksyonlari bos) ama biz ona bakarak nasil monte edildigine nasil Boyandigina bakarak her uc farkli siniftaki arabayida ortak ozelliklere dayandirarak calistircaz.
hayir, anlamamanin sebebi bu sanirim. ona bakarak nasil monte edildigine, boyandigina falan bakmayacaksin. ona bakarak, benim fabrikamdan bir "arac" cikacaksa, bu ne olursa olsun, ben bunu monte edicem, boyuyacam ve calistiracam diyeceksin. bunlari nasil yapacagin classtan classa degisiyor, onlara, kamyon'u nasil monte ediyormusum icin mesela Kamyon.MonteEt() ten bakacaksin.

said:
peki buda guzel e simdi mesela bitanede baska ayri bir fonksyonumuz var modifiyeEt() buda diyelim tum class lar doldurulduktan sonra arabalarin govde ozelliklerini 30cm genislettigini dusunelim, e simdi bu interface turunden (yani prototip araba turunden) parametre alirsa
nasil alip islicek isi bos olan seyi? cunku govdesi belli degil sonucta interface bu, ama yok class alsa zaten ben doldurmusum o class in ozelliklerini o zaman istedigi gibi isler?
oyle birsey yapacaksan interface degil abstract class yapman lazim. interface sana sadece prototip verir, hicbir classi implement edemezsin.
ama mesela abstract class yaparsan arac'i, modifiyeEt() methodu abstract olmaz, bunu extend edecek tum classlar da direk super classlari olan aractan bu modifiyetEt() methodunu kullanirlar.

said:

yani interface objelerinin gercek hayatta nereye oturtacagimi anlamadim.
fabrikan var, araba uretiyorsun, belli bir sirasi yok neyi urettiginin.


protected void AracUret(IArac arac) {
arac.MonteEt();
arac.Boya();
arac.Calistir();
}


sonra da diyelim bir Set'in var, icinde random bi sekilde kamyon, araba, minibus zart zurt var, hepsi de IArac'i implement ediyor


Fabrika fabrika = new Fabrika();
foreach(IArac arac in yukaridaki set)
{
fabrika.AracUret(arac);
}
Link to comment
Sosyal ağlarda paylaş

Ha son olarak, Arac interface'inin monteEt() methodu cagirilmiyor mesela orada, eger parametre bir Kamyonsa, Kamyon'un monteEt() i cagiriliyor, arabaysa onunki cagiriliyor vs. Ama interface'de define edilmis ama ici doldurulmamis methodlar sayesinde, tum araclar icin, burada ne olursa olsun monteEt bunu diyebiliyorsun.

1- ayni sette 3 farkli class'i tasidik
2- ayni methoda 3 farkli class yolladik
3- 3 farkli class'in monteEt methodlarini tek satirda genel bir sekilde cagirdik. eger interface imiz olmasaydi soyle olacakti:

arac zaten object olacakti methodda, bu basli basina cirkin. sonra,


if(arac instanceof Kamyon) {
Kamyon k = (Kamyon) arac;
k.monteEt();
}
else if(arac instanceof Araba) {
Araba a = (Araba) arac;
a.monteEt();
}
else if(blah blah blah) {

}



ve bu kadar kastin yazdin bunlari teker teker, ustune yeni bir arac turu eklemek icin sadece IArac implement eden yeni bi class yaratmak varken gidip buradaki if else e yeni bi condition eklemen gerekti, falan da filan.

bunlarin da haricinde, diyelim bi hata oldu bu fonksiyona (Object aldigi icin interface kullanmadigimizdan) gittin Ekmek class'inin bir instance'ini yolladik. Program cakacakti haliyle. Bu sekilde, abi ben AracUret fonksiyonuna sadece Arac interface'ini implement eden seyleri aliyorum diyorsun.
Link to comment
Sosyal ağlarda paylaş

Gladmir said:

Pent in anlattıklarını özümsedikten sonra

Factory pattern i incelersen daha güzel oturur herşey.


evet bende onlari okuyodum bu arada,
cok guzel aciklamis penth onada ayri bi tesekkur edicem tamamen bitirdikten sonra. (cunku valla her satiri 5 kere okuyorum tamemen anliyim diye :)


zaten factory patternini okurken aklima geldi bu,
anlatan adam her ornekte interface dolduruyo kodu
dedim olmicak bu boyle,
Singleton ve Facade kullaniyomusum ben su ana kadar farkinda degilim, ama dedigin gibi Factory pattern cuk diye oturuyo bu orneklere simdi daha ii anliyorum.
Link to comment
Sosyal ağlarda paylaş

Evet bu penth e benden bir tesekkur mesajidir, cidden ii oldu mantigini kavradigim. Cok iyi anlatmissin.

Gelecek sorularim tahminimce multithreading, delegate ve event kavramlarinda aklima takilan ufak sorular olacaktir.

Herkese verdigi yanitlardan dolayi tesekkurler. :)

Response.End();
Link to comment
Sosyal ağlarda paylaş

×
×
  • Yeni Oluştur...