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

Nedir bu Class Helper? Yenilir mi, içilir mi, grameri nasıldır, ne işimize yarayacak? Bütün bu soruların cevaplarını bu kısa makalemizde vermeye çalışacağız.

Giriş

Hemen konuya girelim. Class Helper -yada sınıf hizmetçisi, ya da yardımcısı-, kendisinde bulunan bütün alanlarıyla, yardımcı olduğu sınıfı genişleten bir yapıdır, şeklinde tanımlanabilir. Class helper, mevcut bir sınıfı değiştirmeden veya bu sınıftan yeni bir sınıf türetmeden, bu sınıfa yeni özellikler, metodlar katmaya yarar. Böylece mevcut sınıfta hiç bir müdahaleye gerek kalmadan ve yeni bir sınıf türetmeden, mevcut sınıfımız istediğimiz şekilde şekillenecektir.

Borland bu yapıyı, VCL kütüphanesini .NET ortamına geçirirken ihtiyaç duymuştur. Çünkü Win32′de tanımlanmış olan bir sınıf, hem .Net’i desteklemesi lazım hem de mevcut yapısını koruması lazım. İşte class helper, nesne programlamaya böyle bir esneklik getirmiştir.

Grameri

Şimdi bu yapının grameri nasıldır ona bakalım:

TSinif = class
public
  procedure BirProsedur;
end;

TSinifYardimcisi = class helper for TSinif
public
  function BirFonksiyon: Boolean;
end;

Ardından bu sınıfımızdan bir nesne oluşturalım:

var
  Nesne: TSinif;
begin
  Nesne := TSinif.Create;
  Nesne.BirFonksiyon;
end;

Farkında iseniz TSinif adlı sınıfımızda "BirFonksiyon" isimli bir fonksiyon bulunmamakta. Ama bir class helper tanımlayarak, olmayan bu fonksiyonu sınıfımıza ekledik.

Yanlış Kullanımlar ve Sınırlar

Nasıl ki programlamada her tekniğin bir yapabildiği olduğu gibi, tekniğe ters olan bazı şeyler de vardır. İlk önce yanlış kullanımlara bakalım:

• Mevcut .NET sınıflarını, kod tanımlamasını değiştirmeden genişletmeye çalışmak.
• Mevcut .NET sınıflarını onlardan miras almadan genişletmeye çalışmak.
• Sealed sınıfları genişletmeye çalışmak. (Sealed sınıflar, sınıf hiyerarşisinde kısır sınıflar olarak bilinirler. Yani sealed sınıflardan herhangi bir başka sınıf türetilemez.)
• Büyük bir sınıf tanımlamasını birden fazla kaynak dosyaya rast gele bir şekilde bölmek.

Her ne kadar bunları yapabilseniz de, tavsiye edilmez ve yanlış kullanım kategorisindedir. Özellikle bir sınıf sealed olarak tanımlanmışsa, bunun elbette bir sebebi vardır. Bunu genişletmek, istenmeyen sonuçlara sebebiyet verebilir.

Yapamayacağınız şeyler ise şunlardır:

• Bir class helper, genişlettiği sınıfın "strict private" olarak tanımlanmış alanına erişemez. Gerçi Delphi programcıları için bu, ne kadar doğru bir sınırlandırma olduğu tartışma konusu olmuştur ve olmaktadır.
• Bir class helper, genişlettiği bir sınıf için interface tanımlayamaz.
• Bir class helper için başka bir class helper tanımlanamaz.

Tabi yapılan en büyük yanlışlıklardan bir tanesi de, class helper’ları ayrı dosyada tanımladıktan sonra bunları ana sınıfın unitinde implementation alanında değil de interface alanında uses’a eklemek olacaktır. Bu da çapraz başvurudan dolayı hataya sebep olacaktır. Çünkü eklediğiniz helper unitinde interface alanında zaten uses kısmında ana sınıfın uniti eklenmiş durumdadır. Bu esasen class helper’larla alakalı bir hata olmadığından yukarıdaki maddelere eklemedim.

Faydaları

Eğer birden fazla kişi aynı sınıf üzerinde çalışıyorsa, class helper’lar gerçekten çok işe yaramaktadır. Class helper kullanılmadığında, bir çok programcının yazdığı sınıfları bir sınıfta birleştirmek için bir kişinin uğraşması gerekmektedir. Bunu yapacak kişi de her yazılan sınıftaki özellik ve metodlara aşina olması şarttır. Class helper kullanıldığında, her programcı, sınıf içinde kendine ayrılmış kısım ile ilgili bir class helper yazar ve bir unit’e kaydeder. Geriye kalan sadece bunları uses’a eklemek ve derlemektir. Derleme işleminde, derleyici bu class helper’ları mevcut sınıfa ekleyerek birleştirip bir sınıf yapacaktır.

Eğer sınıfınız bazı özel araçlar ile oluşturulmuş ise, class helper kullanarak bu oluşturulmuş olan kodda değişiklik yapmanıza gerek kalmayacaktır. Çünkü bu araç ile bir daha kodu üretmeniz gerektiğinde yazdığınız değişikliklerin kaybolmasına sebep olacaktır. Class helper kullanmadan bu tarz bir koda müdahale etmeniz zordur.

Düşünün ki, ürettiğiniz yazılımın bir kaç versiyonu olacak. Mesela profesyonel, standart, temel(basic) gibi versiyonlarınız olacak. Profesyonel’de olan özellikler standart’a göre daha fazla olacak. Standartta olan özellikler de temel versiyona göre daha fazla olacak. Class helper kullanmadığınızda bu versiyonları oluşturmak için ayrı ayrı sınıflar oluşturmalısınız. Bu durumda temel sınıftaki bir özellik veya metodun değişmesi, bug’ların giderilmesi gibi işlemlerde aynı şeyleri hepsi için tek tek yapmalısınız. Birini birinden türetseniz dahi, mesela temel sınıfı ata sınıf kabul edip, diğerlerini ondan türetseniz dahi bu işinizi görmeyecek hatta daha da sıkıntılı bir duruma sokabilecektir. Çünkü nesnelerin kullanımı esnasında, ister istemez bir çok sorunla yüzleşeceksiniz. Bu sorunları çözmek için ek arayüzler ve sınıflar tanımlamak zorunda kalabileceksiniz. Halbuki class helper kullanıldığında sadece en temel olan sınıfı yazarsınız ve diğer sınıfları class helper olarak tanımlarsınız. Böylece mesela programın temel sürümünü derlemek için profesyonel ve standart class helper’larını projeden çıkarmanız yeterli olacaktır. Profesyonel sürümünü derleyeceğinizde ilgili class helper’ı projenize eklersiniz ve her şey bir çırpıda halledilmiş olur.

Belki faydaları daha da artırılabilir. Ama kafanızda bir fikir oluşması için bunlar yeterli.

(Güncelleme): Class Helper Önceliği

Anlatmayı unuttuğum bir kısım şimdi aklıma geldi

Diyelim ki şöyle bir sınıf ve class helper olsun:

TSinif = class
private
  procedure MesajGoster;
public
  procedure BirSeylerYap;
end;

TSinifHelper = class helper for TSinif
public
  procedure MesajGoster;
end;

Gördüğünüz gibi hem sınıfta hem de helper sınıfta da aynı isimde bir metod var. Ama sınıfta private olarak tanımlanmış bir metod, helper’da public olarak tanımlanmıştır. Peki burada hangisi geçerlidir? "MesajGoster" metodu tetiklendiğinde hangi metod çalıştırılacaktır? Aşağıdaki koda bakalım:

procedure TSinif.BirSeylerYap;
begin
  MesajGoster;
end;

TSinif’ ta bulunan "BirSeylerYap" metodumuzu bu şekilde yazdık. BirSeylerYap metodu çalıştığında, "MesajGoster" metodunu çağıracak. İşte burada çağrılacak olan daima önceliği fazla olan helper sınıftır. Yani burada TSinif.MesajGoster değil, TSinifHelper.MesajGoster metodu çağrılacaktır. Yani öncelik daima helper sınıfa aittir.

Peki iki helper sınıf arasındaki öncelik neye göre belirlenir? Mesela yukarıdaki sınıfa ve helper’a ek olarak şunu da yazsa idik:

TSinifHelper2 = class helper for TSinif
public
  procedure MesajGoster;
end;

TSinif isimli sınıfımızın MesajGoster metodu çağrıldığında hangi metod çağrılacaktır?

Bundan önce class helper’ların daima sınıflardan öncelikli olduğunu gördük. Bu yüzden sınıfı eliyoruz. Diyelim ki TSinifHelper , TSinifHelper2′den daha önce yazılmış, yani daha yukarıda yazılmış. Bu durumda hangisi en sonra ya da en altta tanımlıysa onun sözü geçer. Yani en son tanımlanan helper daha önceliklidir.

Bir öncelik daha kafamızı karıştırabilir. Diyelimki TSinifHelper, untHelper1 adlı dosyada ve TSinifHelper2 ise untHelper2 adlı dosyada. Bu durumda hangisi daha öncelikli olacak? Bu öncelik değeri, aslında bir önceki ile aynı mantıkta. Hangisi uses kısmında en sonda ise o önceliklidir.

Sonuç

Bence, Delphi.NET ile birlikte gelen en iyi özelliklerden birisi class helper’lar. Özellikle takım çalışmasında büyük bir kolaylık sağlıyor. Sınıfın bir kısmını bir kişi, diğer tarafta sınıfın diğer kısmını yazan kişilerden habersiz görevini yerine getirebiliyor. Belki ilk başta klasik sınıf bilgimizden biraz garip gelebiliyor ama kullandıkça, ne kadar yararlı olduğunu görebiliyoruz.

Sorularınız olduğunda buradaki yorum kısmına ya da delphiturkiye forumlarında Delphi.Net kısmına iletebilirsiniz.

Kolay gelsin.

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.

Firebird .NET Data Provider

Yapacağımız ilk iş buradaki adresten Firebird .NET Data Provider’ı indirmek olacak. Eğer daha önceden Firebird’ü indirip kurmamış iseniz, onu da indirip kurmanız gerekmete. Ben bu makalede farklılık olsun diye embedded tipi veritabanı kullanacağım. Ama server/classic db ile aralarında fazla bir fark yok. Data Provider’ı indirirken dikkat etmeniz gereken nokta Delphi’nin desteklediği .net sürümü ile data provider’ın aynı olması. Bu makalede Delphi 2006 kullanacağım ve Delphi 2006 .Net 1.1 ile çalışıyor. Bu yüzden .Net 1.1 için gerekli olan Data Provider’ı indirip kurdum.

Data Provider’ı Delphi’ye Ekleyelim

Eğer Data Provider’ı indrip kurmuş iseniz, Firebird assembly’lerini Delphi’ye ekleyebilirsiniz. Bunun için menüden Component/Install .NET Components seçeneğini tıklayalım.

Listeden FbCommand, FbCommandBuilder, FbConnection, FbDataAdapter bileşenlerini seçelim. Normalde kategori olarak "General" gözükebilr. İsteğe göre daha sonra bu bileşenleri "Firebird" isimli bir kategoriye alabilirsiniz.

Eğer bu bileşenleri göremiyorsanız, kategori kısmına Firebird yazalım ve "Select an Assembly" tuşuna basarak "C:\Program Files\FirebirdNETProvider XXX"altından "FirebirdSql.Data.Firebird.dll" dosyasını seçelim. Bileşenleri seçtikten sonra onaylayıp kapatalım.

WinForms ile Örnek Bir Uygulama

Yeni bir "Windows Forms" uygulaması açalım. Firebird bileşenlerini Bileşen Paletinde belirlediğiniz kategori altında görünecektir. Eğer General kategorisinde ise "Firebird" isminde yeni bir kategori açıp bu kategori altına bileşenleri taşıyabilirsiniz.

Form üzerine bir adet FBDataAdapter ekleyelim. Karşımıza Configuration Wizard çıkacak. Next tuşuna basıp diğer sayfaya geçiyoruz.

"New Connection" tuşuna basalım. Karşımıza "ConnectionString Editor" gelecek.

Database kısmına db dosyasının yolunu girelim. Server Type olarak ben "Embedded" kullandığım için bu şekilde seçtim. Ama siz Superserver/Classic seçebilirsiniz. Eğer benim gibi Embedded Server kullanıyorsanız, fbembed.dll dosyasının ismini değiştirmeden, "C:\Program Files\Borland\BDS\4.0\Bin" klasörü altına fbembed.dll, firebird.conf, firebird.msg, aliases.conf, ib_util.dll, icu***.dll dosyalarını kopyalamalısınız. Ayrıca bu dosyalar proje dosyanızı kaydettiğiniz yerde de bulunmalı. İsteğe göre System32 klasörü de kullanılabilir ama ben bu şekilde tercih ediyorum.

Eğer db içinde Unicode kullanıyorsanız charset için UNICODE_FSS’i seçmeyi unutmayın. Å?ifre ve kullanıcı adını da girdikten sonra Test tuşu ile bağlantıyı kontrol edebilirsiniz. Eğer bağlatı başarılı ise Accept tuşuna basıp onaylıyoruz.

Bu işlemin ardından Next tuşuna basıyoruz. Dikkat ederseniz, projemize FBConnection1 isminde yeni bir bileşen otomatik olarak eklendi. Sonraki pencerede, "Use SQL Statements" olarak bırakıp Next diyoruz. Bundan sonra SQL cümleciğimizi oluşturabilmemiz için gereken bir ekran geldi. Buraya aşağıdaki gibi bir SQL cümleciği yazıyoruz.

SELECT * FROM KISILER

"Generate Update, Insert, Delete .." seçeneğini seçersek, sihirbaz bizim için bu sql cümleciklerini de otomatik olarak oluşturacaktır. Ardından Next ve Finish tuşlarına basıp işlemi tamamlıyoruz. Å?u an FbDataAdapter1 ve FbConnection1 form’a yerleşmiş olmalı.

Å?imdi gerekli olan DataSet bileşenini oluşturalım. FbDataAdapter1 bileşenini ister sağ tuş ile, isterseniz seçtikten sonra object inspector altındaki bölümden "Generate DataSet" seçeneğini seçiyoruz.

New bölümüne DataSet nesnemize dsKisiler gibi bir isim veriyoruz. FbConnection1 bileşenimizin ismini dcMyDB, FbDataAdapter1 bileşenini de daKisiler olarak değiştirelim. Eğer önceden oluşturduğunuz bir DataSet’i kullanacaksanız, Existing bölümünden istediğiniz DataSet nesnesini seçebilirsiniz. Tablo seçim bölümünden örnek veritabanımızda bulunan ve DataAdapter bileşenine girdiğimiz SQL cümlesinde tanımlanan KISILER tablosunu seçiyoruz. Tamam’a basıp çıkıyoruz.

dsKisiler isminde (ya da sizin belirlediğiniz bir isimde) yeni bir DataSet bileşeni formumuza eklendi.

Bağlantı bileşenlerimiz bu kadardı. Å?imdi bunu test etmek için form üzerine bir adet DataGrid ekleyelim. DataGrid’i seçelim ve DataSource özelliğini DataSet’imiz olan dsKisiler olarak değiştirelim. DataMember özelliğini de tablomuz olan "KISILER" tablosunu seçelim. Bu işlemden sonra DataGrid tablomuzun içeriğini göstermeye başlayacaktır.

BDP ile Firebird Bağlantısı

Yukarıda yaptığımız işlemler klasik bir ADO.NET bağlantısı idi. Borland, BDP ile ADO.NET’e yeni çözümler getirmektedir. BDP, bir çok veritabanını ekstra bir data provider gerektirmeden bir çok özellikle beraber kullanmanızı sağlıyor. Yukarıda yaptığımız işlemler için Firebird DataProivder gerekli idi. Ama BDP bağlantılarında ekstra bir data provider’a ihtiyacınız yok.

Yukarıda yaptığımız veritabanı bağlantısını şimdi BDP ile yapalım.

Yeni bir WinForms uygulaması açalım. Data Explorer’dan BDP altından Interbase bağlantısına sağ tuşa tıklayalım ve "Add New Connection" seçeneğini seçelim.

İsim olarak "MyDB" yazalım ve onaylayalım. Oluştuduğumuz yeni bağlantıya sağ tuş ile tıklayıp "Modify Connection" seçeneğini seçelim. Database bölümünden database dosyamızı seçelim. Test tuşu ile bağlantımızı test edelim. Eğer bağlantı başarılı ise onaylayıp çıkalım. MyDB bağlantımızın Tables alt bölümünü açarsak bağlantı otomatik olarak açılacak ve veritabanında bulunan tablolar görünecektir.

Å?imdi Tables altındaki "KISILER" tablosunu tutup, formumuza sürükleyelim. Eğer aşağıdaki gibi bir hata alırsanız MyDB bağlantısını tekrar düzenleyin ve bu sefer SQLDialect olarak 1 girin.

"Ambiguous field name between table RDB$RELATION_CONSTRAINTS and table RDB$RELATIONS RDB$RELATION_NAME"

Formumuzda bir adet BdpConnection ve bir adet BdpDataAdepter bilşenleri eklendi. Firebird bileşenlerinde yaptığımız gibi, DataAdapeter bileşenini seçip Object Inspector altından ya da bileşene sağ tuşla tıklayarak "Generate Typed DataSet" seçeneklerini seçin. Gelen pencereyi onaylayıp kapatın. Formumuza DataSet nesnemiz eklenmiş oldu. Bundan sonra önceki örneğimizde olduğu gibi DataGrid’i bağlayabiliriz.

Bdp’nin desteklediği bir çok veritabanı için de bağlantı şekli bu şekildedir. Gerek Firebird bileşenlerini kullanın, gerekse BDP kullanın her halükarda, bir adet Connection, bir adet DataAdapter ve bu DataAdapter’a bağlı olan bir DataSet’e ihtiyacınız olacaktır.

VCL.NET ile Firebird Bağlantısı

Aslında böyle bir şeyden bahsetmeyeceğim. Çünkü VCL.NET bileşenleri içinde Interbase bileşenlerinin aynıları bulunmakta. Eğer VCL kütüphanesinde bulunan Interbase bileşenleri ile Firebird bağlantısı kurmayı biliyorsanız, VCL.NET ile de farklı bir şey yapmayacaksınız.

Örnek uygulamaların kaynak kodlarını buradan indirebilirsiniz.

Kolay gelsin.

Fatih Tolga Ata © 2007

İçindekiler

Giriş

Model Tabanlı Geliştirme

Örnek Uygulama

Bir ECO Modeli Oluşturalım

Arayüzü ECO ile İlişkilendirmek

Verilerin Kalıcılığını Sağlama

Auto Forms

Sonuç

Giriş

Delphi 8 ile birlikte yeni bir framework ile tanıştık: ECO™ (Enterprise Core Object). ECO, model tabanlı geliştirmeye (Model Driven Development) imkan tanıyan bir platformdur. Çok az kod yazarak, belki hiç kod yazmadan uygulama geliştirebildiğimiz bu platform sayesinde, veritabanları, uygulamalar ve arayüzler kolay bir biçimde entegre edilip, yönetilebilir. ECO uygulamaları geliştirmek, zaman kazancı ile beraber üretimin artırılması noktasında size deneyim de kazandıracaktır. Özelikle yazılım şirketlerinin ve bu sektörde çalışanların üretim artırımı noktasında sorunlarını çözeceği aşikardır.

Bu makale serisinde, ilk başta basit olarak modelleme konusuna değinmek istiyorum. Ardından ECO ile basit bir uygulama geliştirip, ECO hakkında genel bir bilgi edinmeye çalışacağız. Devam eden konularda ECO’nun nesne tabanlı programlamayı ne kadar çok bistelştirdiğini anlamış olacağız.

Makaleye devam edebilmek için asgari şunlara ihtiyacınız olacak: ECO kurulu olan sürüm 8 veya yukarısı bir Delphi, basit veritabanları kuracak kadar delphi bilgisi ve ECO’yu öğrenmek için gereken istek.

Model Tabanlı Geliştirme

Bir model, bir şeyin gösterimi ya da tanımıdır. Mesela bir uçak modeli, gerçek bir uçağı göstermektedir. Aynen bunun gibi de bir yazılılm modeli, yazılım geliştirme alanındaki problemleri ve çözümleri özetleyen ve gösteren bir yapıdır. Tabi ki bir çok yazılım projesi için çok çeşitli modeller geliştirilmesi mümkündür. Model ayrıca, takım çalışmalarında geliştiriciler arasında iletişimi basitleştirir. Böylece büyük projelerde geliştiriciler birbirlerini anlamak için kaybedecekleri zamanı işlerine vermiş olacaklardır.

Çok çeşitli modeller tanımlayarak, karmaşık yazılım sistemlerini problem alanıdaki görüntü kümeleri olarak ifade edebiliriz. Bu yapıdaki bir modelin dezavantajı ise, zamanla bir problem tanımını derece derece, metin tanımlamalarından kaynak kod ve veritabanı şemalarına çevirmemizdir. Ki bunları sadece geliştirici ve derleyici anlayabilir. Diğer bir değişle, iş veya meslekî anlayıştan derleyici anlayışına dönüştürmedeki problem, her defasında kodu değiştirmemiz olacaktır. Başkaları tarafından yazılmış kodları anlamak istediğimizde veya anlatmak istediğimizde ise bunları kaynak koddan iş mantığına çevirmemiz gerekecektir.

ECO, el ile yapılan bir çok dönüşüm işlemlerini kaldırmayı sağlıyor. ECO, geliştiriciye iş mantığını daha yakından ifade eden bir problemi modellemesine izin verir. Böylelikle kompleks uygulamaları daha kolay ve rahat bir şekilde anlamamıza ve değiştirmemize imkan tanır.

ECO’da modelleri oluşturduğumuz zaman, sınıflara, İş sınıfları veya Alan sınıfları olarak isim veririz. Çalışma zamanında bunlara İş nesneleri veya Alan nesneleri deriz. Bu isimleri kullanmamızın nedeni, bir işin problem alanındaki nesneleri direk olarak göstermesidir. Mesela bir okul kayıt uygulamasında, iş sınıfı olarak "Öğrenci", "Öğretmen" ve "Ders" olarak tanımlamamız gerekecektir.

Buraya kadar anlattıklarımız daha çok soyut açıklamalardı. ECO ve modellemenin mantığını anlamak için bu kadar bilgi yeter kanaatindeyim. Å?imdi örnek bir uygulamaya geçip, ECO’ nun nasıl çalıştığına göz gezdirelim.

Örnek Uygulama

Bu uygulamamız, basit olarak adres ve telefonları XML dosyasında tutan bir adres defteri olsun. Uygulamamız aşağıdaki özelliklere sahip olmalıdır:

• Å?ahıslar için irtibat bilgilerini tutabilmeli

• Å?irketler için irtibat bilgilerini tutabilmeli

Uygulamamız ile ilgili bu problemleri tanımladıktan sonra uygulamamızı modelleyebiliriz.

Å?ekilde görülen yapı UML(Unified Modeling Language™) diye isimlendirdiğimiz, modelleri ifade etmemize yardımcı olan bir modelleme dilidr. Å?ekil bize, dikdörtgenlerle ifade edilen 3 sınıfı göstermektedir. İrtibat sınıfı şekilde gösterilmese de, abstract(soyutlanmış) bir sınıftır. Baş tarafında ok bulunan çizgiler, Å?ahıs ve Å?irket sınıflarının, İrtibat sınıfından türediğini göstermektedir. Model bize, aşağıdaki iş kurallarını ifade etmektedir:

• Bir İrtibat, bir isme, bir telefon numarasına ve bir de adrese sahiptir.

• Bir İrtibat, Å?ahıs veya Å?irket olmalıdır.

Problem tanınımızı ve buna bağlı model yapımızı oluştuduktan sonra yavaş yavaş ilk ECO uygulamamızı oluşturmaya geçebiliriz. Uygulamayı Delphi 2005 ile yapacağız ama ECO destekli herhangi bir sürümde kullanabilirsiniz.

İşe ilk başta bir ECO uygulaması oluşturmakla başlayalım.

• Menüden File / New / Other.. seçeneğini seçelim.

• Karşımıza New Items penceresi çıkacak. Delphi.NET Projects altından ECO Windows Forms Application seçeneğini seçelim.

• Karşımıza New Application penceresi çıkacaktır. Burada uygulamamız için bir isim verelim ve uygun bir yer seçelim.

Bu adımlardan sonra Delphi, boş bir ECO uygulaması oluşturacaktır. Project Manager’ a baktığınızda normal Delphi uygulamasından farklı olarak fazladan 2 dosya daha göreceksiniz. Biri AdresDefteriEcoSpace.pas ve diğeri CoreClassesUnit.pas.

CoreClassesUnit.pas

Bu unit, ECO uygulamamızda sınıfları oluşturduğumuz UML paketidir. Normalde daha çok paket oluşturulabilir ama biz bu uygulamada varsayılan olarak gelen bu paketi kullanacağız.

AdresDefteriEcoSpace.pas

Bu dosya, uygulamamızın ECO Space‘ini tutar. ECO Space, uygulamamızın çalışma zamanındaki nesnelerini tutar. Diğer bir değişle nesneleri tutan bir taşıyıcıdır. Nasıl ki bir nesne, bir sınıfın örneğidir(instance), aynen öyle de bir ECO Space, bir modelin örneğidir. ECO Space tarafından tutulan nesneler, alanların(domain) özelliklerini ve modelde tanımlı ilişkileri tutar.

Bir nesne taşıyıcısı olarak ECO Space, hem iş gören içerik hem de önbellektir. ECO Space’in içindeki Persistence Mapper denen bileşen, XML dosyası, RDBMS gibi Persistence Katmanı ile modelde tanımlı sınıfların arasında bir kanal veya bir köprü olarak kullanılmaktadır. İlerleyen bölümlerde burayı daha iyi kavrayacağız.

Bir ECO Modeli Oluşturalım

ECO, modelleme dili olarak UML’i kullanır. En çok kullanılan bölümleri Class Diagram ve Object Constraint Language (OCL) ‘dir.

Å?imdi önceki oluşturduğumuz AdresDefteri uygulamasına geçelim. ModelView penceresi altından CoreClasses‘ a çift tıklayalım. Bundan sonra modelleme arayüzü karşımıza çıkacaktır. Bununla birlikte "Tool Palette" penceresinin de değiştiğini göreceksiniz.

Yeni bir sınıf oluşturabilmek için ister Tool Palette’i isterseniz de modelleme alanına sağ tuş ile tıklayarak gelen menüyü kullanabiliriz. Å?imdi Modelleme alanına yeni bir sınıf (ECO Class) ekleyelim. İsim olarak da "İrtibat" girelim. Ne olursa olsun .NET programlamada Türkçe karakter serbesttir. .NET unicode tabanlı olduğu için Delphi’de buna uyum sağlamışa benziyor. Her neyse, bu sınıf seçili iken Object Inspector’dan Abstract özelliğini True yapalım. Çünkü bu sınıfımız Abstract’dır(soyut). Abstract sınıflar ile ilgili makalenin başlarında bir açıklama kutucuğu bulabilirsiniz.

Oluşturduğumuz bu sınıfa bir Attribute (özellik) ekleyelim. Bunun için yeni oluşturmuş olduğumuz İrtibat sınıfımızı gösteren dörtgene sağ tuş ile tıklayıp Add / Attribute seçeneğini seçelim. Name özelliğine İsim (Türkçe karakter serbest) ve Type özelliğine de string girelim. Sınıfımızın son hali şu şekilde olacaktır.

Ardından "Telefon" ve "Adres" için de Attribute ekleyelim.

Å?ahıs ve Å?irket adı ile iki tane sınıf daha oluşturalım. Ama bu sınıflar İrtibat sınıfından türeyeceği için Abstract özelliğini False olarak bırakalım. Å?imdi aşağıda gösterildiği gibi Å?ahıs sınıfı ile İrtibat sınıfı arasında ilişki kuracağız. Bunun için Tool Palette’de bulunan Generalization / Implementation aracını kullanıyoruz.

Aynı ilişkiyi Å?irket sınıfı içinde yapalım. Böylelikle Å?irket ve Å?ahıs sınıfları İrtibat sınıfından türemiş sınıflar oldular. Eğer nesneye dayalı programlama mantığını biliyorsanız bu kısmı çok rahat anlamışsınızdır. Diğer bir değişle İrtibat sınıfında bulunan bütün özellikler Å?ahıs ve Å?irket sınıfında da bulunacaktır. Modelimiz en son hali ile şu şekli alacaktır:

ModelView penceresine göz gezdirdiğimizde eklediğimiz sınıfları görebiliriz. Ayrıca CoreClassesUnit altında da bazı sınıfları görebiliriz.

Görüldüğü gibi iki tip model yapımız var. Domain Model yapısında direk olarak bizim oluşturduğumuz sınıflar mevcut. Implementation Model ise, ECO tarafından otomatik olarak kod üzerinde oluşturulan gerçek Delphi sınıflarıdır.

Arayüzü ECO ile İlişkilendirmek

Modelimizi tamamladığımıza göre kullanıcı arayüzünü hazırlamaya geçebiliriz.

Önemli: Bu aşamadan sonra projemizi derlememiz gerekmektedir. Çünkü arayüz tasarımcısı model bilgilerini alabilmesi için derlenmesi gerekmektedir. ECO’ nun çalışma düzeneği, .Net Reflection üzerine kuruludur. Reflection için projemizi derlememiz gerekmektedir. Å?imdi devam etmeden önce elimizi F9′a götürelim…

Å?imdi WinForm’ a geçelim. Forma 2 adet button, 3 adet DataGrid ve Enterprise Core Objects kategorisinden 3 adet ExpressionHandle ekleyelim. Butonlarından birini btnÅ?irketEkle, diğerini de btnÅ?ahısEkle olarak isimlendirelim. Text özelliklerini de "Å?ahıs Ekle" ve "Å?irket Ekle" olarak değiştirelim. ECO uygulaması oluşturma sihirbazı form üzerine bizim eklediklerimiz dışında bir kaç bileşen ekler. Bunlar arasında rhRoot isimli ReferenceHandle bileşeninin EcoSpaceType özelliğini bizim EcoSpace’imize bağlıyoruz. Yani buraya:

AdresDefteriEcoSpace.TAdresDefteriEcoSpace

gireceğiz. Bundan sonra eklediğimiz 3 adet ExpressionHandle bileşenini ayarlamamız gerekmektedir. Bu bileşenleri ehİrtibat, ehÅ?ahıs ve ehÅ?irket olarak isimlendirelim. Hepsinin RootHandle özelliğini biraz önce ayarlamış olduğumuz rhRoot yapalım. Å?imdi aşağıda gösterildiği gibi, her bileşenin Expression özelliğini kendi sınıfının allInstance özelliğine ayarlayalım.

Eğer rhRoot bileşenini doğru bir şekilde ayarlamadıysanız muhtemelen resimdeki gibi bir sınıf listesini göremeyeceksiniz. Bir ReferenceHandle bileşeni, tüm ECOSpace’ler içinde belirli bir EcoSpace’i seçmemize yarar. Bu örneğmizde EcoSpaceType özelliği ile AdresDefteri için oluşturduğumuz EcoSpace’i seçtik.

Forma eklediğimiz DataGrid bileşenlerine dgİrtibat, dgÅ?ahıslar ve dgÅ?irketler isimlerini verelim. Herbirinin DataSource özelliğini de kendilerine ait olan ExpressionHandle bileşenine ayarlayalım. Mesela dgİrtibat için DataSource ehİrtibat olacak. Å?imdi btnÅ?ahısEkle düğmesini çalışır hale getirelim. Bunun için iki seçeneğimiz var. İster kod girerek istersek de kod girmeden. İlk başta herhangi bir kod girmeden herşeyi IDE ile halledelim. btnÅ?ahısEkle düğmesinin özelliklerinden BindingContext özelliğini dgÅ?ahıslar olarak seçelim. Ardından EcoListAction olarak düğmeye basıldığında ne gibi bir işlevi olacağını ayarlayalım. Örneğimizde bu özelliği Add olarak seçeceğiz. RootHandle özelliği olarak da Å?ahıslar sınıfına bağlı ExpressionHandle bileşenini seçelim yani bu örnek için ehÅ?ahıslar. Gördüğünüz gibi kod girmeden işlerimjizi hallettik. Å?imdi de btnÅ?irketEkle düğmesini kod girerek yapalım. Düğmenin OnClick olayına şu kodları ekleyelim:

procedure TWinForm.btnÅ?irketEkle_Click(sender: System.Object; e:  System.EventArgs);
begin
  Å?irket.Create(EcoSpace);
end;

Eğer eksik bir şey yapmadıysak programı çalıştırdığımızda 2 düğmemiz de ekleme işlemlerini yapacaktır.

Verilerin Kalıcılığını Sağlama

Buraya kadar yaptığımız işlemler ile programımız çalışır hale geldi. Fakat eklediğimiz veriler hafızada tutuluyor ve program kapatıldığında da hafızadan siliniyor. Å?imdi bu verileri bir XML dosyasına yazarak kalıcı hale getirelim.

ECO ile beraber 2 basit kalıcılığı sağlayan(persistence) metod bulunmaktadır. Bu metodlardan birisi XML dosyalarına kaydederken diğeri de RDBMS’e kayıt yaparken kullanılmaktadır. Bu örnekde daha basit ayarlandığından dolayı XML dosyalarında kalıcılık gösterilecektir.

ProjectManager’dan AdresDefteriEcoSpace.pas dosyasına çift tıklayalım. Açık değilse Design kısmına geçip, Enterprise Core Object kategorisinden PersistenceMapperXML bileşenini ekleyelim. Bu bileşenin ismine pmXML ve FileName özelliğine de bir dosya ismi yazalım mesela "veri.xml". Eğer Object Inspector’da EcoSpace’imizin PersistenceMapper özelliğine göz atarsak, otomatik olarak yeni eklemiş olduğumuz pmXML bileşenine ayarlandığını görebiliriz.

Å?imdi WinForm’ a geri dönelim ve bir button ekleyelim. Button’nun ismine btnKaydet, ve Text özelliğine de Kaydet girelim. Burada yine iki seçeneğimiz bulunakta. İster kod girerek istersek de kod girmeden kaydetme işlemini yapabiliriz. Kod girmeden yapabilmek için Button’ nun EcoAction özelliğini UpdateDatabase olarak değiştirelim. Programı çalıştırıp yeni bir kayıt ekleyelim ve kayıt tuşuna basalım. Hepsi bu kadar. Programın bulunduğu klasörde xml dosyamızı görebiliriz. Ayrıca her programı çalıştırmada ECO, otomatik olarak xml dosyasını tekrar yükleyecektir. Eğer kod girerek yapmak istersek, sadece button’nun onClick olayına şu kodu yazmamız yeterli olacaktır:

EcoSpace.UpdateDatabase;

Auto Forms

En son olarak bu bölümde Auto Form’ lardan da bahsetmek istiyorum. ECO Shiribazı ile oluşturmuş olduğumuz programımıza otomatik olarak eklenen bileşenler arasında ECOAutoForms bileşenini görebilirsiniz. Bu bileşen sayesinde aşağıda görüldüğü gibi DataGrid üzerine çift tıkladığımızda, ECO bizim için bir düzenleme formu çıkaracaktır. Bu özelliği aktifleştirmek için, herhangi bir DataGrid’in EcoAutoForm özelliğini True yapmamız yeterlidir.

Sonuç

Bu bölümde Model Driven Development kavramını, ECO’ nun OOP ve model programlamaya getirdiği kolaylıkları, basit bir ECO programının yapılışını görmeye çalıştık. İlerleyen bölümlerde ECO ile daha çok haşir neşir olacağız.

Bu makalde yaptığımız örnek programın kodlarını buradan indirebilirsiniz. Ama kaynak kodları sadece takıldığınız yerlerde bakmak şartıyla indirebilirsiniz.

Bu bölüm için bir kaç kaynaktan yararlandım. Başta Delphi 2005′in Help’i çok işimi gördü. Bununla birlikte makalenin taslağı olarak(başlıklar ve konu) Bdn’ deki bir makaleyi örnek aldım. Ama bu makale, onun çevirisi değildir. Makalenin adresi aşağıda bulunmaktadır:

http://www.borland.com/us/products/delphi/tutorial/tutorial1.html

Makale ile ilgili yorum, eleştiri ve sorularınızı bekliyorum.

Fatih Tolga Ata © Eylül 2005

Son Güncelleme: 25 Ocak 2007