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

Bu makalemizde bu yeniliklere değinmeye çalışacağız. Bunlardan bir kısmını önceki makalelerimizde ayrıntılı olarak işlemiştik. Burada sadece bu sitede bahsetmediğimiz kısımlar bahsedilecek ve önceden bahsettiklerimize linkler içerecektir.

Operator Overloading:

Buradaki makalede ayrıntılı olarak işlenmiştir: http://www.diyezon.com/?p=52

Inline Belirleyicisi:

Derleyiciye tavsiye niteliğinde olan bu belirleyici (ya da direktif), fonksiyon ya da prosedürün kod çıktısında, çağrıldığı yere gömülmesini sağlar. Tavsiye niteliğinde diyorum çünkü, eğer prosedür ya da fonksiyon inline yapılmaya müsait değilse derleyici bu direktifi es geçecektir.

Inline yapılmış prosedür ya da fonksiyon, "call", "ret" gibi assembler komutlarına ihtiyacı olmadığı gibi, stack’ın push ve pop ile yedeğinin de alınmasına ihtiyaç yoktur. Çünkü inline yapılan fonksiyon, direk olarak çağrıldığı kısma yerleşecektir. Halbuki normal fonksiyonlarda call komutu ile hafızada başka bir kod kısmına dallanmaktadır. Ve burada stack’ın yedeği alınıp, fonksiyon sonunda yedek tekrar yüklenmektedir. Daha fazla bilgi için (Delphi ve C++ Builder ile Assembler ve Fonksiyon Çağırım Mekanizmaları).

Inline prosedür ve fonksiyonda bu gibi işlemler yapılmadığından kod daha hızlı çalışacaktır. Ama her fonksiyon çağırımında fonksiyon kodları direk olarak çağrıldığı yere yerleşeceğinden, programınızın boyutu biraz büyüyecektir. Tanımlaması normal fonksiyon ve prosedür gibi olup sadece son tarafa inline belirleyicisi eklenir:

procedure MyProc(x:Integer); inline;
begin
    // ...
end;

Strict Private

Sınıf kavramına katılan bu alan tipi, normal private alan gibidir. Tek fark bu alan daha da gizlidir Bu dediğimizin anlaşılabilmesi için private alanın ne olduğu bilinmesi gerek. Tabi ondan önce sınıfların ne olduğunu biliyorsunuzdur umarım(Bileşen Yazım Klavuzunun ilk bölümleri sınıfları anlatmaktadır).

Private sınıflar normalde, aynı unit içindeki başka sınıflar içinden erişilebilir. Strict Private ise gerçekten gizler. Yani aynı unit içinde bile olsa başka bir sınıf strict private alana erişemez.

Strict Protected

Private için geçerli olan durumun aynısı protected için de geçerlidir. Strict Protected ise sadece aynı sınıf ve sınıfın çocukları tarafından görülebilirler. Aynı unit bile olsa başka bir sınıf bu alanı göremez.

Metodlu Record’lar

Artık Recordlar için private, public gibi alanlar tanımlayıp procedure, function, constructor gibi metodlar tanımlayabiliyoruz. Ayrıca property’ler de tanımlanabiliyor. Yani aynı sınıflar gibi…

type
  TMyRecord = record
    type
      TBirTip = Integer; //tip tanımlaması
    var
      BirAlanDegiskeni: TColor;
    class var
      StatikDegisken: Integer;
    procedure BirProsedur();
    constructor Create;
    property Color: TColor read BirAlanDegiskeni write BirAlanDegiskeni;
    class property StatikOzellik: TBirTip read StatikDegisken write StatikDegisken;
  end;

constructor TMyRecord.Create;
begin

end;

procedure TMyRecord.BirProsedur;
begin
  ShowMessage(IntToStr(Color));
end;

Abstract ve Sealed Sınıflar

Önceden abstract sınıf tanımlanamıyordu. Bunun yerine interface’ler kullanılıyordu. Ama bu her zaman işe yaramayabiliyor. Yabancı olanlar için kısaca abstract, kendisinde herhangi bir tanımlama ve kod bulunayan, kod kısmı, sınıflar için çocuk sınıflarda, metodlar için ise mirasçı metodlarda tanımlı olan bir yapıdır.

type
  TAbstractClass = class abstract
    procedure SomeProcedure;
end;

Bu sınıfın kod tanımlaması TAbstractClass sınıfından türeyecek olan sınıflarda yapılacaktır.

Sealed sınıflar ise, kısır sınıflardır. Yani artık sınıf hiyerarşisinde en sonda bulunan ve kendisinden herhangi bir türetme yapılamayacak olan sınıflardır.

type
  TSealedClass = class sealed
    procedure SomeProcedure;
end;

Bu sınıftan başka bir sınıf türetilemez.

Class Helper’lar

Buradaki makalede ayrıntılı olarak işlenmiştir: http://www.diyezon.com/?p=50

Class Statik Tipler, Değişkenler, Özellikler, Sabitler, Metodlar

Bazen olurki nesneyi tanımlamadan, sınıf içinde bulunan bazı değerlere erişilmesini istersiniz. Bu durumda erişilmesini istediğiniz şeyi, statik olarak tanımlamalısınız. Mesela aşağıdaki örneğe bakalım:

type
  TAClass = class
    strict private
      class var
        StatikDegisken: Integer;
    strict protected
      class function GetStatikOzellik: Integer; static;
      class procedure SetStatikOzellik(val: Integer); static;
    public
      class property StatikOzellik: Integer read GetStatikOzellik write SetStatikOzellik;
  end;

TAClass.StatikOzellik := 879;

Burada gördüğünüz gibi TAClass sınıfından bir nesne oluşturmadan içindeki bir özelliğie eriştik. Class Static tekniğini kullanırken dikkat etmeniz gerken bir kaç önemli nokta şudur:

• Statik metod’lar içinde artık Self değişkenini kullanamazsınız. Çünkü sınıfa referans içeren bir nesne yoktur.
• Statik metodlar ve özelliklerde ancak ve ancak statik olan değişken ve metodları kullanabilirsiniz.
• Statik metodları virtual ya da dynamic olarak tanımlayamazsınız.

Bunun dışında bir sınıf içinde statik sabitler ve statik tipler de oluşturulabilir:

type
  TBirClass = class
  private
    type
      TBirStatikRecord = record
        BirAlan: string;
      end;
  public
    class var
      BirStatikRecord: TBirStatikRecord;
    const StatikSabit = 'Burada class kelimesini kullanmanıza gerek yok!!';
  end;

....
ShowMessage(TBirClass.StatikSabit);

gibi…

İç içe Geçmiş Sınıflar – Nested Classes

Artık bir sınıf tanımlamasının içinde başka bir sınıf tanımlanabiliyor:

type
  TDistakiSinif = class
  public
    type
      TIctekiSinif = class
      public
        procedure IctekiMetod;
      end;
      procedure DistakiMetod;
  end;

procedure TDistakiSinif.TIctekiSinif.IctekiMetod;
begin
  ...
end;

Final Metodlar

Sealed sınıflar gibi final metodlar da bir sınıfın çocuk sınıflarında, final olarak tanımlanmış olan virtual metodun miras alınamadığını ifade eder. Mesela:

TSonMetodluSinif = class(TBirAtaSinif)
public
  procedure SonMetod; override; final;
end;

Bu tanımlamadan sonra artık SonMetod isimli metod, "TSonMetodluSinif" isimli sınıfın çocuk sınıfları tarafından override yapılamayacaktır. Final metodların sadece virtual metodlarda işe yaradığına dikkat edin.

For-In Döngüsü

Artık bir dizi veya kolleksiyon içinde for-in döngüsü ile iterasyon yapılabilmekte:

for DiziElemani in BirDizi do
begin
  ....
end;

for BirKarakter in BirString do
begin
  ...
end;

for BirKumeElemani in BirKume do
begin
  ...
end;

for BirKolleksiyonElemani in BirKolleksiyon do
begin
  ...
end;

Sonuç

Yeni gelen özelliklerin unutmamış isem tamamına değinmeye çalıştım. Bunlara ek olarak Highlander çıktığında generic yani parametrize tiplere de ayrı olarak değineceğiz. Generics’in nasıl bir şey olduğunu merak edenler buraya tıklayarak meraklarını giderebilirler.

Bunlarla ilgili uygulama yapıp geliştirmek sizlere kalmış. Buradaki bilgiler önfikir mahiyetindedir. Derleyici bazındaki yenilikler bunlar olmakla birlikte, VCL ve diğer alanlarda da bir çok yeniliğe gidilmiştir. Yeri geldikçe bunlardan da bahsedebiliriz.

Yorumlarınız önemlidir, bekliyorum.

Delphi’ye, belki de çok uzun zaman önce eklenmesi gereken bu özellik ile, herhangi bir sınıf veya record için toplama(+), çıkarma(-), çarpma(*) gibi operatörlere bazı özel anlamlar yükleyebiliyoruz. C++ programcılarının hiç de yabancı olmadıkları bu teknik ile kendimize özel veri tipleri tanımlayıp, bu tiplerin Integer, string gibi başka tipler ile etkileşimlerinin nasıl sonuç vereceğini belirleyebilirsiniz.

Giriş

Delphi programcılarının uzun zamandır en çok yakındıkları ve Delphi derleyicisi tasarımcılarının başını ağrıttıkları belli başlı konular vardır. Birisi şüphesiz parametrize tiplerdir(generics, c++ için STL). Highlander sürümü ile birlikte bu özellik de Delphi’ye kazandırılmış olacak. Diğerleri de nested tipler, class static tipler ve operator overloading olarak sıralanabilir. Parametrize tipler hariç diğerlerini hem Delphi, hem de Delphi.NET için şu anda kullanabiliyoruz.

Bu makalemizde göreceğimiz operator aşırı yükleme veya operator overloading, sınıf ya da record’ların kullanımını büyük bir ölçüde genişletmektedir. Delph.NET için hem record hem de class veri tipleri için operator overloading yapılabilirken, Delphi for Win32 için sadece record veri tiplerinde operator overloading yapılabilir. Ama bu kullanım bakımından o kadar da etki etmemektedir. Hatta çoğu durumda operator overloading için record kullanılmaktadır. Vereceğimiz örnekler sınıflar ile yapılmış olduğundan Delphi.NET ortamında denemelisiniz. Sınıflar ile örnek veriyorum, çünkü recordlar’dan farklı olarak yapılacak fazladan bir kaç işlem var. Mesela record’larda çoğu durumda Result çıkış değeri Record olduğundan, Create ile oluşturmanıza gerek yok.

Ayran’nın Suyu Fazla mı Olmuş, Ne?

Operator overloading’i anlatabilmek için böylesine uçuk sayılabilecek bir örnek seçtim. Belki ayran içtikçe bu konuyu hatırlarsınız

Şimdi 3 adet tipimiz olsun. TAyran, TYogurt ve TSu. TAyran sınıfı içinde hem TYogurt tipinde, hem de TSu tipinde iki adet özelliğimiz olsun. TTuz da olurdu ama şimdilik ayranımız tuzsuz olsun

TYogurt = class
  Miktar: Integer;
end;

TSu = class
  Miktar: Integer;
end;

TAyran = class
  Yogurt: TYogurt;
  Su: TSu;
public
  constructor Create;
end;

constructor TAyran.Create;
begin
  inherited;
  Yogurt := TYogurt.Create;
  Su := TSu.Create;
end;

Şimdi diyelimki TAyran tipimize TYogurt ve TSu tiplerinde ekleme yapılabilsin. Ayrıca TYogurt ve TSu kendi aralarında toplanabilsin. Ayrıca bir de TAyran ile diğer tipler karşılaştırılmaya tabi tutulabilsin. Bu işlemleri siz, ayrı ayrı metodlar tanımlayarak ve bu metodları gerektiği yerde kullanarak gerçekleştirebilirisiniz. Ama operator overloading kullanarak aşağıdaki gibi işlemler yapabileceğiz:

var
  Yogurt: TYogurt;
  Su: TSu;
  Ayran: TAyran;
begin
  Yogurt := 15;
  Su := 5;
  Ayran := Yogurt + Su;
  Yogurt := Yogurt - 5;
  if Ayran > Yogurt then
    ShowMessage('Ayrandaki yogurt miktarı daha fazla');
end;

Nesne oluşturma kısımlarını konumuz dışında olduğu için atladım. Tabi ki bu işlemler, operator overloading olmadan hataya sebep olacaktır. Çünkü bir sınıf tipini kalkıp başka bir sınıf tipi ile topluyorsunuz, sonra bu sınıf tipine Integer ekliyorsunuz ve sonra da başka bir sınıf tipi ile karşılaştırmaya tabi tutuyorsunuz. Dediğim gibi bu işlemleri prosedür ve fonksiyonlarla da halledebilirsiniz. Ama bu işlemleri operator overloding üzerinden yaparsanız, kullanımda yukarıdaki gibi bir kolaylık sağlamış olacaksınız. Şimdi veri tiplerimiz ile yukarıdaki işlemleri gerçekleştirebilmek için gereken operator tanımlamalarını yapalım.

Add ve Subtract

Şimdi TYogurt nesnesi için aşağıdaki tanımlamayı yapalım. Ama ondan önce TYogurt içinde TAyran ve TSu sınıflarına referanslarımız olduğundan ikisi için forward tanımlaması gerekmekte. Çünkü TAyran ve TSu, TYogurt’dan sonra tanımlanmıştır. Her neyse bu zaten nesne programlama konusu. Şu an bizim konumuzla alakası fazla yok.

  TAyran = class; //forward tanımlama
  TSu = class; //forward tanımlama

  TYogurt = class
    Miktar: Integer;
    class operator Add(Yogurt: TYogurt; Su: TSu): TAyran; //Ayran := Yogurt + Su
    class operator Add(Yogurt1: TYogurt; Yogurt2: TYogurt): TYogurt; //Yogurt3 := Yogurt1 + Yogurt2
    class operator Subtract(Yogurt1: TYogurt; Yogurt2: TYogurt): TYogurt; //Yogurt3 := Yogurt1 - Yogurt2
  end;

Gördüğünüz gibi üç adet satır ekledik. Bunlardan ilki "+" yani toplama operatorünün üzerine yazar. Bu class statik metod ile Add metodunun üzerine yazmak ile nesnemiz ile yapılacak olan her "+" toplama işleminde bu metod çağrılacaktır. Ama verdiğimiz kriterlere göre… Örneğimizde gördüğünüz gibi iki adet Add operatoru tanımlandı. Bunlardan ilki TYogurt ile TSu değerlerini topluyor ve sonucu TAyran olarak çıktı veriyor. İkincisi ise iki adet TYogurt nesnesin topluyor ve yine TYogurt cinsinden çıktı veriyor.

Buradaki altın kural, eğer iki parametreli operator metodu var ise, tanımlayacağınız operator metodundaki parametrelerden en az birisi işleme girecek olan sınıftan olmalı. İki parametre alan çoğu operator metodları için bu mantık vardır. Bu yüzden bir operator’e overload yapacaksanız, kara kara hangi sınıfta tanımlıyacağınızı düşünmenize gerek yok. Çünkü işleme girecek olan herhangi bir sınıf bu metodun bir parametresi olacağından, işleme girecek olan herhangi bir sınıf içinde bu overload işlemini yapabilirsiniz. Mesela ilk Add tanımlamasını TSu sınıfında da yapabilirdik. Çünkü TSu da işleme girmektedir. Ama artık gerek kalmadı. Çünkü:

Ayran := Yogurt + Su;

gibi bir ifade için bu Add metodu çağırılacaktır.

Tek parametreli operator metodlarında ise aslında mantık ile parametresinin ne olacağını bilebiliyorsunuz. Zaten yanlış bir tanımlama yaptığınızda derleyici sizi uyaracaktır. Operator metodlarının parametreleri dahil tam listesi için yardım dosyasına müracaat etmelisiniz.

En son satırdaki Subtract operator metodu ise "-" çıkarma işleminin görevini görmektedir. Burada gördüğünüz örnekte iki adet TYogurt nesnesi birbirinden çıkarılıp sonuç olarak TYogurt cinsinden çıktı veriliyor. Yani:

Yogurt3 := Yogurt1 - Yogurt2;

gibi.. Şimdi bu metodların kod kısımlarını da verelim.

class operator TYogurt.Add(Yogurt: TYogurt; Su: TSu): TAyran;
begin
  Result := TAyran.Create;
  Result.Yogurt.Miktar := Yogurt.Miktar;
  Result.Su.Miktar := Su.Miktar;
end;

class operator TYogurt.Add(Yogurt1, Yogurt2: TYogurt): TYogurt;
begin
  Result := TYogurt.Create;
  Result.Miktar := Yogurt1.Miktar + Yogurt2.Miktar;
end;

class operator TYogurt.Subtract(Yogurt1, Yogurt2: TYogurt): TYogurt;
begin
  Result := TYogurt.Create;
  Result.Miktar := Yogurt1.Miktar - Yogurt2.Miktar;
end;

Gördüğünüz gibi Result değerlerini her defasında Create ile oluşturduk. Çünkü Result bir nesnedir. Ve Result ile atanacak olan nesne birbirinden farklıdır. İşte record kullanmanın bir yararı da burada. Create ile ikide bir oluşturmanıza gerek yok. Record kullanmanın tek dez avantajı, forward tanımlama yapamamanız. Ama bu sorun, her bir record’u ayrı dosyalara alınarak üstesinden gelinebilir. Ben bununla kafanızı karıştırmamak için sınıf’ları ve forward tanımlamaları kullandım. Ayrıa record’un bir avantajı da sınıf gibi private, public, protected alanlarda prosedür ve fonksiyon oluşturabilmenizdir. Gerçi bu özellik operator overloading ile aynı zamanda Delphi’ye kazandırılmıştır. Her neyse…

Implicit ve Explicit

Şimdi diyelimki TYogurt tipindeki nesnemizi TAyran nesnesine dönüştüreceğiz. Yani TYogurt nesnesindeki miktarı, TAyran üzerine yazacaz. Bunun için TYogurt nesnesine şunu eklemeliyiz:

class operator Implicit(Yogurt: TYogurt): TAyran; //Ayran := Yogurt;

Implicit operator metodu hangi sınıf veya record içinde tanımlanmış ise o sınıf veya record’u metodun Result kısmında bulunan sınıfa dönüştürür. Örneğimiz için bu Ayran değişkene Yogurt’u atamak ile olur. Bu metodun kodları ise örneğimize göre şöyle olabilir:

class operator TYogurt.Implicit(Yogurt: TYogurt): TAyran;
begin
  Result := TAyran.Create;
  Result.Yogurt.Miktar := Yogurt.Miktar;
end;

Eğer sınıf için operator overloading kullanıyorsanız, burada ve diğer tanımlamalarda dikkat etmeniz gereken nokta parametre ile gelen nesneleri direk olarak Result içine atama yapmamanız. Çünkü bu taktirde sınıfın işaretçisini eşitlemiş olursunuz ve işler istemediğiniz noktalara gelebilir.

Explicit operatorü ise mantık olarak aynıdır. Sadece kullanımda fark vardır. Yani yukarıdaki "Ayran := Yogurt" işleminde, kullanıcının böyle kolay bir şekilde eşitlemesini istemeyebiliriz. Yani direk böyle bir eşitleme yaptığında hata yapmış olabileceğini düşündürtmek için bu kullanıma izin vermeyebiliriz. Ve sadece type casting ile tip dönüşümüne izin verebiliriz. İşte bunu bize sağlayan operator Explicit’dir.

"Ayran := Yogurt" eşitlemesini "Ayran := TAyran(Yogurt)" şeklinde yapabilmek için sadece yukarıda yazdığımız Implicit yazan yeri Explicit olarak değiştirin:

class operator TYogurt.Explicit(Yogurt: TYogurt): TAyran;
begin
  Result := TAyran.Create;
  Result.Yogurt.Miktar := Yogurt.Miktar;
end;

Kod aynı kod, ama sadece Implicit yerine Explicit var. Bunu yapmakla artık "Ayran := Yogurt" çevirimi derleyici tarafından hatalı olarak görülecek ve "Incompatible types" yani uyumsuz tipler gibi bir hata verecektir. Böylece kullanıcıyı "Ayran := TAyran(Yogurt)" işlemini yapmaya zorlamış oluyoruz.

Peki neden Implicit’i kaldırdık? Hem Implicit hem de Explicit operatorunu kullanamazmıydık. Kullanabiliridik. Ama Explicit çalışmazdı. Çünkü Implicit daima Explicit’den önceliklidir.

Karşılaştırma

Karşılaştırma işlemleri için bir çok operator vardır. Burada hepsine değinmemiz biraz zor. Sadece makalemizin başında verdiğimiz kodda kullandığımız ">" büyüktür karşılaştırma operatoru için overload işlemini yapalım. Bu sefer dilerseniz TAyran sınıfımızda böyle bir tanımlama yapalım:

  TAyran = class
    Yogurt: TYogurt;
    Su: TSu;
  public
    constructor Create;
    class operator GreaterThan(Ayran: TAyran; Yogurt: TYogurt): Boolean;
  end;

Karşılaştırma operatorlerini overload yaparken dönüş değerinin Boolean olmasına dikkat edin. Bu operator metodunu aşağıdaki gibi kodlayabiliriz:

class operator TAyran.GreaterThan(Ayran: TAyran; Yogurt: TYogurt): Boolean;
begin
  if Ayran.Yogurt.Miktar > Yogurt.Miktar then
    Result := True
  else
    Result := False;
end;

Yada daha kısa ve şık bir birçimde şöyle de olabilir:

class operator TAyran.GreaterThan(Ayran: TAyran; Yogurt: TYogurt): Boolean;
begin
  Result := Ayran.Yogurt.Miktar > Yogurt.Miktar;
end;

İçini nasıl doldurmanız gerektiği size kalmış. Ama burada Yogurt için de büyüktür operatorünü overload yapabilirdik. Bu durumda

Ayran.Yogurt.Miktar > Yogurt.Miktar

yazmak yerine:

Ayran.Yogurt > Yogurt

yazabilirdik. Gerisi size kalmış.

Sonuç

Burada değinmediğimiz bir çok operatöre aşırı yükleme yapabilirsiniz. Bunların tam listesi için yardım dosyasında "Operator Overloading" ile ilgili kısma bakmanız yeterli.

Tabi burada verdiğimiz sınıflar için tek tek operator tanımlaması yaptığınızda ortalık biraz karışabiliyor. Bunların önüne geçmek için operator tanımlamalarını daha çok ata sınıflarda gerçekleştirmelisiniz. Böylece çocuk sınıflarda bu tanımlamaları bir daha yapmak zorunda kalmazsınız. Mesela örneğimizde TSu ve TYogurt sınıflarının her ikisinin de Miktar isminde bir özelliği mevcut. Bu iki sınıfı TSiviMadde gibi "Miktar" özelliği olan bir ata sınıftan türetebilirdiniz. Ve bu operator tanımlamalarını ata sınıf için yapıp, ayrı ayrı TSu ve TYogurt için yapmanıza gerek kalmazdı.

Yorumlarınız önemlidir, bekliyorum.

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.

Ve tavsiyem başka bir bileşen kullanacağınıza kendi bileşeninizi kendiniz yazın! Nasıl mı? Cevabı işte bu makalede…

Öyle bir yazılım geliştirme ortamı düşünün ki, kendi yazdığınız sınıfları tanıyıp kendi bünyesine alabiliyor. Öyle ki, kendi editörleri ile, bilinen bazı tiplerde sınıfınızı daha kolay kullanır hale getiriyor. Ve hatta kendi görsel dizayn aracı ile, sizin sınıfınızı bütünleşik olarak kullanabiliyor. İşte bu geliştirme ortamlarından bir tanesi ve belki de en güçlüsü Delphi’dir.

VCL’de bileşen dediğimiz zaman akla gelen ilk şey, VCL’in tanıyabildiği sınıflardır. VCL’in bir bileşeni tanıyabilmesi için belli başlı kriterler mevcuttur. Bu kriterlerden en önemlisi şüphesiz, nesnenin TComponent sınıfından ya da alt sınıflarından türemesidir.

Öyle ise, VCL’de bir bileşen, sınıf hiyerarşisi TComponent ata sınıfına dayanan nesnelerdir, diyebiliriz. VCL.NET’de de bu olay böyledir. Tek fark TComponent sınıfının nereden türediğidir. Ama bileşen yazıyor isek bu bizi o kadar da çok ilgilendirmiyor. Çünkü TComponent sınıfının ataları ile pek uğraşmayacağız.

Bileşen yazımında bilmemiz gereken iki kavram. DesignTime yani tasarım zamanı, programı derleyip çalıştırmadan önceki tasarım aşamasıdır. Bileşenlerin, özelliklerini değiştirip düzenleyebildiğiniz bu aşamada, bileşenler IDE tarafından kısmen çalıştırılırlar. RunTime yani çalışma zamanı ise, programı derleyip çalıştırdıktan sonraki kısımdır. Bu aşamada IDE, devreden çıkmıştır ve bileşenleriniz çalışmaya başlamıştır. Bu aşamda IDE’nin tek müdahale edebildiği kısım debug işlemleridir.

İleride göreceğimiz belli özellikler ile, DesignTime ve RunTime üzerinde ayrı ayrı işlem yapabileceksiniz. Böylece tasarım zamanında bileşeniniz farklı davranacak, çalışma zamanında farklı davranacaktır.

VCL’in bileşen olarak tanıdığı sınıfların TComponent sınıfından türemesi gerektiğini gördük. Peki bundan sonra olaylar nasıl gelişiyor?

Bildiğiniz gibi iki tip bileşen vardır. Görülebilen(Görsel) ve Görünmeyen(Görsel olmayan) bileşenler.(Türkçeyi –sala bindirip –sele verdiler. Y. Bülent Bakiler)

Görülebilen bileşenler, çalışma zamanında form üzerinde görülebilen bileşenlerdir. Bu bileşenler TControl sınıfından türerler.

Görünmeyen bileşenler ise TControl sınıfından türemeyen herhangi bir TComponent bileşenidir. Normalde sadece DesignTime’da görünürler. Fakat bazı görünmeyen bileşenler, RunTime’da etkileri bulunmaktadır. Ama bunlar çalışma zamanında görünseler bile görülebilen bileşen sınıfına girmezler. Mesela TPopupMenu ve TMainMenu, bu tarz bileşenlerdendir. Her ne kadar bazı makalelerde bu tarz bileşenler kısmi görünür olarak nitelendirilseler de biz bunları da görünmeyen olarak nitelendireceğiz.

Kısacası bileşenleri Görülebilen(Visible) yani TControl sınıfından türeyen bileşenler ve Görünmeyen(Non-Visible) bileşenler yani TControl’den türemeyen bileşenler olarak iki kısma ayırıyoruz.

Tasarım zamanında görülebilen ve görünmeyen bileşenleri ayırmak kolaydır. Böylece hangisi TControl’den türemiş hangisi türememiş anlaşılabilir. Mesela TImage, TButton gibi görülebilen bileşenleri tasarım zamanında görünen şekli üzerinde oynama yapabiliyorsunuz. Ama TTimer bileşeni form’un üzerine eklendikten sonra, bileşeni temsil eden sadece bir kutucuk göreceksiniz.

Dedik ki, TComponent sınıfından türeyen nesneleri, VCL bileşen olarak tanıyabilir. Ayrıca İşletim Sistemi’nin tanıyabileceği sınıflar da mevcuttur. İşletim Sistemi tanıdığı sınıflara kolay ulaşmak için onlara birer numara atar. Bu namaraya Handle diyoruz. Eğer bir bileşenin Handle numarası var ise, bu bileşen İşletim Sistemi tarafından tanınabilmektedir. Herhangi bir programdan bu Handle numarası bilindiği takdirde, ilgili sınıfa ulaşilabilir.

TControl sınıfının iki önemli çocuk sınıfı vardır. Bunlar TWinControl ve TGraphicControl. TWinControl,yukarıda bahsettiğimiz gibi, İşletim Sisteminin tanıyabildiği bileşen türlerindendir. Ve Handle numarasına sahiptir. Bu sınıftan türeyen bileşenler de Handle numarasına sahip olacaklardır. TForm, TButton, TPanel, TCheckBox, TComboBox, TStaticText bu tarz bileşenlerdendir.

TGraphicControl sınıfları ise aksine Handle numarasına sahip değillerdir. Ve İşletim Sistemi, bunları sadece resim olarak görür. TImage, TBevel, TLabel bu tarz bileşenlerdendir. TControl sınıfının, TGraphicControl sınıfından tek farkı, TGraphicControl’de çizim yapabilmeniz için bir Canvas nesnesi tanımlanmıştır.

Öyle ise eğer Görülebilen bileşen yapmak istiyorsak önümüzde iki seçenek bulunmakta. Handle numarası alacak ya da almayacak. Handle numarası alması bileşene ek külfet getirecektir. Eğer Windows API’leri ile bileşen üzerinde işlem yapmayacaksanız, ya da diğer bileşenler ile bu bileşeni etkileşimli bir şekilde kullanmayacaksanız her zaman için TGraphicControl seçiminiz olsun. Ama az önce saydığımız işlemeleri yapacaksanız, bileşeninizin bir Handle numarasına ihtiyacı olacaktır.

Mesela TPanel gibi bir bileşen içine diğer bileşenleri gömecekseniz, bileşeniniz TWinControl‘dan türemelidir. Ya da bileşeninize SetWindowRgn gibi bir api ile değişik şekiller verecekseniz, yine TWinControl sınıfını ebeveyn sınıf olarak kabul etmelisiniz.

Bu örnekler artırılabilir. Bileşen yazımında mesafe katettikçe bu ayrımı yapmak sizin için zor olmayacaktır.

Ayırca TGraphicControl nesneleri, işletim sistemi tarafından tanınmadığı için, Handle numarası olan bir container yani bir taşıyıcı nesneye ihtiyaç duyarlar. Mesela form üzerine bir adet Image ve bir adet Panel ekleyin. Image nesnesi Handle numarasına sahip olmadığından hiç bir zaman panel’in üzerine geçemiyecektir, daima altında kalacaktır. Ta ki, Handle numarası olan bir taşıyıcı nesne içine konulana kadar. Çünkü Handle numarası olmadan işletim sistemi bileşeni tanıyamaz ve hangisinin altta hangisinin üstte olacağını belirleyemez. Aynı şekilde bir Label da Panel, Button gibi bir bileşenin üstüne çıkamaz. Ama StaticText eklediğinizde button’unun üzerine çıkabileceğini göreceksiniz. Eğer altında ise sağ tuşa tıklayıp “Bring to Front” yapabilirsiniz. TStaticText, TWinControl’den türemiştir, TLabel ise TGraphicControl’den türemiştir. Ek olarak, çok luzumu olmadıkça TStaticText kullanılmamalıdır. Çünkü TWinControl sınıfları daha fazla hafıza ve daha fazla işlem gücü gerektirirler.

Bu iki sınıf dışında, bu iki sınıftan türeyen başka sınıflardan da bileşen oluşturabilirsiniz. Mesela TMemo sınıfından türeyen bir başka sınıf yazarak, TMemo’nun mevcut özelliklerinin üzerine yenilerini ekleyebilirsiniz. Ya da TLabel gibi bir GraphicControl sınıfından türeyen bir bileşen yaparak TLabel’a mesela link özelliği ekleyebilirsiniz. Yoksa önceden tanımlanmış bir şeyi tekrar tanımlamanıza gerek yoktur.

Burada bahsedeceğimiz kısım, bileşen yazımında lüzumlu olan bazı nesne işlemleridir. Bu konu hakkında daha fazla bilgi alabilmek için başka makalelere göz atabilirsiniz.

TMyClass = class(TAnchestorClass)
private
protected
public
published
end;

Bu tanımlama, type bloğunda bulunmalıdır. Implementation alanında ise bu sınıfın tanımlamaları bulunacaktır.

Bu örnekte TAnchestorClass sınıfından türeyen bir TMyClass sınıfı tanımladık. Bunun dışında herhangibir method ya da özellik eklemedik.

private alanında, sadece sınıfımızın için kullanılacak olan ve dışarı ile bağlantısı olmayacak olan değişkenler ve metodlar bulunacaktır. Gerek nesne tanımlandıktan sonra, gerekse TMyClass sınıfından türeyen başka bir sınıf içinden, private alanı erişilebilir olmayacaktır.

protected alanı ise yine private alana benzemektedir. Tek fark bu alana sadece çocuk sınıflar erişebilir. Yani TMyClass sınıfından türeyen herhangi bir sınıf protected alanında tanımlanmış olan özellik ve metodlara erişebilecektir.

public alanı, gerek nesne tanımlandıktan sonra, gerekse çocuk sınıf tanımlamalarında görülebilen alandır. Yani private alanın tam ters özellikte bir alandır.

published alanı ise Delphi için özel bir alandır. Bu alan IDE tarafından kullanılabilir olan özellikleri içerir. Bu alana eklediğiniz özellikler IDE’de Object Inspector’da görünecektir. Ayrıca eğer özelliğin kalıcılığı sağlanmış ise, IDE bu özelliğe ait değerleri ve verileri Dfm ya da Nfm dosyaları içine kaydedebilir. Özelliklerin kalıcılığını gelecek bölümlerde bahsedeceğiz.

Bir fonksiyon ya da prosedür tanımlamayı biliyoruz. Sınıf içinde bu tanımlamalar şu şekilde olacaktır.

interface

type
TMyClass = class(TAnchestorClass)
private
protected
public
  procedure MyProc(Param: string);
published
end;

implementation

procedure TMyClass.MyProc(Param: string);
begin
  ShowMessage(Param);
end;

Sınıfımızın oluşturma zamanını ya da yok edilme zamanını kontrol edebilmemiz için iki ayrılmış kelime bulunmaktadır. Constructor ve Destructor. Bunlarda aynen procedure ve function gibi çalışırlar. Tek fark, constructor’lar çağrıldığında sınıfımızından yeni bir nesne oluşturulacaktır. Aynı şekilde destructor çağrıldığında ise nesne yok edilecektir. Object Pascal, istediğiniz kadar constructor ve destructor oluşturmanıza izin vermektedir. Örnek bir tanımlamayı şimdi görelim.

interface

type
TMyClass = class
private
protected
public
  constructor Olustur(Parametre: string);
  destructor YokEt;
published
end;

implementation

constructor TMyClass. Olustur (Parametre: string);
begin
  ShowMessage('Nesne Oluşturuldu. Oluşturma parametresi :' + Parametre);
end;

destructor TMyClass.YokEt;
begin
  ShowMessage('Nesne yok edildi');
end;

var
  MyObject: TMyClass;
begin
  MyObject := TMyClass.Olustur('Nesneden merhabalar');
  MyObject.YokEt;
  ShowMessage('Nesne yok edildi mi ' + BoolToStr(Assigned(MyObject), True));
end;

Genel olarak mecbur olmasanız da standartlaşmış olan bazı isimlendirmeler mevcuttur. Nesneleri oluşturmak için kullanacağınız constructor için “Create” ve yok etmek için kullanacağınız destructor için “Destroy” tabirleri kullanılmaktadır. Bu isimlendirmeler VCL’de önceden beri kullanıldığı için, oluşturulan diğer sınıflarda da bu isimlendirmeler kullanılmıştır. Hem ileride başka bileşenler ile sorun yaşamamak için hem de başka programcılar’ın bileşeninizi rahat kullanabilmesi için standartları takip etmek faydalıdır. Bu yüzden biz de makalemizde constructor için Create ve destructor için Destroy isimlerini kullanacağız.

Delphi’de çok öncelerden beri var olan ve çoğu programlama dillerinin bile yeni yeni sahip oldukları “özellikler”, değişkenlerin farklı bir çeşitidir.

Öyle bir değişken düşünün ki, değişkene veri atamaya kalktığınızda bir metod çalışsın ve değişkenden veri çekmeye çalıştığınızda ise başka bir metod çalışsın yada belirleyeceğiniz bir başka değişkenden veriyi okusun. İşte bu tarz işlemlere izin veren özel değişkenlere “özellik”(property) diyoruz.

property MyProp: Integer read FMyProp write SetMyProp;

Burada bilmemiz gereken 3 önemli alan vardır.

Birincisi özelliğin tipini belirlediğimiz kısımdır. Özelliğe atayacağınız tip, diğer bölümlerde kullanılacak olan metod ve değişkenlerin tipleri ile aynı olmalıdır.

İkinci alan olan read alanına, veri okunacağı zaman nereden okuyacağını bildiriyoruz. Bu örnekte özelliğimizden veri çekilmeye çalışıldığında, veri otomatik olarak FMyProp değişkeninden çekilecektir.

Üçüncü alanımız olan write alanında ise, özelliğimize veri yazılacağı vakit nereye yazılacağını belirliyoruz. Örneğimizde veri, SetMyProp metoduna yollanacaktır.

Önceden de bahsettiğimiz gibi read ve write alanlarına yazacağınız metod ya da değişkenler, özellik ile aynı tipte olmalıdır. Ve özellik tanımlanmadan önce bunların tanımlanması gerekir. Bu tanımlama kısmını örneğimizde göstermedik.

TAraba = class
private
  FMarka: string;
  function GetMarka: string;
  procedure SetMarka(const Value: string);
public
  property Marka: string read GetMarka write SetMarka;
end;

implementation

function TAraba.GetMarka: string;
begin
  Result := FMarka;
end;

procedure TAraba.SetMarka(const Value: string);
begin
  if Value = 'Toyota' then
  begin
    ShowMessage('Toyota markası kabul edilmedi!!');
  end
  else
    FMarka := Value;
    ShowMessage('Şuan ki Marka = ' + FMarka);
  end;
end;

“Marka” isimli özelliğimizde read ve write metodlarında iki adet metod bulunmaktadır. Nesne tabanlı programlamada bu metodlara Getter ve Setter denilmektedir. Önceki örnekten farklı olarak burada hem read için hem de write için metod kullanıldı.

Getter ve Setter metodlarının tanımlamasının illaki private alanda olmasına gerek yok. Ama tavsiye edilen tanımlama, private ve protected alanlarında yapılmasıdır. Eğer alt sınıflarda bu getter ve setter metodlarının üzerine yazmayı planlamıyorsanız, private kısmında bırakabilirsiniz.

Örneğimizi incelediğinizde, Marka özelliğimizden bir değer “okunmaya” çalışıldığında GetMarka fonksiyonu çalışıyor. Ve bu fonksiyonun çıkış değeri Marka özelliğinin de çıkış değeri oluyor. Aynı şekilde Marka özelliğine bir değer atılmaya kalkıldığında, SetMarka prosedürüne değer parametre olarak yollanır. Bu örneğimizde yeni değer Value parametresi olarak SetMarka prosedürüne gelecektir.

“F”, “Get” ve “Set” öneklerini kullanmanız sizin avantajınızadır. Siz bunlara farklı şeyler de verebilirsiniz. Ama bu önekleri kullanarak IDE editörü ile etkileşiminizi artırabilirsiniz. Mesela sadece alttaki tanımlamayı sınıfın public alanına yazın:

property BirOzellik: Integer read FBirOzellik write SetBirOzellik;

Şimdi bu satırıda iken Ctrl+Shift+C tuşlarına basın. Editör otomatik olarak read ve write kısmında yazılı olan değişken ya da metodu sizin yerinize tanımlayacaktır. Editörün otomatik olarak tanımlayabilmesi için değişken(ya da diğer tabir ile “alan”)’ler için “F” öneki, Getter yani read fonksiyonları için “Get” öneki ve Setter yani write prosedürleri için “Set” önekini kullanmanız yeterlidir.

Yukarıdaki örneği şu şekilde çalıştırın ve sonucu gözlemleyin:

var
  BirAraba: TAraba;
  ArabaninMarkasi: string;
begin
  BirAraba := TAraba;
  BirAraba.Marka = 'Subaru';
  BirAraba.Marka = 'Toyota';
  ArabaninMarkasi = BirAraba.Marka;
  ShowMessage(ArabaninMarkasi);
end;

Özelliklerde son olarak değinmek istediğim nokta, sadece okunabilir olan ve sadece yazılabilir olan özelliklerdir.

Sadece okunabilir olan bir özellik için, write alanını kaldırmamız yeterlidir. Aynı şekilde sadece yazılabilir olan bir özellik için de, read alanını kaldırmanız yeterlidir.

property ReadOnlyProp: Integer read FReadOnlyProp; // Sadece okunabilir
property ReadOnlyProp: Integer write FReadOnlyProp; // Sadece yazılabilir

Bundan önce bir sınıftan türetmeyi göstermiştik. Tak yapmamız gereken sınıf tanımlamasında ata sınıfı belirtmektir. Eğer belirtmezseniz, sınıfınız TObject sınıfından türeyecektir.

TCokOzelButton = class(TWinControl)
TCookDegisikResim = class(TImage)
TJanjanliLabel = class(TLabel)

Bildiğiniz kadarı ile, türettiğiniz ata sınıfına ait private alanı hariç tüm alanlardan faydalanabilirsiniz. Bu nesne özelliğine kalıtım diyoruz.

Bir sınıftan türetme yaptığınız vakit, ata sınıfa ait belli bazı metodları tekrar tanımlamak isteyebilirsiniz. Ya da protected olan bazı özellikleri public ya da published yapmak isteyebilirsiniz. Bu durumda, bu özellik ya da metodu kalıtım yolu ile alıp tekrar tanımlamanız gerekmektedir. Metodlar için bu işleme, üzerine yazma(override) ya da inherit(miras alımı) denilmektedir.

TAnchestorClass = class
protected
  procedure BirSeylerYap(Param1: string); virtual;
end;

TMyClass = class(TAnchestorClass)
public
  procedure BirSeylerYap(Param1: string, Param2: Integer); override;
end;

implementation

procedure TMyClass. BirSeylerYap(Param1: string, Param2: Integer);
begin
  //Ata sınıftaki metodu çağırmadan önce yapılacaklar.
  inherited BirSeylerYap(Param1);
  //Ata sınıftaki metod çağrıldıktan sonra yapılacaklar.
end;

Birincisi, ata sınıfta tanımlayacağımız metodun üzerine yazılabilir olabilmesi için virtual ya da dynamic tanımlıyoruz. Aksi halde metodumuz static olacaktır. Ama bu konuya fazla girmiyoruz. Bu kısımda tek söylemek istediğim şey virtual ile dynamic arasındaki farktır. Dynamic metodlar virtual metodlara nazaran daha yavaş çalışırlar ama hafıza kullanımı olarak virtual metodlardan daha az yer tutarlar. Şimdiki işletim sistemlerinde bu fark yok denecek kadar az olduğu için, genelde virtual metodlar kullanılır. Dynamic ve virtual metodların tarihi gelişmesini öğrenmek istiyorsanız ve ayrıntılı bilgi almak istiyorsanız buradan ulaşabilirsiniz.

İkinci olarak, çocuk sınıflarda üzerine yazımak istediğimiz ya da tekrar tanımlamak istrediğimiz metodun tanımlamasından sonra override alan tanımlayıcısını getiriyoruz. Örneğimizde gördüğünüz gibi ata sınıfa nazaran fazladan bir parametre daha eklenmiştir.

Üçüncü olarak, çocuk sınıfımızda metodun kodlarında inherited ayrılmış kelimesi ile ata sınıfın metodunu çağırıyoruz. inherited kelimesinden sonra metodun ata sınıftaki tanımlanmış haline göre metodu çağırıyoruz. Yukarıda örnekteki inherited kısmı TAnchestorClass.BirSeylerYap(Param1) gibi bir manaya gelmektedir.

Eğer inherited ile ata sınıfın metodunu çağırmazsanız, BirSeylerYap metodu çağrıldığında sadece sizin metodunuz çalıştırılacaktır. Ata sınıfın metodu hiç bir zaman çalıştırılmayacaktır. Bunun için, ileride yapacağınız bileşenlerde, ata sınıfın bir metodunu override yaptığınızda bu noktaya dikkat ediniz. Mesela TPanel’den türeyen bir sınıfınızda Paint metodunu override yaptığınızda ve inherited ile TPanel’in Paint metodunu kendi metodunuz içinde bir yerde çağırmadığınızda, TPanel ekrana çizilmeyecektir. Programın çökmesine bile sebebiyet verebilirsiniz.

Ek olarak override kelimesini sadece virtual ve dynamic metodlarda kullanabiliyoruz. Static metodlarda override kelimesini kullanamazsınız.

Aynen metodlar gibi constructor ve destructor’lar da override edilebilir. Ve genelde constructor’lar virtual ve destructor’lar da static olarak tanımlanmışlardır. Aşağıdaki örneğe göz atalım:

TMyComponent = class(TComponent)
public
  constructor Create(AOwner: TComponent); override;
  destructor Destroy;
end;

implementation

constructor TMyComponent.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  // nesne oluşturulduktan sonraki işlemler
end;

destructor TMyComponent.Destroy;
begin
  //nesne yok edilmeden hemen önceki işlemler
  inherited;
end;

Metodların inherit edilmesinden farklı değil, değil mi? Ama ata sınıfın constructor ve destructor’ını nerede çağıracağınız önemlidir. Mesela Destroy ‘da inherited kelimesinden sonraki kodlar çalıştırılmayacaktır. Çünkü ata nesnenin Destroy destructor’ı nesneyi yok edecektir. Farkında iseniz ata nesnenin Destroy’unda parametre olmadığından, sadece inherited; şeklinde kullandık.

Son olarak bu konuda değinmek istediğim metodların ve özelliklerin kalıtım yolu ile görünürlüğünün değiştirilmesidir.

Bir önceki örnekte göreceğiniz gibi TAnchestorClass sınıfında protected olan metod TMyClass çocuk sınıfında public olarak tanımlanmıştır. Yani ata sınıftan oluşturulan bir nesne BirSeylerYap metodunu göremezken, çocuk sınıfta bu public olduğu için, çocuk sınıftan oluşturulan bir nesne BirSeylerYap metodunu görüp erişebilecektir.

// Ata sınıf tanımlaması...
protected
  property BirOzellik: Integer read FBirOzellik write SetBirOzellik;

//ÇocukSınıf tanımlaması
public
  property BirOzellik;

Görüldüğü gibi tekrar özelliğin read ve write metodlarını yazmamıza gerek kalmadan, ata sınıfta gizli olan bir özelliği çocuk sınıfta görünür hale çevirdik.

Peki özellikler, inherit yapılamaz mı? Yapılabilir ama override kelimesi ile değil. Ata sınıftaki bir özelliği çocuk sınıfta tekrar tanımlamak istiyorsak:

//Ata sınıf tanımlaması
protected
  FColor: TColor;
  procedure SetColor(const Value: TColor);
  property Color: TColor read FColor write SetColor;

//Çocuk sınıfı tanımlaması
protected
  FColor: TColor;
  procedure SetColor(const Value: TColor);
public
  property Color: TColor read FColor write SetColor;

Peki bu bize ne kazandıracak? Ata sınıfa ait bir özelliği çocuk sınıfta da yönetmemize imkan sağlayacaktır. Ayrıca özelliğin getter ya da setter metodu çalıştırılmak istendiğinde, ata sınıfın getter ve setter’ı yerine çocuk sınıfın getter veya setter’ı çalıştırılacaktır. Çocuk sınıf içinde ata sınıfın SetColor metoduna erişmek için de inherited kelimesini kullanabiliriz. Yani ata sınıfa ait özelliğin getter ve setter’ını inherited ile çağırabilirsiniz. Tabi ata sınıftaki setter’ın protected ya da public olması kaydı ile.

Buaraya kadar nesne tabanlı programlamanın bileşen yazımında en çok işimize yarayan kısımlarına değindik. Başka kaynaklar ile daha ayrıntılı bilgiler edinebilirsiniz. Eğer bunları nasıl ve nerede kullanacağımızı merak ediyorsanız sabredin. Çünkü yapacağımız çoğu işlem bu bilgiler üzerine olacaktır.

Sınıflarda özelliklerin nasıl tanımlandığını gördük. Bir bileşen sınıfında bazı durumlarda özellikler özel anlam taşırlar. IDE, bileşen sınıfımıza ait özellikleri değiştirip düzenleyebilmek için bu özellikleri tanıyabilmesi lazımdır. Aynı şekilde, bu özellikleri form’a kaydedip daha sonra bu özelliği formdan tekrar okuyabilmesi gerekmektedir. Bu işlem sadece tasarım zamanında değil, çalışma zamanında da yapılmalıdır.

IDE’nin özelliklerimizi tanıyabilmesi için özellikleri, published alanında tanımlamamız gerekmektedir. Ayrıca özelliklerin kaydedilip tekrar yüklenebilmesi için kalıcılığının da sağlanması gerekmektedir.

Basit veri tipleri için kalıcılık, IDE tarafından otomatik olarak sağlanır. Mesela Integer, string, Byte, Boolean, sıralı tipler bu tip basit tiplerdendir. Ve bazı daha kompleks tipler için de özel fonksiyonlar tanımlanmıştır. Mesela TImage bileşeninde bulunan TPicture verilerini okuyup yazabilmek için LoadFromStream ve SaveToStream gibi bazı metodlar mevcuttur. TMemo’da bulunan Lines özelliği de bu tarz bir özelliktir. Kendi veri tiplerinizin kalıcılığının sağlanması, daha sonraki bölümlerde bahsedeceğimiz konulardandır. Şimdilik yapacağımız örnekler, hazır kalıcılığı sağlanmış olan kompleks tipler ile, basit veri tipleri ile ilgili olacaktır.

Event (Olay)

Bir Event (Olay) ise bir çeşit özelliktir. Event’ların tipi metod işaretçileridir. Yani eğer bir özelliğin tipi metod işaretçisi ise bu özellik, event(olay) olarak bilinir.

Metod İşaretçileri, sınıf içinde bulunan fonksiyon ve prosedürelerin işaretçilerini tutan değişkenlerdir. Normal fonksiyon ve prosedür işaretçilerinden farklı olarak metod işaretçilerinin tanımlanma şekli biraz değişiktir. Bir metod işaretçisi tanımlayabilmek için ilk başta metod işaretçisinin tipini tanımlamamız gerekmektedir. Ardından, bu tip ile oluşturulmuş herhangi bir değişken, aynen metod çağırır gibi çağrılabilir.

type
TMyEvent = procedure(Param1: string) of object;

Ardından bu metod işaretçi tipini kullanan bir event tanımlayalım

TMyClass = class
private
  FOnMyEvent: TMyEvent;
published
  property OnMyEvent: TMyEvent read FOnMyEvent write FOnMyEvent;
end;

Artık OnMyEvent adında yeni bir event’ımız mevcut. Burada getter ve setter olarak girdiğimiz FOnMyEvent değişkeni ise metod işaretçisidir. Daha sonradan bu sınıfımız içinde bir yerde bu metod işaretçisini çağırabiliriz.

if Assigned(FOnMyEvent) then
  FOnMyEvent('Param1 parametresi');

Bu işlemden sonra, FOnMyEvent’a atanmış olan metod çağırılacaktır. Mesela :

type
TForm1 = class(TForm)
  ....
  procedure MyObjectMyEvent(Param1: string);
  ....
end;

....

var
  MyObject: TMyClass;
begin
  MyObject := TMyClass.Create;
  MyObject.OnMyEvent := MyObjectMyEvent;
end;

Yukarıdaki işlemde, MyObject nesnesinin OnMyEvent olayına Form1’de bulunan gerçek bir metod atanmıştır. Böylece TMyClass sınıfındaki FOnMyEvent metod işaretçisi, Form1’de bulunan MyObjectMyEvent gerçek metoduna işaret eder olmuştur. TMyClass içinde herhangi bir yerdeki FOnMyEvent() çağırımı, Form1’deki atadığımız metodu yani bu örneğimizde MyObjectMyEvent metodunu çağıracaktır. Bu işleme Olay Tetikleme ya da Event Triggering denilmektedir.

Mesela Form üzerine eklediğiniz bir TButton bileşeninin OnClick olayına çift tıklayın. IDE, otomatik olarak Form’un sınıfı içinde yeni bir metod oluşturacaktır. Buraya bir kaç kod yazın ve kaydedip kapatın. Ardından Unit’e ait “dfm” yada .net için “nfm” dosyasına notepad gibi bir programla baktığınızda aynen yukarıdaki örneğimizdeki gibi, Button’nun OnClick olayına IDE’nin oluşturduğu metoda eşitlendiğini göreceksiniz. TButton, kendi içinde bunu FOnClick gibi gizli bir metod işaretçisine bu metodu atayacaktır.

İleride Event’lar ile ilgili daha fazla örnek yapacağız. Şu an için bu kadar teorik bilgi yeterli diye düşünüyorum.

Hatırlayacağınız gibi, makalenin başında bahsettiğimiz gibi, IDE’nin bileşenimizi tanıyabilmesi için belli kriterler vardır. Bunlardan en birincisinin, bileşenin TComponent ve alt sınıflardan türemesi gerektiğini gördük.

TComponent sınıfından türeyen bir sınıf oluşturduktan sonra, IDE’nin bu bileşeni kullanabilmesi için kayıt ettirmeliyiz. Bunun için Register prosedürü kullanılmaktadır. Basit bir Register işlemi şu şekildedir.

procedure Register;

implementation

procedure Register;
begin
  RegisterComponents('Bileşen Kategorisi', [TMyComponent]);
end;

IDE, bileşenimizin paketini kayıt ederken, otomatik olarak Register prosedürünü çağıracaktır. Bunun içine yazdığımız RegisterComponents prosedürü de sınıfımızı bileşen olarak kaydettirecektir. İlk parametre, bileşenin araç paletinde hangi kategoriye gireceğidir. İkinci parametre ise array tipinde, kaydettirilecek olan bileşen sınıflarıdır. Bu parametreye [TBilesen1, TBilesen2] şeklinde girerek birden fazla kayıt yaptırabilirsiniz.

Bu kadar bilgiden sonra artık ilk bileşenimizi yazabiliriz. Bileşenimiz, Caption özelliğine girilen değerin geçerli bir sayı olmaması durumunda bir hata gösteren ve değeri kaydetmeyen bir bileşen hazırlayalım.

Bunun için ata sınıf olarak TLabel sınıfını seçiyoruz. Ve bu sınıfa ait Caption özelliğinin üzerine yazalım. Bileşenimiz şu şekilde olacaktır.

interface

uses
  SysUtils, Classes, Controls, StdCtrls, Dialogs;

type
  TNumberLabel = class(TLabel)
  private
    function GetCaption: TCaption;
    procedure SetCaption(const Value: TCaption);
  protected
  public
    constructor Create(AOwner: TComponent); override;
  published
    property Caption: TCaption read GetCaption write SetCaption;
  end;

procedure Register;

implementation

procedure Register;
begin
  RegisterComponents('Samples', [TNumberLabel]);
end;

{ TNumberLabel }

constructor TNumberLabel.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  Caption := '0';
end;

function TNumberLabel.GetCaption: TCaption;
begin
  Result := inherited Caption;
end;

procedure TNumberLabel.SetCaption(const Value: TCaption);
var
  E, Number: Integer;
begin
  Val(Value, Number, E);
  if E <> 0 then
    ShowMessage('Bir sayı girmelisiniz!')
  else
    inherited Caption := Value;
end;

Bu bileşenin nasıl kurulacağına sonra değineceğiz. Şimdi kodları açıklayalım.

Sınıf tanımlamasına baktığımızda bir adet constructor, bir adet property ve bu property’e ait olan setter ve getter’ı görüyoruz. Caption özelliği burada gördüğünüz gibi ata sınıfın Caption özelliğinin üzerine yazılmış durumda. Ata sınıfın bir özelliğine ya da bir metoduna ulaşmak için “inherited” kelimesini kullandığımızı görmüştük.

Bu özelliğin GetCaption getter metoduna baktığımızda, çıkış olarak ata sınıfın Caption özelliğinin çıktı olarak verildiğini görüyoruz. Aynı şekilde SetCaption setter metodunda ise Caption’a atanan değerin geçerli bir sayı olup olmadığını kontrol ediyoruz. Eğer geçerli değilse hata mesajını gösteriyoruz, eğer geçerli bir sayı ise, ata sınıfın Caption özelliğine bu yeni değeri atıyoruz.

Bildiğiniz gibi Delphi, forma yeni eklenen bir bileşenin Caption ya da Text özelliğini, bileşenin ismi olarak belirliyor. Ve bu bileşeni yeni eklediğinizde Caption olarak “NumberLabel1” gibi bir şey atayacak. Ki bu, geçerli bir sayı değildir. Bu yüzden ilk değer olarak Caption özelliğine bir sayı atamalıyız. Bunun gibi ilk değerleri bileşenin Create constructor’ında vermeliyiz. Zaten Create constructor’ına baktığınızda anlayacaksınız. Ayrıca hatırlatmak gerekirse, buradaki constructor virtual olarak tanımlanmıştır. Bu yüzden override; kelimesini kullanmayı unutmuyoruz.

Aslında bileşen yazımı ile alakası olmasa da, çoğu zaman yeni bileşen yazanlar için kafa karıştırıcı bir konudur. Ama yeni bir bileşeni kurmak için gereken şartları sağladığınızda hiç bir sorun ile karşılaşmayacaksınız.

Her bileşen mutlaka bir paket içinde olmalıdır. Delphi 7 ve öncesinde, hazır tanımlanmış olan bir paket bulunuyordu. Ve paket yerine pas uzantılı bir bileşeni kurmak istediğinizde, IDE bunu hazır olan bu paket içine otomatik olarak atıp orada derliyordu. Ama Delphi 8 ve daha sonraki versiyonlarda bu paketten vazgeçildi.

Bir VCL bileşeni kurabilmeniz için ilk başta eğer paket’i yok ise bir paket oluşturuyoruz. Bunun için Menü’den File/New/Other ile açılan pencereden Package’i bulup seçiyoruz. Project Manager bölümünde boş bir paket oluşturulmuş durumda. Contains kısmında paketin içinde bulunacak olan unit’ler, ve Requires kısmında ise bu paketin ihtiyaç duyduğu diğer paketler bulunacaktır. Contains kısmına sağ tuş ile tıklayıp “Add New” ile yeni bir Unit ekleyelim. Ve yukarıdaki TNumberLabel bileşenini buraya yapıştırıp paketle birlikte bir klasöre kaydedelim. Ardından bu paketi Shift+F9 ile derleyelim. Eğer çıkış için bir klasör belirlememiş iseniz, My Documents/Borland Studio Projects/Bpl altında bu paketin derlenmiş dosyasını bpl dosyası şeklinde görebilirsiniz. Bu arada, Bpl dosyaları bir çeşit Dll’dir.

Derleme işleminden sonra Menüden Tools/Options ile açılan pencereden Library – Win32 kısmını bulalım. “Library Path” altına bileşenimizin pas dosyasını kaydettiğimiz klasörü ekleyelim.

En son olarak Menüden “Component/Install Packages…” ile derlenmiş olan bpl dosyasını bulup bileşenimizi kuralım. Bileşenimiz Register prosedüründe belirttiğimiz kategori altına kaydedilmiş olmalıdır.

VCL.NET için de işlemler bu şekildedir. Tek fark, derlediğiniz paket bir Bpl değil, Dll uzantılı bir .NET assembly’si olacaktır. Daha sonra bu dll dosyasını Component/Install .NET Component altından VCL Components kategorisi altına ekleyebilirsiniz.

Bu bölüm buraya kadar yeterli. Buraya kadar öğrendiklerimizi bir bir gözden geçirelim, atlamayalım. Çünkü bu bilgiler, hem bileşen yazımının temelini oluşturmakta, hem nesne programlamanın temelini oluşturmakta hem de Delphi’nin çalışma mantığını göstererek, Delphi programlamada neyin nasıl gerçekleştiği noktasında bizlere fikir vermektedir.

İç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