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/delphi-7-ile-simdiki-delphi-surumleri-arasindaki-farklar/?utm_source=rss&utm_medium=rss&utm_campaign=delphi-7-ile-simdiki-delphi-surumleri-arasindaki-farklar http://www.diyezon.com/delphi-7-ile-simdiki-delphi-surumleri-arasindaki-farklar/#comments Mon, 13 Aug 2007 22:00:48 +0000 Fatih Tolga Ata http://www.diyezon.com/?p=53 Bildiğiniz gibi VCL, .NET ortamına taşınırken derleyici bazında bir çok değişikliğe ve geliştirmeye gidildi. Bu geliştirmeler, hem Delphi.NET derleyicisini hem bildiğimiz klasik Delphi for Win32 derleyicisini etkiledi. Tabi bu geliştirmeler, en çok biz programcıların işine yaradı.

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.

Firebird .NET Data Provider

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

Data Provider’ı Delphi’ye Ekleyelim

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

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

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

WinForms ile Örnek Bir Uygulama

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

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

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

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

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

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

SELECT * FROM KISILER

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

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

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

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

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

BDP ile Firebird Bağlantısı

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

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

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

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

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

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

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

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

VCL.NET ile Firebird Bağlantısı

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

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

Kolay gelsin.

Fatih Tolga Ata © 2007

İçindekiler

Giriş

Model Tabanlı Geliştirme

Örnek Uygulama

Bir ECO Modeli Oluşturalım

Arayüzü ECO ile İlişkilendirmek

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

Auto Forms

Sonuç

Giriş

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

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

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

Model Tabanlı Geliştirme

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

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

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

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

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

Örnek Uygulama

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

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

• Å?irketler için irtibat bilgilerini tutabilmeli

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

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

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

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

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

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

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

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

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

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

CoreClassesUnit.pas

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

AdresDefteriEcoSpace.pas

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

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

Bir ECO Modeli Oluşturalım

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

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

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

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

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

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

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

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

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

Arayüzü ECO ile İlişkilendirmek

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

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

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

AdresDefteriEcoSpace.TAdresDefteriEcoSpace

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

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

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

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

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

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

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

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

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

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

EcoSpace.UpdateDatabase;

Auto Forms

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

Sonuç

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

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

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

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

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

Fatih Tolga Ata © Eylül 2005

Son Güncelleme: 25 Ocak 2007