Bu bölümde Sınırlandırıcıları(Constraints) göstermeye çalışacağız. Hazırsanız buyrun.

Sınırlandırıcılar(Kısıtlamalar, Constraints)

Öyle olurki bazen, tip argümanlarınızın belli metodları ve özellikleri içermesini isteyebilrsiniz. Mesela çizim yapma özelliği olan sınıfların kolleksiyonunu tutan bir generic sınıf düşünün. İsmi de TCizebilenKolleksiyon gibi bir şey olsun. Bu generic kolleksiyona atayacağınız her elemanın bir çizim gerçekleştiren “Ciz” gibi bir metodunun olmasını isteyebilirsiniz. Bu durumda, tip parametresini belli arayüzler ile sınırlandırmanız gerekmektedir. Bu örneğimizi koda dökecek olursak, arayüzümüz şöyle bir şey olacak:

ICizebilen = interface
public
  procedure Ciz;
end;

Bu arayüz ile sınırlandırılmış olan kolleksiyon sınıfımız da şöyle bir şey olabilir:

TCizebilenKolleksiyon<T: ICizebilen> = class
...
end;

Bu durumda T parametresine atayacağımız her argümanın ICizebilen arayüzünün sahip olduğu özellik ve metodlara sahip olacağını garantilemiş oluyoruz.

.Net ortamında kullanabilceğiniz bir çok arayüz bulunmaktadır. Bu arayüzler genelde “able” son eki ile biterler. “able” ekinin Türkçe karşılığı “-ebilen”, “-abilen” olarak düşünebilirsiniz.. ISerializable, IComparable, ICloneable, vs…

Tip parametreleri birden fazla arayüz sınırlandırıcısı alabilir. Bu durumda tip parametreleri virgül yerine aynen prosedür ve fonksiyonların parametrelerinde olduğu gibi “;” noktalı virgül ile ayrılırlar. Mesela:

TSinif<T: ISerializable; U: IColoneable> = class

gibi… Bu örneğe göre T parametresi ISerializable arayüzünü, U parametresi de IColoneable arayüzünü desteklemesi şarttır.

Ayrıca, birden fazla sınırlandırıcı, tek bir tip parametresine atanabilir. Bu durumda bunlar, “AND” lojik mantığına göre tip parametresini sınırlandırırlar.

TSinif<T: ISerializable, IColoneable> = class

gibi… Bu örnekte T parametresi hem ISerializable, hem de IColoneable arayüzlerini desteklemek zorundadır. Aynı şekilde prosedür ve fonksiyon parametrelerinde olduğu gibi aynı sınırlandırmaya sahip iki tip parametresini virgül ile ayrırak beraber yazabilirsiniz:

TSinif<T, U: ISerializable> = class

gibi… Bu örneğe sınırlandırıcıya sahip olmayan bir parametre daha ekleseydik noktalı virgül ile ayırmamız gerekecekti:

TSinif<T, U: ISerializable; Z> = class

gibi…

Bunlar grammer ile ilgili kısımlardı. Peki derleyicinin davranışı nasıl olacak? Aşağıdaki örneğe bakalım:

TPrintableCollect<T: IPrintable> = class ...
...
TDeneme = class(IPrintable)
  procedure Print;
end;

THata = class
end;
...
var
  Calisan: TPrintableCollect<TDeneme>;
  Hatali: TPrintableCollect<THata>; //Syntax hatası: THata sınıfı IPrintable arayüzünü desteklemiyor.

Gördüğünüzü gibi THata sınıfı IPrintable arayüzüne yabancı olduğu için tip argümanı olarak atadığımızda syntax hatası alıyoruz.

Bununla beraber aynı mantık ile arayüz yerine bir sınıfı sınırlandırıcı olarak kullanabilirsiniz. Bu durumda generic sınıfımız ancak ve ancak sınırlayıcı olarak verdiğimiz sınıf ve alt sınıflarından tipleri alabilir. Mesela:

TBirSinif = class...
TBirAltSinif = class(TBirSinif)...
TBirKolleksiyon<T: TBirSinif> = class...

Bu örneğimizde T tip parametresine ancak ve ancak TBirSinif ve ondan türeyen sınıflar argüman olarak atanabilir.

Sınırlandırıcılarda Belirsizlik

İki adet sınırlandırıcı, bir tip parametresine atandığını düşünelim. Mesela:

TTest<T: ISerializable, ICloneable> = class
  BirNesne: T;
  procedure Klonla;
end;

procedure TTest<T>.Klonla;
begin
  BirNesne.Clone;
end;

Derleyici “BirNesne” değişkeninin ISerializable ve ICloneable arayüzlerini desteklediğini biliyor. Ayrıca IClonable arayüzünde de Clone isminde bir metod olduğunu da biliyor. Bu yüzden Klonla metodunda Clone metodunu çağırırken herhangi bir çevirim işlemi yapmadık. Çünkü derleyici, Clone metodunun hangi arayüze ait olduğunu biliyor.

Farz edelim ki Clone metodu, hem ISerializable hem de ICloneable arayüzlerinde bulunuyor olsun. Bu durumda Clone metodunu yukarıdaki gibi çağırdığımızda ne olacak? Derleyici bu durumda belirsizilik olduğuna dair bir hata mesajı gösterecektir. Bu belirsizliği ortadan kaldırmak için harici çevirim(explicit casting) yapmalıyız. Yani:

procedure TTest<T>.Klonla;
begin
  ISerializable(BirNesne).Clone;
  ICloneable(BirNesne).Clone;
end;

Bu durumda, ilk Clone çağırımı ISerializable arayüzü üzerinden, ikincisi ise ICloneable arayüzü üzerinden gerçekleşecektir.

Sınırlandırıcı Olarak constructor, class ve record Kullanmak

Eğer sınırlandırıcı olarak record gibi referansız tipler kullanacaksak bu durumda “record” ayrılmış kelimesini kullanıyoruz. Ama dikkat etmemiz gereken konu kullanacağımız tip argümanı nullable yani null değer alabilen bir tipten olmamalı. Mesela string nullable’dır ama Integer değildir.

Aynı şekilde eğer sınırlandırıcımız sadece referanslı tipler olacaksa bu sefer de “class” ayrılmış kelimesini kullanmaktayız. Ayrıca kullanacağımız tip nullable olabilmeli. Yani tip argümanı olarak sınıfların yaninda string gibi nullable tipleri de kullanabiliriz. Bunları şu şekilde örneklendirelim:

TReferansiz<T: record> = class...
TReferansli<T: class> = class...
TBirRecord = record
end;

var
  Hatali1: TReferansiz<string>; //Hatalı, çünkü string nullable,
  Hatali2: TReferansli<Integer>; //Hatalı, Integer referanslı bir tip değil
  Uygun1: TReferansiz<TBirRecord>;
  Uygun2: TReferansiz<Integer>;
  Uygun3: TReferansli<string>; //string nullable bu yüzden uygun.

gibi…

Constructor kelimse ise, sınırlandırıcıda kullanılan sınıfın mutlaka parametresiz bir constructor’a sahip olmasını şart koşmaktadır. Mesela:

TBirSinif = class
  constructor Create;
end;

TBirBaskaSinif = class

end;

TBirKolleksiyon<T: constructor> = class...
...

var
  Uygun: TBirKolleksiyon<TBirSinif>;
  Hatali: TBirKolleksiyon<TBirBaskaSinif>;

Bu örnekte Uygun nesnesinde tip argümanı olarak TBirSinif tipini girdik. Ve derleyici bunu kabul etti. Çünkü TBirSinif parametresiz bir constructor’a sahip ve sınırlandırıcımız için uygun. Fakat Hatali nesnesinde tip argümanımıza girilen TBirBaskaSinif tipi parametresiz bir constructor’a sahip değil. Bu yüzden derleyici burada hata gösterecektir.

Sonuç

Normalde Delphi.NET derleyicisi, generics ve .net 2.0′a tam destek vermekle beraber, bir çok bug da içeriyor. Gerçi bu cümleleri yazdığım sıralarda, RAD Studio 2007 daha 1 haftadır piyasada. Şu an bildiğim kadarı ile Rad Studio 2007′in çıkacak olan update’inde büyük çoğunlukla derleyici ve asp.net’deki düzeltmeler bulunacak. Derleyici düzeltmelerinde de pastanın büyük payını generics ile ilgili hatalar alacak. Bu yüzden generics ile uğraşırken “Internal Error XXXX” gibi hatalar ile karşılaşırsanız kafanızı duvarlara vurmayın. Çünkü internal error’lerin hepsi bug olarak kabul edilir. Böyle bir durumla karşılaştığınızda eğer yoksa QC’ye rapor edebilirsiniz.

Fatih Tolga Ata © 2007

Kaynaklar:

• CodeGear’ın Delphi Parametrize Tipler ile İlgili Taslak Metinleri
• .NET 2.0 SDK Yardım Dosyası
• Microsoft Visual C# 2005 Step by Step, John SHARP, 2005 Edition

]]> http://www.diyezon.com/enine-boyuna-generics-bolum-2/feed/ 1 http://www.diyezon.com/enine-boyuna-generics-bolum-1/?utm_source=rss&utm_medium=rss&utm_campaign=enine-boyuna-generics-bolum-1 http://www.diyezon.com/enine-boyuna-generics-bolum-1/#comments Tue, 18 Sep 2007 03:58:02 +0000 Fatih Tolga Ata http://www.diyezon.com/?p=54 Bir iki önceki makalemizde, Delphi gramerine katılan generics ve parametrize tipleri yüzeysel olarak tanıtmıştık. Generics, RAD Studio 2007′ nin çıkması ile artık sadece beta tester’larını değil, tüm Delphi programcılarını ilgilendiren bir konu olmuştur. Gerçi şu an için sadece .NET ortamında kullanabildiğimiz bu özellik bir sonraki sürümde Win32 için de kullanılabilir bir gramer olacaktır. Başlangıç için önceki makalemizi okuyabilir ya da direk buradan başlayabilirsiniz. Zira bu bölümde Generics ile ilgili temel bilgiler vereceğiz.

Giriş

Generics’i doğru bir şekilde anlayabilmek için, hangi problemleri çözmek için dizayn edildiğini anlamakta yarar var. Bunun için ilk başta temel bir konudan ve bununla ilgili bir problemden bahsedelim.

.Net ortamı için object tipini herhangi bir değer ya da değişken için referans olarak kullanabilirsiniz. Çünkü her bir referans tipi otomatik olarak System.Object sınıfından türetiilir. Delphi’nin özel tipleri bile .net ortamına geçtiğinde artık birer object olacaktır. Fakat bazı durumlarda explicit casting yapmadan object sınıfına atama yapmak derleyicinin hata üretmesine neden olabilir (Explicit ve Implicit terimlerine yabancı iseniz buradaki makalede ilgili başlığı bulabilirsiniz.). Bunun için AUTOBOX direktifini kullanmamız gerekebilir. Yani aşağıdaki gibi, Delphi’ye ait özel bir tipi, .NET’in object tipine implicit olarak atama yaptığımızda derleyici hata üretecektir.

var
  i: Integer;
  o: &Object;
begin
  o := i;

Derleyicinin hata üretmemesi için ya AUTOBOX kullanacağız ya da explicit casting uygulayacağız:

var
  i: Integer;
  o: &Object;
begin
  o := &Object(i); //Explicit casting
  {$AUTOBOX ON}
  o := i;

Buradan çıkardığımız sonuç, her halükarda eğer .Net ortamından söz ediyorsak, ister Delphi tipi olsun ister olmasın, herşey &Object (System.Object) sınıfından türemiştir. Ve bir şekilde tüm tipler, object nesnesine atanabiliyor.

Biz bu bilgiliyi kullanarak sınıflarımızı ve metodlarımızı bir çok noktada genelleştirebiliriz. Mesela VCL’den hatırlayacağınız TList sınıfına benzer bir liste sınıfı hazırlayabilir ve object‘in yukarıdaki anlattığımız özelliği sayesinde içinde istediğimiz tipte nesneler barındırabiliriz. System.Collections alanında bulunan Queue(kuyruk) sınıfı da bu tarz bir yapıya sahiptir(Kuyruğa ilk giren ilk çıkar.). Mesela aşağıdaki örnekte iki farklı tipi Queue nesnesinin bir elemanı yapıyoruz.

uses
  System.Collections, System.Xml;
  ...

{$AUTOBOX ON}
var
  b: TButton;
  s: XmlDocument;
  q: Queue;
begin
  q := Queue.Create();
  b := TButton.Create(nil);
  x := XmlDocument;
  q.Enqueue(b);
  q.Enqueue(x);

Queue sınıfının Enqueue metodu, kuyruğa yeni bir object eklemeye yarar. Enqueue metodu object tipinde parametre aldığından her çeşit nesne bu metod ile kuyruğumuza eklenebilir. Bu örneğimizde TButton ve XmlDocument tipinde iki farklı nesneyi kuyruğa ekledik. Kuyruktan bir eleman çıkarmak için ise Dequeue metodunu kullanmamız gerekecektir. Dequeue metodu da aynen Enqueue metodu gibi object nesneleri ile çalışır. Yani Dequeue metodunun çıktısı bir object olacaktır. İşte bu noktada, object sınıfının özelliğinden dolayı Queue sınıfı ve bu iki metodu genel çapta kullanılabilir bir yapıdadır.

Yukarıdaki kodlara şunları ekleyip derlemeye çalışalım:

var
  ...
  ...
  cikanB: TButton;
  cikanX: XmlDocument;
begin
  ....
  ....
  cikanB := q.Dequeue; //ilk button girmişti, ilk de o çıkacak.
  cikanX := q.Dequeue;

Bu kodu derlemeye kalkdığınızda “Incompatible types…” hatasını alacaksınız. Halbuki yukarıda AUTOBOX ile implicit çevirimi aktifleştirmiştik. Peki bu hatayı neden aldık?

Birincisi, AUTOBOX sadece object nesnelerine atama yapılacağında işe yarıyor, object nesneleri başka bir nesneye atama yapılacağında değil. Object sınıfndan türemiş olan bir sınıfın nesnesi object‘e atama yapacağınızda, derleyici bunu otomatik çevirebilir. Ama aksi durumda, object nesnesinin hangi sınıftaki bir nesneye dönüşeceğini kestiremez. Bu durumda explicit çevirim yapmak zorundayız. Bunun için sondaki iki satırı şu şekilde değiştirmeliyiz:

  ...
  cikanB := TButton(q.Dequeue);
  cikanX := XmlDocument(q.Dequeue);
  ShowMessage(cikanX.Name); //"#document"

Peki kuyruktan çıkış sırasını yanlışlıkla değiştirseydik ne olurdu? Biliyoruz ki, kuyruk’ta ilk giren ilk çıkar. Yani örneğimize göre ilk olarak button girmişti ve ilk olarak da o çıkacaktır. Bu durumda sıralarını değiştirelim deneyelim:

  ...
  cikanX := XmlDocument(q.Dequeue);
  cikanB := TButton(q.Dequeue);
  ShowMessage(cikanX.Name);

Bu kod derlenir fakat çalışma anında yanlış yaptığımızı gösteren bir hata alırız. Bu durumda object sınıfının bu genelleştirme özelliğini, bunun gibi yerlerde kullanmak, bir çok yanlışı ve dikkatsizliği de beraberinde getiriyor.

Genelleştirilmiş sınıf ve metodlar oluşturmak için kullanılan bu object yaklaşımının diğer bir dezavantajı ise, object sınıfının diğer bir nesneye çevirim yapılması(unbox işlemi ya da unboxing de denilir) yada başka bir sınıfın object sınıfına çevirim yapılması(box ya da boxing yapılması) esnasında gereken ek hafıza ve işlemci zamanıdır. Yani her defasında Enqueue yapıldığında bir nesne object tipine dönüştürülecek ve her Dequeue yapıldığında ise object nesnesinin tipi başka bir nesneye dönüştürülecektir. Bu da ek işlem gücü ve hafızayı gerektirir.

Sınıfları ve metodları genelleştirmede object yaklaşımının belki başka dezavantajlarda sayılabilir ama, bizim işimiz burada generics ve parametrize tipler. Object yaklaşımı kafamızın bir köşesinde yer etmişken, dilerseniz generics yaklaşımına bir göz atalım.

Generics ve Parametrize Tipler(Parameterized Types)

Aslında Delphi programcıları bunu çok uzun süreden beri bekliyorlardı. Belki de .NET 2.0′a böyle bir özellik gelmeseydi, uzun bir süre daha Delphi böyle bir özellikten yoksun kalacaktı. Borland ya da CodeGear’ın .NET ortamına yaptığı yatırımları eleştirenler olmuştur. Fakat bu yatırımlar sayesinde hem Win32 hem de .NET üzerinde Delphi bir çok yeniliğe gitmiştir. Buradaki makaleden bu yeni özellikleri kısaca tanıyabilirsiniz.

Gramere ve kullanışına geçmeden önce bir kaç terim üzerinde duralım. Terimler ilk başta kafa karıştırıcı gibi gelse de bu terimleri kullandıkça alışacağınıza inanıyorum. Bu terimleri önce veriyorum çünkü makale içerisinde bu terimler kullanılacak.

Terminoloji

Parametrize Tip (Parameterized Type:): Tip Paremetresine ihtiyaç duyan bir çeşit tiptir. Generic tip, parametrize tipin daha çok bilinen ismidir. Ama literatürde ikisi de kullanılmaktadır. Aşağıdaki kodda “Liste<eleman>” sınıfı, bir parametrize tiptir.

type
  Liste<eleman> = class
    ...
  end;

Tip Parametresi (Type Parameter): Bir parametrize tip veya metod başlık tanımlamasında, parametrize tipin veya metodun kodlarında kullanılacak olan bir tipi ifade eden bir parametredir. Daha sonra bu parametreye bir tip argümanı bağlanacaktır. Aşağıdaki kodda “eleman” bir tip parametresidir ve sınıfın kodlarında kullanılacak olan bir tipi ifade eder.

type
  Liste<eleman> = class
    ...
  end;

Oluşturulmuş Tip (Instantiated Type, Constructed type): Parametre kümesi tanımlanmış olan bir parametrize tiptir. Liste<Integer> gibi…

Tip Argümanı (Type Argument): “Oluşturulmuş” bir tip yapmak için gereken bir çeşit tiptir. Mesela Liste<Integer> bir oluşturulmuş parametrize tip ise, Integer bunun tip argümanıdır.

Kapalı Oluşturulmuş Tip (Closed Constructed Type): Bir parametrize tipin tüm parametreleri, gerçek tip olan argümanlar ile çözümlenmiş ise bu tipe, Kapalı Oluşturulmuş Tip denir. Liste<Integer> kapalıdır, çünkü Integer tip argümanı gerçek bir tiptir.

Açık Oluşturulmuş Tip (Open Constructed Type): Eğer bir parametrize tipin en az bir parametresi bir tip parametresi ise, bu tip bir açık oluşturulmuş parametrize tiptir. Ayrıca eğer Liste<T> parametrize tipinde T parametresi bir sınıfı içeren parametre ise Liste<T> açık oluşturulmuş bir tiptir. İleride örnekler yaptığımızda bu daha da pekişecektir.

Oluşturma İşlemi (Instantiation): Derleyici, parametrize tiplerde tanımlı metodlar için gerçek işlem kodunu oluşturur ve kapalı tipler için gerçek virtual metod tablosunu oluşturur. Bu işlem ön derleme esnasında gerçekleşir. Bu işlem Win32′de *.dcu ve *.obj dosyalarını çıkarırken gereklidir. Fakat .Net ortamında gerekli değildir. Çünkü .Net oluşturulmuş tipler için gerekli tanımlamalara sahiptir. Bu yüzdendir ki, C++’da template oluşturduğunuzda, derleyici ilk başta template’li tipleri ayrı ayrı oluşturmak için ön derleme işlemine girişir. Anlaşılan o ki, Delphi’nin bir sonraki versiyonunda da Win32′de generics desteği verebilmek için buna benzer bir yönteme gidilecek. Her neyse…

Bunlar dışında bir kaç terim daha var. Fakat daha fazla kafa karıştırmamak için, o terimleri ayrı başlıklar halinde ileride görelim. Dilerseniz önceden object yaklaşımı ile yaptığımız işlemleri şimdi de generics ile yapmaya çalışalım.

Kullanımı

Kuyruk örneğimizi hatırlayacak olursanız, ekstradan tip çevirim işlemleri yapmıştık. Ayrıca tip güvenliğinin gerekli olduğundan ve bir dikkatsizlikte belli sorunların oluşabileceğinden bahsettik. Ayrıca fazladan gerçekleştirilen object’den bir başka tipe ve daha sonra da o tipden tekrar object’e çevirim yapılmasından dolayı(box / unbox), ekstra hafıza ve işlem gücü gerektiğinden bahsetmiştik.

Bütün bunlara gerek duymadan, genelleştirilmiş sınıflar oluşturabilmek için parametrize tipleri ve generic yapısını kullanabiliriz. Generic sınıflar, tip parametresine sahip olduğundan dolayı, sadece object gibi bir tipe bağlı kalmaz. Böylece yukarıda bahsettiğimiz sıkıntıları da bertaraf etmiş oluruz.

.Net 2.0 ile birlikte System.Collections.Generic alan adının altında bir çok yararlı generic sınıf tanımlanmıştır. Aşağıdaki kod parçasında parametrize Queue sınıf ile oluşturulmuş bir Integer kuyruğu ve bir string kuyruğu görmekteyiz.

uses
  System.Collections.Generic;

  ...
  ...

var
  SayiKuyruk: Queue<Integer>;
  YaziKuyruk: Queue<string>;
  Sayi: Integer;
  Yazi: string;
begin
  SayiKuyruk := Queue<Integer>.Create;
  YaziKuyruk := Queue<string>.Create;
  Sayi := 123;
  Yazi := 'Deneme';
  SayiKuyruk.Enqueue(Sayi);
  YaziKuyruk.Enqueue(Yazi);
  ...

Gördüğünüz gibi, ne bir çevirim işlemi var ne de tipler uyuşuyor mu diye bir endişe… “SayiKuyruk” ve “YaziKuyruk” nesnelerinin ikisi de Queue<T> gibi bir parametrize tip’den oluşturulmuş tipten oluşturulmuştur . Terimlerimizde hatırlarsanız “Kapalı oluşturulmuş tip“ten bahsetmiştik. Derleyici bu örneğimizde Queue<T> tipinden iki adet yeni tip oluşturmuştur. Bunlardan birisi Queue<Integer> ve diğeri ise Queue<string> tipidir. Ve ikisi de kapalı oluşturulmuş bir tiptir. Ayrıca iki tip tamamen bir birinden bağımsız iki farklı tiptir!

Bu örnekten ne öğrendik? Özet olarak, bir generic sınıfa atadığımız tip argümanlarına göre(Integer, string, vs..) yeni bağımsız bir tip oluşturuyoruz. Ve bu oluşturulan tip, parametre olarak verdiğimiz argümanlara göre işlem yapıyor.

Önceki Queue sınıfı, sadece object tipinde nesneler ile çalşıyordu. Bu sınıftan sadece bir adet vardı ve oluşturduğumuz nesneler hep aynı sınıftan oluşturuluyordu. Ama generic Queue sınıfında ise iş biraz değişiyor. Artık tanımladığımız farklı tip için ayrı bir sınıf oluşturuluyor. Bu yüzden örneğimizdeki SayiKuyruk ve YaziKuyruk nesnelerinin sınıfları aynı değildir! Derleyici her iki tip argümanı için de ayrı ayrı sınıflar oluşturmuştur. Tip argümanları gerçek tipler olduğu için de oluşturulan bu iki sınıf da kapalı oluşturulmuş tip olmuştur.

Tanımlanması

Generic tiplerin tanımlanması kullanımı kadar kolaydır. Delphi’de sınıflar, interface’ler ve record’lar tip parametreleri ile birlikte tanımlanabilirler. Ayrıca metodlar ve prosedürel tipler de parametrize yapılabilir. Aşağıdaki sınıf tanımlamasına göz önüne alalım:

type
  TBirSinif = class
  public
    procedure BirSeylerYap(Parametre: string); overload;
    procedure BirSeylerYap(Parametre: Integer); overload;
    procedure BirSeylerYap(Parametre: Boolean); overload;
  end;

Sadece bu sınıf ve metodları düşündüğümüzde aynı iş için üç farklı metod tanımlaması yapıyoruz. Ne için? Sadece bir tipin değişmesi yüzünden. Bir de ikinci bir parametre aldığını düşünün. Veya üç, dört… Ne yapacağız? 4′ün 3′lü kombinasyonunu alıp o kadar farklı metod tanımlaması mı yapacağız?

Bunun yerine bu işi derleyiciye bırakıp, biz sadece tipler ile uğraşıyoruz. Yukarıdaki sınıfımızı parametrize olarak yeniden tanımlayalım:

type
  TBirSinif<T, K, L> = class
  private
    FBirOzellik: K;
  protected
    procedure SetBirOzellik(const Value: K);
  public
    procedure BirSeylerYap(Parametre: T);
    property BirOzellik: K read FBirOzellik write SetBirOzellik;
  end;

Gördüğünüz gibi, Integer string gibi değişkenler yerine sınıfa eklediğim tip parametrelerini kullanıyorum. Bu parametrize tipimizde 3 adet tip parametresi mevuct. Gerçi bu örnekte sadece ilk ikisini kullanıyoruz.

Bir genel kültür bilgisi mahiyetinde, ek olarak, bu sınıf derlendikten sonra TBirGenericSinif`3 gibi bir şekle girecektir. Eğer tip parametre sayısı 4 olsaydı, son kısım “`4” olacaktı. Bu yüzden derlenmiş assembly’nizi ya da programınızı reflect ettiğinizde bu tarz şeyler görürseniz şaşırmayın. Her neyse…

Önceden de bahsettiğimiz gibi yukarıdaki TBirSinif sınıfı ile TBirSinif<T, K, L> generic sınıfı birbirinden çok farklı şeylerdir. İsimleri aynı olabilir ama kesinlikle aralarında bir bağlantı yoktur. Aynı şekilde TBirSinif<Integer, string, Boolean> gibi bir kapalı oluşturulmuş sınıf, TBirSinif<string, string, Integer> gibi başka bir kapalı sınıftan çok çok farklıdır ve bağlantıları yoktur. Çünkü derleyici, tip argümanlarına göre tipleri tekrar tekrar tanımlamaktadır.

Generic Metodlar

Sınıflar gibi metodlar ve prosedürel tipler de parametrize olarak tanımlanabilir. Mesela:

type
  TBirProsedur2<T> = procedure(Param1, Param2: T) of object;
  TNormalBirSinif = class
    procedure BirProsedur<X>(Param1, Param2: X);
  end;

procedure TNormalBirSinif.BirProsedur<X>(Param1, Param2: X);
begin

end;

Görüldüğü gibi parametrize olmayan bir tip içinde(TNormalSinif) parametrize bir metod tanımladık. Bunu yaparken aynen sınıflarda olduğu gibi metod isminden sonra tip parametrelerini giriyoruz. Aynı şeyi parametrize olan bir tip içinde de yapabilirdik. Ama burada karar size ait. Eğer generic bir sınıf içinde farklı parametrelerle tanımlamamız gereken metodlar olursa, bu şekilde parametrize edebiliriz. Yani:

type
  TBirSinif<T> = class
    ...
    procedure BirProc<X>(Param1: X; Param2: T);
  end;

Görüldüğü gibi sınıf tanımlamasında X parametresi tanımlı olmadığı halde, metod tanımlamamızda kullanabiliyoruz. Peki bu gibi bir şeyi nasıl kullanacağız?

Farkında iseniz bir kaç paragraf yukarıda verdiğimiz bir örneğin tam bir çözümlemesini yapmadık. Yani:

type
  TBirSinif = class
  public
    procedure BirSeylerYap(Parametre: string); overload;
    procedure BirSeylerYap(Parametre: Integer); overload;
    procedure BirSeylerYap(Parametre: Boolean); overload;
  end;

Bu sınıfta “BirSeylerYap” metodu overload edilmiştir. Bu sınıfı generic yaparken şu şekilde bir tanımlama yapmıştık:

type
  TBirSinif<T> = class
  public
    procedure BirSeylerYap(Parametre: T);
  end;

Burada her bir kapalı tip için sadece bir adet metodumuz olabiliyor. Yani mesela TBirSinif<Integer> gibi kapalı bir sınıf içinde sadece bir adet “BirSeylerYap” metodu vardır ve sadece Integer tipinde bir parametre almaktadır. Halbuki bizim esas yapmak istediğimiz her bir kapalı sınıf içinde overload yaptığımız tiplerin sınırlandırmasını kaldırmak. Sadece bir çeşit metod yerine birden fazla çeşitte parametre alan metodlarımız olması gerekiyor. Bu yüzden metodumuzu genelleştirmek için onu da parametrize ediyoruz:

type
  TBirSinif<T> = class
  public
    procedure BirSeylerYap<X>(Parametre: X);
  end;

gibi… Bu şekilde bir metodun, istediğimiz kadar çeşidini overload yapmadan oluşturabiliriz. Mesela:

var
  BirNesne: TBirSinif<Integer>;
begin
  BirNesne := TBirSinif<Integer>.Create;
  BirNesne.BirSeylerYap<string>('Deneme bir string');
  BirNesne.BirSeylerYap<Integer>(123);
  BirNesne.BirSeylerYap<Boolean>(True);
  BirNesne.BirSeylerYap<TForm>(Form1);
  BirNesne.BirSeylerYap<TButton>(Button1);

gibi…

Gördüğünüz gibi overload ile kısıtlı sayıda yaptığımız metod tanımlamalarını bu şekilde artırabiliriz. Bu da aynen sınıflarda olduğu gibi, metodlarımızı da genelleştirmemize imkan sağlıyor.

Gelecek Bölümde

Gelecek bölümde Sınırlandırıcıları ya da başka yerlede göreceğiniz tabir ile Kısıtlamalar ya da Constraints tabirlerini göreceğiz. Diğer bölüme geçmek için buraya tıklayabilirsiniz.

Her zamanki gibi yorum ve eleştirilerinizi bekliyorum.

Fatih Tolga Ata

Kaynaklar:

• CodeGear’ın Delphi Parametrize Tipler ile İlgili Taslak Metinleri
• .NET 2.0 SDK Yardım Dosyası
• Microsoft Visual C# 2005 Step by Step, John SHARP, 2005 Edition

Bütün bunları geçelim ve generic tiplere yabancı olanlar için bir kaç küçük örnek verelim.

TGenericClass<T> = class
private
  FProperty: T;
public
  property AProperty<T> read FProperty write FProperty;
end;

Basit bir generic sınıf tanımlaması bu şekilde. Bu sınıfı aşağıdaki gibi kullanabiliriz.

var
  AStringClass: TGenericClass<string>;
  AIntegerClass: TGenericClass<Integer>;
begin
  AStringClass := TGenericClass<string>.Create;
  AIntegerClass := TGenericClass<Integer>.Create;

  AStringClass.AProperty := 'Bu bir string';
  AIntegerClass.AProperty := 456;
end;

Burada T parametresi bir tipi ifade etmektedir. İçine koyacağımız tipe göre sınıfımız kendini şekillendirmektedir. İstersek sınıfmızı <T, U> gibi birden fazla tip ile tanımlayabiliriz. Önceden de dediğim gibi eğer fikirlerini değiştirmezlerse highlander sürümünde editör, generic tipleri normal bir tip gibi algılıyor. Yani siz <T, U> gibi tanımladığınız generic sınıfınızı kullanırken iki yerine bir parametre kullanırsanız delphi böyle bir tanımlamanın olmadığından felan bahsedecektir. Ama eksik parametre kullanıldığını söylemesi gerekmektedir. Bu da çok karmaşık uygulamalarda sizi şaşırtabiliyor.

Aslında generic tiplerin en çok kullanıldığı yerler belki de kolleksiyon tiplerindedir. Mesela:

var
  AStringList: List<string>;
  AStreamList: List<TMemoryStream>;
begin
  AStringList := List<string>;
  AStreamList := List<TMemoryStream>;

  AStringList.Add('Birinci sıradaki yazı');
  AStringList.Add('İkinci sıradaki yazı');
end;

Bu List<T> sınıfını kullanabilmek için System.Collections.Generic’i uses kısmına eklemelisiniz. Yukarıda gördüğünüz işlem Delphi’de TList ve pointer’lar ile yaptığımız işlemleri daha basit bir şekilde yapmamıza yarıyor. List dışında, .net kütüphanesi bir çok generic tip barındırmaktadır. Ama şimdilik highlander’da generic’lerin nasıl olacağına dair bu kadar bilgi yeterli. Highlander çıktıktan sonra bununla ilgili bir makale buralarda olabilir.

Yorumlarınızı bekliyorum.