Tevfik AKTUĞLU-Java Programlama

Doğrusal Veri Kapları

2012-01-31T22:35:00.001+02:00

Bu yazımızda, Veri Kapları Çerçevesi'nce (VKÇ) desteklenen doğrusal veri yapılarına değineceğiz. Bunu yaparken izleyeceğimiz yöntem, söz konusu veri yapılarının ortak özelliklerini anlattığımız giriş bölümünü takiben, anılan kategoriye giren kapları en geniş anlamda temsil eden genel liste veri yapısının desteklediği arayüzleri açıklamak ve kapların doğrusallaştırılmaları sonrasında ardışık erişimli görüntülerini sağlayarak dolaşılmasını olanaklı kılan gezicilere bakmak olacak. Yazımızın devamında ise, değişik doğrusal yapıların farklı gerçekleştirimlerine göz atarak işimizi bitireceğiz.

Giriş
Genel liste arayüzü
Geziciler
Genel liste gerçekleştirimleri
Doğrudan erişimli listeler
Kısıtlı listeler
Bağlaçlı liste
Değişken uzunluklu diziler: java.util.Vector🔎

Giriş

Doğrusal veri yapıları, eleman ekleme, silme ve güncelleme işlemlerinin hangi sırada uygulandığının bilinmesi durumunda, elemanların nasıl sıralanacağının bilindiği kaplardır. Örnek olarak, 1, 2 ve 3 sayılarının bir genel listenin, sırasıyla, başına, sonuna ve başına eklendikten sonra elde edilen kaptan ikinci elemanın silindiğini düşünün. Bu işlemlerin sonrasında listemiz, ne tür bir gerçekleştirim kullanılırsa kullanılsın, [3, 2] sıralamasıyla gezilecektir. Halbuki, küme veya eşlemlerde elde edilecek sıralama gerçekleştirime bağlı olarak oluşacak ve dolayısıyla kestirilemeyecektir.

Genel Liste Arayüzü: `java.util.List`

Doğrusal veri yapılarını en geniş anlamda temsil eden soyut veri yapısı genel listedir. VKÇ'deki List arayüzü ile karşılanan bu yapı, gerçekleştirim biçiminden bağımsız olarak bir genel listenin desteklemesi beklenen işlemleri tanımlar. Yani, ister dizi gibi doğrudan erişimli bir yapı kullanılarak gerçekleştirilsin isterse bağlaçlı bir yapı kullanılarak, tüm genel listeler List arayüzündeki işlemleri desteklemek zorundadır.

Collection'dan kalıtlanmak suretiyle List arayüzünde gözüken iletilerin başında, equals ve hashCode gelir. Bu iletilerin List arayüzüne konulmuş olmasını başta yadırgayabilirsiniz. Ne de olsa, tüm sınıfların [dolayısıyla List arayüzünü gerçekleştirecek sınıfların da] kalıtladığı Object sınıfında bu iletilere dair gerçekleştirimler sağlanmaktadır. Ancak, buradaki amaç gerçekleştirimciye bir hatırlatma yaparak onu uyarmaktır; tanımlayıcıları List arayüzünü gerçekleştirmek isteyenlere şunu demektedirler:

Tutacakları karşılaştırmak yoluyla işini gören Object sınıfındaki equals metodu, muhtemelen senin işine gelmeyecektir. Ne de olsa, bu metot eşitlik denetimi yerine aynılık denetimi yapar. Bunun bir sonucu olarak, iki listenin eşit olması ancak ve ancak aynı olmaları durumunda mümkün olacaktır; eşit içeriğe sahip iki farklı liste eşitsiz ilan edilecektir. Dolayısıyla, sen iyisi mi, equals iletisini gerçekleştirmeyi bir daha düşün. Ha bu arada; hashCode iletisini de gözden geçirmeyi unutma. Malum, birbirine eşit farklı nesnelerin kıyım değerleri de eşit olmalıdır. Bu koşulu sağlayabilmenin yolu ise hashCode ile equals'ı birlikte ele almaktan geçer. Çünkü, Object sınıfındaki equals metodunu ezip de hashCode metodunu ezmezsen, eşit kapların farklı kıyım değerleri üretmesi durumu ortadan kalkmaz.

List arayüzündeki iletilerin çoğu VKÇ'yi daha önceden kullanmış olanlara tanıdık gelecektir. Bunun başlıca sebebi, VKÇ'de desteklenen kapların bir standardizasyon çabası kapsamında birlikte ele alınmış olmasıdır.¹ Doğal olarak, aynı işlemler için olabildiğince aynı ileti adları seçilmeye çalışılmış ve ilintili işlemler kategorizasyon amacıyla aynı arayüze konulmuştur. Örneğin, ne tür bir kap olursa olsun, isEmpty hedef nesnenin boş olup olmadığını denetlerken size kaç eleman içerdiğini döndürür. Benzer bir şekilde, ilişkisel olmayan veri yapıları (genel liste, kuyruk, yığıt, çift-uçlu kuyruk, küme) Collection arayüzünde belirlenen işlevselliği paylaşırlar. Mesela, ister Vector olsun isterse TreeSet, bir nesnenin hedef kapta olup olmadığı contains iletisi ile sorgulanabilir; hedef kabın sonuna add ile eleman eklenirken, hedef kaptan verilen bir nesneye eşit ilk elemanın silinmesi remove ile sağlanır. Bunlara paralel olarak, containsAll, addAll ve removeAll/retainAll iletileri, sırasıyla, sorgulama, sona ekleme ve silme işlemlerini kendilerine geçirilen kapta var olan tüm nesneleri dikkate alarak yerine getirirler. clear iletisi ise, hedef kabın tüm elemenlarını siler.

List arayüzünün Collection'dan kalıtladığı diğer iletiler hedef kabın dizi şeklindeki görüntüsünü döndüren toArray iletileridir. Kap içeriğini baştan sona dolaşılma sıralarını koruyacak şekilde diziye kopyalayan iletilerden argümansız olanı, sonucu Object dizisi olarak döndürürken, kopyalamanın yapılacağı dizinin bileşen türünü argümanındaki dizinin bileşen türünü belirleyen tür argümanıyla alan ikinci uyarlama, sonucu dönüş değerinin yanısıra, yeterli yere sahip olması durumunda, argümanda geçirilen dizinin içinde de döndürür. Argümandaki dizinin yeterli yere sahip olması halinde, dönüş değeri için ikinci bir dizi yaratılmayacak, aynı dizi nesnesi paylaştırılacaktır.

Üst arayüzlerden kalıtlanmayıp List arayüzünün eklediği doğrusal kaplara özel tüm iletiler, kendilerine sağlanan indis değerlerini kullanarak ya da sonuçlarında indis değeri döndürerek işlerini görürler. Bunlardan get/set çifti, dizi erişim işleci ([]) görevini görür: get argümanında sağlanan indisteki elemanı döndürürken, set belirtilen konumdaki elemanı ikinci argümanındaki yeni değerle güncelledikten sonra söz konusu konumdaki eski değeri döndürür. get'in tersi olarak da görülebilecek indexOf ve lastIndexOf iletileri ise, contains iletisinin boolean yerine sorgulanan nesnenin, sırasıyla, kap içindeki ilk ve son geçiş yerlerini döndüren uyarlamaları olarak düşünülebilir. Argümandaki nesnenin kap içinde bulunmaması halinde her iki ileti de -1 döndürecektir.

List arayüzüne özel add, addAll ve remove iletilerinin yukarıda anılan adaşlarından şöyle bir farkı vardır: ekleme kap sonu yerine sağlanan ekstra argümanla belirtilen konuma yapılırken, silme nesne-eleman eşitliği denetlenerek bulunan konumu değil argümandaki indisin gösterdiği konumu etkiler.

Değineceğimiz son ileti, ilk başta göründüğünden çok daha hünerli olan subList. Hedef kabın argümanlar ile sınırlanan [kapalı-açık] dilimini bir List görüntüsü≝ olarak döndüren bu ileti, dilim işlemlerinin gerçekleştirilmesini kolaylaştırır. İstersek, bir nesnenin kabımızın belirli bir diliminde var olup olmadığını sorgulayabiliriz; istersek, aşağıda olduğu gibi, kabımızın bir bölümünü silebiliriz.

import java.util.Arrays;
import java.util.LinkedList;
import java.util.List;
...
  List<Integer> ls = new LinkedList<>(Arrays.asList(0, 1, 2, 3, 4, 5, 6, 7, 8, 9));
  ls.subList(3, 7).clear(); // ls → [0, 1, 2, 7, 8, 9]

Geziciler: `java.util.Iterator` ve `java.util.ListIterator`

List arayüzünün Collection vasıtasıyla Iterable'dan kalıtladığı düşünüldüğünde, liste elemanlarının, tıpkı diziler gibi, gezici for döngüsü ile dolaşılabileceği görülecektir. Yani, gezici nesne yaratıp başa konuşlandıktan sonra hasNext ve next iletilerinden yararlanarak dolaşmaktansa, listemizi aşağıdaki gibi dolaşmak da mümkündür ve kodun anlaşılabilirliğini artırmak adına bu yöntem yeğlenmelidir.

import java.util.List;
import java.util.ArrayList;
...
  List<ElmTürü> ls = new ArrayList<>();
  ... // ls'yi doldur]
  for (ElmTürü elm : ls) { ... }

Ön-derleme sonrasında yukarıdaki for döngüsü J2SE 5.0 öncesinde programcının yazmak zorunda kaldığı şu şablon koda çevrilecektir. Dolayısıyla, gezici for döngüsünün, dolaşılabilir kapların kullanımında yararlanılan sözdizimsel bir kolaylık olduğunu söyleyebiliriz.

import java.util.Iterator;
...
  for (Iterator<ElmTürü> gzc = ls.iterator(); gzc.hasNext();) {
    ElmTürü elm = gzc.next();
    ...
  }

Gezicinin soyutlanarak doğrudan kullanımının önüne geçilmesi nedeniyle, gezici for döngüsünün gövdesinde kap içeriğinin güncellenmesi olanaksızdır; dolaşma esnasında kabın güncellenebilmesi için gezicinin bizzat programcı tarafından yaratılması gerekir. Bu durumda, geziciye gönderilecek bir remove iletisi, next ile döndürülen son elemanı silecektir.

...
  for (Iterator<ElmTürü> gzc = ls.iterator(); gzc.hasNext();) {
    ElmTürü elm = gzc.next();
    if (...) gzc.remove();
    ...
  }

iterator'ın döndürdüğü gezicinin anılan üç iletiye sınırlı olması bazen kısıtlayıcı olabilir. Doğru ya, ardışık elemanların ilişkilerini görebilmek için kabımız içinde ileriye doğru olduğu gibi geriye doğru da dolaşmak isteyebiliriz; gezme sırasında elemanları silmek isteyebileceğimiz gibi güncellemek, öncesine veya sonrasına yeni bir değer eklemek isteyebiliriz. Bu takdirde, List tutacağı aracılığıyla gönderilebilecek listIterator iletisinin kullanımı düşünülebilir. Hedef kabın ListIterator arayüzü tutacağı ile kullandırılan bir görüntüsünü döndüren bu ileti, geziciyi kabın başına veya argümanla belirtilen konuma konuşlandırabilir. İlkleme sonrasında, gezicinin sağladığı görüntü kullanılarak altyapıdaki kap ileri/geri yönde dolaşılabilir, uygun görülen yerlere yeni eleman eklenebildiği gibi, var olan elemanlar değiştirilebilir veya silinebilir. Bu noktada, yıkıcı (güncelleyici) işlemlerin etkisini altyapıdaki kap üzerinde göstereceği unutulmamalıdır. Örneğin, aşağıdaki kod parçasında gzc ls ile gösterilen kabın ortasına konuşlanmakta ve başa doğru dolaşırken değeri 3 olan elemanları 33 olacak şekilde güncellemektedir.

import java.util.ListIterator;
...
  List<Integer> ls = new ArrayList<>();
  // ls'yi doldur...
  int orta = ls.size / 2;
  for (ListIterator<Integer> gzc = ls.listIterator(orta); gzc.hasPrevious();) {
    int elm = gzc.previous(); // Derleyici Integer→int dönüşümünü yapıyor
    if (elm == 3) gzc.set(33);
    ...
  }

Kabın paylaşılması nedeniyle, yapılan değişikliklerin hem liste hem de gezici tutacağı ile görüleceği unutulmamalıdır. Bu noktanın gözden kaçırılması, çok-izlekli programlarda—mesela, kabın bir izlekte liste tutacağı yoluyla bir diğerinde ise gezici tutacağıyla değiştirildiği durumlarda—soruna yol açabilir.

Iterator arayüzünden kalıtlayan ListIterator aşağıdaki tabloda verilen iletileri içerir. Eklemenin yapılacağı nokta aynı kapıya çıkan iki şekilde tanımlanabilir: i) hasNext'in false döndürmesi durumunda listenin sonuna, aksi takdirde next ile döndürülecek elemanın öncesine, ii) hasPrevious'ın false döndürmesi durumunda listenin başına, aksi takdirde previous ile döndürülecek elemanın sonrasına. Ayrıca, remove ve set iletilerinin en son okunmuş olanın dışında bir elemanı etkilemeyeceği ve bu iletilerin add veya bir diğer remove iletisi sonrasında bir başka okuma yapılmaksızın kullanılamayacağı unutulmamalıdır. Aksi takdirde, gönderi IllegalStateException ayrıksı durumunun firlatılmasıyla sona erecektir.

`ListIterator` *arayüzü*
İleti	İşlev
`hasNext`	Liste sonu sorgulama
`next`	Bir sonraki eleman
`remove`	En son okunan elemanı silme
`nextIndex`	Bir sonraki elemanın indisi
`hasPrevious`	Liste başı sorgulama
`previous`	Bir önceki eleman
`previousIndex`	Bir önceki elemanın indisi
`add`	Ekleme
`set`	En son okunan elemanı güncelleme

Gezici kullanımı sırasında şu husus akılda tutulmalıdır: geziciler dolaştırdıkları listenin değişebilirlik, çok/tek-izleklilik ve tür güvenlilik gibi özelliklerini korur. Buna göre, aşağıdaki kod parçasında, lsGzc vasıtasıyla değişikliğe izin verilirken, sabitLsGzc'nin aynı kabı değiştirmek amacıyla kullanılması UnsupportedOperationException ayrıksı durumuna neden olacaktır.

import java.util.Collections;
...
  List<Integer> ls = new ArrayList<>();
  // ls'yi doldur...
  List<Integer> sabitLs = Collections.unmodifiableList(ls);
  ...
  ListIterator<Integer> lsGzc = ls.listIterator();
  ListIterator<Integer> sabitLsGzc = sabitLs.listIterator();

java.util.Enumeration arayüzüne değinerek geziciler bahsini kapatalım. İşlevsel olarak Iterator arayüzünün silme özelliği barındırmayan uyarlaması olarak düşünülebilecek bu arayüzün kullanımından kaçınılmalıdır. Daha önceden tanımlanmış olup ıslah edilerek VKÇ'ye katılan Hashtable ve Vector gibi kapların bu arayüzün tutacağı ile görüntü döndüren iletileri yerine, eşdeğer bir diğer iletinin kullanılması yerinde olacaktır. Örneğin, Vector nesnelerine elements yerine iterator iletisi gönderilmelidir. Bu, VKÇ ile birlikte tanımlanan Vector benzeri (ArrayList gibi) kapların elements'i desteklemeyip iterator'ı desteklemesi nedeniyle kodun yeniden kullanılabilirliği adına daha doğru olacaktır.

Genel Liste Gerçekleştirimleri

Altyapıda yararlanılan kabın erişim özelliğine bağlı olarak List arayüzünü gerçekleştiren sınıflar, doğrudan erişimli ve ardışık erişimli olmak üzere ikiye ayrılırlar. Bu ayrım, kimi iletilerin performanslarını etkilemesi ve desteklenebilecek ekstra iletiler nedeniyle, söz konusu kapların kullanıldıkları programların çalışma hızını ve anlaşılabilirliğini etkileyecektir; hangi somut sınıfın kullanılacağına dair yapılan seçimde bu nokta göz önünde bulundurulmalıdır. Kodun yeniden kullanılabilirliğini artırmak ve yapılacak muhtemel değişikliklerin etkisini en aza indirmek adına, tutacak türü olarak arayüz ve soyut sınıf adları kullanmaya çalışılmalı, somut sınıfların kullanımı nesne yaratma noktalarına sınırlı tutulmalıdır. Tercih edilen somut sınıfın kesinleşmesinden sonra bile arayüzlerde listelenen iletiler sınıfa özel eşdeğer iletilere yeğlenmeli, sınıfa özel iletiler ancak ek getirileri olmaları durumunda seçilmelidir. Örneğin, Vector'de karar kılınsa dahi List arayüzündeki get kullanılmalıdır, Vector sınıfına özel elementAt değil. Buna karşılık, subList ve tek argümanlı indexOf iletisinin birlikte kullanımı yerine iki argümanlı indexOf iletisinin kullanımı daha anlaşılabilir olması ve [marjinal] hız farkı nedeniyle tercih edilebilir.

adlar.indexOf("Ali", 5); // adlar.sublist(5, adlar.size()).indexOf("Ali")

Java VKÇ, gerçekleştirimcinin işini kolaylaştırmak amacıyla somut sınıfların üzerine inşa edileceği soyut sınıflar sağlar. Doğrudan erişimli bir altyapı üzerine oturtulan bir genel liste için bu soyut sınıf AbstractList iken, ardışık erişimli altyapı kullanarak aynı işe soyunanların doğru adresi, AbstractList'ten kalıtlayan AbstractSequentialList'tir. İskelet görevi gören bu sınıflar, yararlanılacak altyapının ayrıntılarına dair varsayımlarda bulunulamaması nedeniyle, kimi iletilere karşılık gerçekleştirim sağlamazken kimi iletiler için genel [ve yavaş] gerçekleştirimler sağlar. Dolayısıyla, VKÇ'ye yeni bir kap gerçekleştirimi eklemek isteyenler, soyut sınıflardan uygun olanından kalıtlayarak iskeleti ete büründürmelidir.

VKÇ'ye yeni bir kap gerçekleştirimi eklemek isteyenlerin sabit içeriklilik ve değişken uzunlukluluk özelliklerini destekleyip desteklememelerine bağlı olarak sorumlulukları da değişir. Örneğin, tüm doğrudan erişimli listeler get ve size iletilerine karşılık gelen metotları sağlamak zorundayken, listenin değişken içerikli olmasının istenmesi durumunda, AbstractList'te UnsupportedOperationException ayrıksı durumu fırlatacak şekilde gerçekleştirilen set ezilmelidir. Benzer şekilde, listenin değişken uzunluklu olması isteniyorsa, iki argümanlı add ve int argüman alan remove metotlarının da ezilmesi gerekir. Ardışık erişimli listelerin gerçekleştiriminde de aynı ayrım geçerlidir: AbstractSequentialList'ten kalıtlayıp size ve listIterator iletilerini gerçekleştirmesi beklenen geliştiriciler, listIterator'ın döndürdüğü gezicinin alacağı iletileri gerçekleştirirken sabit içeriklilik ve değişken uzunlukluluk özelliklerini hesaba katmalıdırlar. Ardışık erişimli listelerden sabit içerikli [ve dolayısıyla sabit uzunluklu] olanlar, ListIterator arayüzünde bulunan next, hasNext, nextIndex, previous, hasPrevious ve previousIndex için gerçekleştirim sağlamak zorundayken, diğer iletilerin gerçekleştiriminde UnsupportedOperationException döndürmelidirler. Buna karşılık, değişken içerikli, sabit uzunluklu listeler, anılan arayüzün add adlı iletisini de gerçekleştirmek durumundadır. Son olarak, değişken uzunluklu listeler, arayüzde bulunan tüm iletileri gerçekleştirmelidir.

Doğrudan Erişimli Listeler: `java.util.ArrayList` ve `java.util.Vector`

VKÇ'de doğrudan erişimli genel liste gerçekleştirimi sağlayan iki sınıf vardır: ArrayList ve Vector🔎. Diziden yararlanarak işini gören bu sınıflar arasında işlevsellik ve performans açısından pek fark yoktur. Ancak, yine de şu noktaların akılda tutulmasında yarar olacaktır:

Java'nın ilk uyarlamasından bu yana var olan Vector, diğer J2SE 1.2 öncesi kaplar gibi, çok-izlekli iken ArrayList tek-izleklidir. Dolayısıyla, ArrayList türlü kapların çok-izlekli bir programda kullanılması durumunda, farklı izleklerden eşzamanlı erişimin sebep olabileceği tutarsızlıkları önlemek adına bazı kod bölgelerinin synchronized bloğu içine alınarak çok-izlekli hale getirilmeleri gerekir. Buna karşılık, kamuya açık tüm metotları synchronized olan Vector sınıfının tek-izlekli veya erişim serileştirme gereksiniminin düşük olduğu çok-izlekli programlarda kullanılması, çalışma hızının gereksiz yere yavaşlamasına neden olacaktır. Bu gibi durumlarda, ArrayList türlü bir kabın kullanımı ve gerekli noktalarda Collections sınıfındaki synchronizedList metodu ile döndürülen görüntü üzerinde işlem yapılması da bir çözüm olarak hesaba katılmalıdır.²
Her iki sınıf da, eleman sayısının artmasını gerektirecek bir işlem sırasında sığanın otomatik olarak büyümesini sağlar. Ne var ki, Vector sınıfında ilişkin kabın yaratılması esnasında sağlanacak bir argüman ile sığa artımına müdahale edilebilirken, ArrayList sınıfında böyle bir olanak yoktur.

Yukarıda da söylediğimiz gibi, her iki sınıf da benzer performansa sahiptir. get, set, size, isEmpty, iterator ve listIterator iletileri sabit zamanlı performans sergilerler. Ayrıca, kabın sığa artımına ihtiyaç duyduğu durumlarda yaşanan düşüşe karşın, kap sonuna eleman ekleyen add iletisi de ortalamada sabit zamanlı bir performans gösterir. Buna karşılık, diğer iletilerin arama temelli olanları, kap içeriğini dolaşmak zorunluluğu nedeniyle doğrusal veya daha pahalı bir performans sergileyecektir.

Kısıtlı Listeler: `java.util.PriorityQueue` ve `java.util.ArrayDeque`

C'den başka programlama dili bilmeyenlerin yaydığı bir efsanedir: liste denince akla bağlaçlar, bağlaç denince ise göstericiler gelir. Eğer bu bedbahtlardansanız, olasıdır ki yazımızın bağlaçlı listelerle başlamamış olması sizi şaşırtmıştır. Size kötü bir haber daha verelim, genel liste arayüzünün bir altkümesine sınırlı işlevsellik sunan kısıtlı listelere değinmeden bağlaçlı listelere geçmeyeceğiz.

VKÇ'de desteklenen ve tür sıradüzeni aşağıda verilen kısıtlı liste çeşitlerini anımsayarak başlayalım. Üç temel işlemin de üst olarak nitelenen aynı liste ucunu etkilediği bir kısıtlı liste olan yığıt (İng., stack), herhangi bir noktada çıkarılacak (veya sorgulanılacak) ilk elemanın en son eklenen eleman olması nedeniyle son giren ilk çıkar listesi olarak da adlandırılır. Bir diğer kısıtlı liste, gerçek yaşamdaki aynı adlı kavramı temsil eden ve uygarlıktan nasibini almış herkesin takdir edeceği nedenlerden ötürü ilk giren ilk çıkar listesi olarak adlandırılan kuyruktur (İng., queue). Kuyruğun elemanları arasında bir sıralamanın istenmesi halinde—yani, kuyruğun belirli bir ölçüte göre oluşturulması istendiğinde—ekleme işlemi kuyruğun sonu yerine herhangi bir yerine yapılabilir. Böylesine kuyruklara, öncelikli kuyruk (İng., priority queue) denir. Son olarak, temel işlemlerin aynı listenin her iki ucuna da uygulanabildiği kısıtlı listelere çift-uçlu kuyruk adı verilir.

Yukarıdaki şeklin incelenmesi kuyruk ve yığıt yapılarının VKÇ tarafından desteklenmediği kanısını yaratabilir. Java uzmanı olanlarınız ise, aslında bu desteğin var olduğunu, sorunun şeklin eksik olmasında yattığını iddia edeceklerdir. Her iki görüşte de haklılık payı olduğunu, duruma daha sonra açıklık getirileceğini söyleyelim ve Queue arayüzünün açıklaması ile devam edelim. Collection'dan kalıtlayan bu arayüz, aynı işlemin istisnai durumlarda iki farklı biçimde davranması nedeniyle, aşağıdaki tabloda listelenen altı iletiyi içerir. Sabit uzunluklu, dolu bir kuyruğa add ile ekleme yapılması IllegalStateException ayrıksı durumuna neden olurken, aynı kuyruğa offer ile eleman eklenmeye çalışılması, C fonksiyonlarını andırırcasına, null değerinin döndürülmesine neden olacaktır. Sorgulama ve çıkarma işlemleri de boş bir kuyruğa uygulanmaları halinde benzer bir davranış sergileyecektir.

*Kuyruk: İlk giren ilk çıkar listesi*
İşlem	İleti (`Queue`)	Başarısızlıkta döndürülen değer	Denk ileti (`Deque`)
Ekleme	`add`	`IllegalStateException`	`addLast`
Ekleme	`offer`	`false`	`offerLast`
Sorgulama	`element`	`NoSuchElementException`	`getFirst`
Sorgulama	`peek`	`null`	`peekFirst`
Çıkarma	`remove`	`NoSuchElementException`	`removeFirst`
Çıkarma	`poll`	`null`	`pollFirst`

Queue arayüzüne dayalı kuyruk gerçekleştirimini kolaylaştırmak amacıyla sağlanan AbstractQueue'dan kalıtlayan sınıflara baktığımızda, değişken uzunluklu öncelikli kuyruk yapısını ikili yığın (İng., binary heap) kullanarak gerçekleştiren PriorityQueue sınıfını görürüz. Dizi üzerine ikili ağaç benzeri bir yapı oturtarak işini gören bu gerçekleştirim stratejisi sayesinde, temel işlemlerden sorgulama sabit zamanda sonuç verirken, ekleme ve çıkarma logaritmik zaman almaktadır. Öncelikli kuyruğun eleman sayısını öğrenme, boşluk yüklemi ve gezici yaratma da sabit zamanda mümkün olmaktadır. Buna karşılık, geri kalan iletiler doğrusal zaman gerektirmektedir.

PriorityQueue sınıfının yapıcılarına bakıldığında iki nokta dikkat çeker. Öncelikle, değişken uzunluklu olması hasebiyle taşmaması için büyütülen kuyruklar, istenildiği takdirde yaratıldıkları noktada belirli bir ilk sığaya sahip olacak şekilde yaratılabilir. Kuyruğun eleman eklenerek büyümesi sırasında altyapıdaki dizinin büyütülmesinden kaynaklanacak performans kaybını azaltacak bu parametre, sabit uzunluklu kuyruklarda yer ve zaman kayıplarını sıfıra indirecektir. Dikkatimizi çeken ikinci husus, iki argümanlı yapıcıdaki ikinci argümanın Comparator türlü olmasının hatırlattığı ayrıntıdır: öncelikli kuyruk içine konulmak istenecek nesnelerin, hangi sınıftan olurlarsa olsunlar, karşılaştırılabilir olmaları gerekir. Durup düşünüldüğünde bu önkoşulun çok doğal olduğu görülecektir: karşılaştırılamayan nesneler sıraya dizilemezler!³ Dolayısıyla, nesnelerin Comparable arayüzünü gerçekleştiren bir sınıfa ait olması veya nesneleri karşılaştırmayı bilen bir karşılaştırıcı nesnenin fazladan sağlanması zorunludur.

Gelelim ortalıkta gözükmeyen yığıt ve kuyruk gerçekleştirimlerinin nerede olduklarına. Bunun için, çift-uçlu kuyruk yapısının tanımlandığı Deque arayüzünü gerçekleştiren ArrayDeque sınıfına bakmak yetecektir. Çünkü, VKÇ'de bir kabın yığıt veya kuyruk gibi davranması, bu yapılara uyumlu iletilerin ArrayDeque nesnelerine gönderilmesiyle sağlanır.⁴

import java.util.Deque;
import java.util.Queue;
import java.util.ArrayDeque;
...
  Deque<Integer> yığıt = new ArrayDeque<>();
  Queue<Integer> kuyruk = new ArrayDeque<>();

Örneğimizdeki asimetrik kullanım dikkatinizi çekmiştir: tutacak türü olarak, kuyruk için Queue arayüzü kullanılırken, yığıt için çok-uçlu kuyruğa dair Deque arayüzü kullanılmaktadır. Dolayısıyla, kuyruk adlı kap kuyruklara özel iletilerle kullanılacakken, yığıt'ın kullanımında seçtiğimiz tanımlayıcı adı aldatıcı olacaktır. Zira, söz konusu tutacak Deque arayüzünde tanımlı olan ve aşağıdaki tabloda sağlanan yığıt iletilerinin yanısıra diğer tüm iletilere de izin verecektir.

*Yığıt: Son giren ilk çıkar listesi*
İşlem	İleti	Başarısızlıkta döndürülen değer	Denk ileti
Ekleme	`push`	`IllegalStateException`	`addFirst`
Ekleme	—	`false`	`offerFirst`
Sorgulama	`peek`	`null`	`peekFirst`
Sorgulama	—	`NoSuchElementException`	`getFirst`
Çıkarma	`pop`	`NoSuchElementException`	`removeFirst`
Çıkarma	—	`null`	`pollFirst`

Bu noktada, bazılarınız, Java'nın ilk uyarlamasından bu yana var olan Stack sınıfı nerelerde, diye soruyor olabilir. Hemen yanıtlayalım: eskiden olduğu yerde, emrinize amade sizi bekliyor. Ama, sakın ola ki, sırf adı yığıt sözcüğünün İngilizce karşılığı olduğu için bu sınıfı kullanmanın daha iyi bir fikir olduğunu düşünmeyin. Çünkü, geliştiricilerin, muhtemelen işi aceleye getirmeleri nedeniyle, Vector sınıfından kalıtlayarak gerçekleştirdiği bu sınıf, yığıt kavramıyla ilgili ilgisiz çok sayıda iletiyi desteklemektedir. Mesela, aşağıdaki kod parçasında yaratılan kap, yığıta dair iletilerin yanısıra, Vector sınıfının desteklediği diğer iletileri de, doğrudan erişimliler dahil olmak üzere, itiraz etmeden kabul eder.

import java.util.Stack;
...
  Stack<Integer> yığıt = new Stack<>();
  // List arayüzündeki tüm iletiler yığıt'a gönderilebilir!

Geldiğimiz noktada, üç farklı kısıtlı liste için sağladığı destek ve söz konusu yapıların farklı terminoloji kullanması nedeniyle, Deque arayüzünü (ve gerçekleştirimcisi ArrayDeque sınıfını) anlamakta zorluk çekiyor olabilirsiniz; bazı işlemlerin istisnai durumlarda iki değişik şekilde tepki vermesi işi daha da kötüleştirebilir. Ancak ürkmeyin, aşağıdaki tablonun yorumu sizi işinizin düşündüğünüz kadar zor olmadığına inandıracaktır.

*Çift-uçlu kuyruktan yararlanarak kuyruk ve yığıt*
			Denk iletiler
			C tarzı dönüş	Ayrıksı durum
Kuyruk	Ekleme	`add`	—	`addLast`
	Ekleme	`offer`	`offerLast`	—
	Sorgulama	`element`	—	`getFirst`
	Sorgulama	`peek`	`peekFirst`	—
	Çıkarma	`remove`	—	`removeFirst`
	Çıkarma	`poll`	`pollFirst`	—
Yığıt	Ekleme	`push`	`offerFirst`	`addFirst`
	Sorgulama	`peek`	`peekFirst`	`getFirst`
	Çıkarma	`pop`	`pollFirst`	`removeFirst`

Çift-uçlu kuyruklarda üç temel işlemin—ekleme, çıkarma (silme) ve sorgulama (göz atma)—kabın her iki ucuna da uygulanabileceğini hatırlatarak başlayalım. Söz konusu altı işlemin istisnai durumlarda farklı tepki veren iki ileti ile karşılandığı da düşünüldüğünde, yedi tanesi tablomuzun sağ kısmında yer alan on iki iletinin gizemi çözülür. Bunlara, temel işlemlerin yığıt ve kuyruk terminolojisindeki karşılıkları olan üçüncü sütunda listelenen dokuz iletiyi de eklersek, toplamda yirmi bir iletiyi buluruz. Collection'dan gelenler ve Deque'in geri kalan üç iletisi (descendingIterator, removeFirstOccurrence ve removeLastOccurrence) ile beraber düşünüldüğünde, bu sayı başta korkutucu gelebilir. Ancak, çift-uçlu kuyruğu ne şekilde kullanacağınıza karar vermenizle birlikte yirmi bir ileti aniden yığıt için üçe, kuyruk için üç veya altıya, çift-uçlu kuyruk içinse altı veya on ikiye düşecektir.

ArrayDeque dairesel arabellek (İng., circular buffer) şeklinde kullanılan bir dizi ile gerçekleştirim sağlar. Bu sayede, temel işlemlerin her iki uca uygulanmasına karşılık gelen tüm iletiler sabit zamanda işlerini bitirirler. Aynı nedenden ötürü, temel işlemlerin toptan uygulanmaları da eleman başına sabit bir maliyet sergileyecektir. Buna karşılık, kabın taranmasını gerektiren arama iletileri doğrusal zamanlı performansa sahiptirler. Son olarak, altyapıda kullanılan dizinin yetersiz sığaya sahip olduğunun görülmesi dizinin genişletilmesine neden olacağı için, ekleme iletilerinin nadiren de olsa bazen reklam edilenden düşük bir performans sergileyebileceği unutulmamalıdır. Bu duruma düşmemek için ArrayDeque nesnesini muhtemel kullanıma uygun bir sığa ile yaratmak yardımcı olacaktır.

Bağlaçlı Liste: `java.util.LinkedList`

VKÇ'nin genel liste gerçekleştirimi olarak sunduğu ikinci seçenek, List ve Deque arayüzlerini ardışık erişimli bir yapı kullanarak gerçekleştiren LinkedList sınıfıdır. Baş ve son düğümlerin tutacaklarını barındıran çift bağlaçlı bir yapıya sahip bu sınıfta ekleme ve çıkarma, liste içindeki bağlaçların güncellenmesiyle tamamlanır. Bunun doğal bir sonucu olarak, herhangi bir elemana erişmenin tek yolu, get/set gibi iletiler kullanılıyor olsa bile, ardışık erişimdir; istenen bir elemana erişilmesi için, söz konusu eleman öncesindeki/sonrasındaki tüm elemanların ziyaret edilmesi zorunludur. Dolayısıyla, doğrudan erişim üzerine kurulu ikili arama gibi algoritmalarda bu sınıf yerine ArrayList veya Vector gibi bir sınıfın kullanılması daha mantıklı olacaktır. Buna karşılık, araya eklemenin sık yapıldığı ve ardışık erişime mecbur olunan durumlarda—mesela, ekleme sıralaması (İng., insertion sort) algoritmasının gerçekleştiriminde—seçimin LinkedList'ten yana olması gerekir. Çünkü, bağlaçlı bir yapı kullanılarak gerçekleştirilen bir kabın ortasına yapılan eklemeler/çıkarmalar doğrudan erişimli kapların neden olduğu gibi kaydırmanın getireceği olumsuzluktan etkilenmez. Son olarak, kabın iki ucuna erişimin sabit maliyetli olması, size yığıt ve kuyruk gibi kısıtlı listeler için LinkedList'in çekici bir seçenek olduğunu düşündürebilir.

...
import java.util.LinkedList;
...
  Deque<Integer> yığıt = new Linked<>();
  Queue<Integer> kuyruk = new LinkedList<>();

Yukarıda sağlanan çözümün ArrayDeque kullanılarak sağlanan çözümle daha sağlıklı bir şekilde karşılaştırılabilmesi için, ArrayDeque'in altyapıda kullanılan dizinin boş konumları için maliyet ödetmesine karşılık, LinkedList'in her bir eleman için fazladan iki bağlaç tutmak zorunda olduğu unutulmamalıdır. ArrayDeque nesnesinin duruma uygun bir ilk sığaya sahip yaratılması imkanı ile birlikte ele alındığında, bu durumun temel işlemlerin zaman maliyetini marjinal de olsa ArrayDeque lehine çevirdiği görülecektir. Dolayısıyla, yığıt ve kuyruk kullanımı için ilk önerdiğimiz yöntemin daha doğru olduğu söylenebilir.

Değişken Uzunluklu Diziler: Vector
Hızlı Arama Zamanlı Kaplar

VKÇ'nin ortaya konduğu J2SE 1.2 öncesinde tasarlanıp gerçekleştirilmiş olan veri kaplarının dokümantasyonunda iki noktayı kafa karıştırıcı bulabilirsiniz. [Islah edilerek çerçeveye oturtulması olanaksız gözüken] Dictionary ve Stack sınıflarını kullanmaktan kaçınılması tavsiye edilirken, Hashtable ve Vector sınıflarında tamamıyla aynı şeyi yapan farklı adlara sahip pek çok ileti çifti göze çarpar. Her iki durumda da sebep, VKÇ'nin ortaya koyduğu standart ve söz konusu sınıfların bu standarda uyumdaki başarısı(zlığı)dır. Programcı olarak bizim payımıza düşen ise, dokümantasyonda önerildiği gibi, ilk iki sınıf yerine önerilen seçeneklerden yararlanmak ve diğer iki sınıfta standartta bulunan ada sahip iletileri kullanmaktır. Böyle bir yaklaşım, yazdığımız kodun yeniden kullanılabilirliğini artıracaktır. ↑
Metotlarının synchronized ilan edilmiş olması, Vector sınıfını tamamıyla izlek güvenlikli kılmaz. Bu şekilde sağlanan güvence metotların teker teker kullanımlarına ilişkindir; Vector sınıfındaki iki veya daha fazla sayıda metodun aynı atomik işlemin parçası olarak icra edilmesini gerektiren durumlarda, iş yine programcıya düşecektir. ↑
Aslına bakarsanız, sıralanmak istenen verinin ikillerini 0 veya 1 olmasına göre gruplara ayırarak işini gören bazı algoritmalar karşılaştırma işleminden yararlanmazlar. Ne var ki, bu algoritmaların uygulanabilirliği bazı ilkel türlere kısıtlı olduğu için, bu istisna genelleştirilerek vardığımız yargıyı boşa çıkarmak için kullanılamaz. ↑
Aslına bakacak olursanız, ayrıcalıklı kuyruktan yararlanarak yığıt ve kuyruk displinine sahip kapların oluşturulması mümkündür. Bunun için yapılması gereken, elemanların ekleme zamanlarına dair bilgi içermeleri ve bu bilginin ayrıcalıklı kuyruğun sıralama ölçütü olarak kullanılmasıdır. ↑

Clojure, Java Platformunun Fonksiyonel Programlama Dili

2012-01-11T15:43:00.001+02:00

Bu yazımızda, daha önceden fonksiyonel programlamaya aşık olup da JSM aleminde aşklarının karşılıksız kaldığını düşünenlerin yanıldığını anlatmaya çalışacağız: JSM'nin fonksiyonel programlama dillerinden Clojure'a (okunuş: Klojur) göz atacağız. Yeni bir programlama dili öğrenmek fikrinden korkanlarınızın içi rahat olsun, Common Lisp, Scheme gibi dilleri bilenlerde karşı konulmaz bir déjà vu hissi uyandıracak Lisp ailesinin bu genç üyesinin sıfırdan öğrenilmesi, anılan ailedeki dillerin yalın sözdizimi ve az sayıdaki kuralı nedeniyle pek fazla zorlayıcı olmayacak. Yeter ki, programlamanın aslında eğlenceli bir şey olabileceğine ve bir problemin birden çok farklı şekilde çözülebileceğine inanın.

Peki ama, neden Clojure?
Kurulum
Fonksiyonlar birer hesaplama nesnesidir
Temel veri türleri
Veri kapları
Fonksiyon tanımı, yeniden
Özyineleme

Peki Ama, Neden Clojure?

Çok yerinde bir soru. Zira, Clojure arkasında büyük bir şirket veya programcı topluluğunun bulunduğu bir programlama dili değil. Ancak; Java, Scala🔎, Jython, JRuby, BeanShell🔎, Groovy, vd. gibi, Clojure da bir JSM dili: Java programlama dilinin kullanımına hazır olan tüm kitaplıklar Clojure kaynak kodu içinden de kullanılabilir; Clojure kaynak kodu istenecek olursa sınıf dosyasına derlenerek Java platformunun parçası haline getirilebilir. Ayrıca, bazı diğer özelliklerinin Clojure'u önümüzdeki yıllarda daha çekici kılacağını söylemek falcılık olmayacaktır. Dolayısıyla, Clojure'u elinizin tersiyle itmeden önce biraz daha düşünmenizde yarar var.

Clojure'un Lambda Hesaplama Kuramı (İng., Lambda Calculus) üzerine inşa edilmiş bir fonksiyonel programlama dili olduğunu söyleyerek başlayalım. Süslü kısmı aradan çıkararak ifade edecek olursak, problem çözümünün matematikteki karşılıklarına benzer bir şekilde ele alınan ve fonksiyon adı verilen altyordamlar yoluyla sağlandığını söyleyebiliriz; doğal olarak, problemlerin fonksiyonların bileştirilmesiyle çözüldüğü bu paradigmada birimsellik aracı olarak fonksiyonlar kullanılır. Birinci sınıf vatandaş olan fonksiyonlar, diğer fonksiyonlara argüman olarak geçirilip, fonksiyonlardan sonuç olarak döndürülebilir ve herhangi bir bileşke türlü değerin bileşeni olarak tutulabilirler. Yani, C'de fonksiyon göstericileri, Java'da arayüzler vasıtasıyla zahmetli bir şekilde, kısmen elde edilebilen bir şey, Clojure'da çok daha kapsamlı bir paketin parçası olarak bedavaya gelir.¹ Bu, Google tarafından geliştirilmiş olup yoğun bir biçimde kullanılan ve Apache'nin Hadoop projesi vasıtasıyla özgür yazılım dünyasına kazandırdığı MapReduce adlı bulut hesaplama çerçevesinin önümüzdeki aylar, yıllar içinde karşınıza çıktığında işinizin daha kolay olacağı anlamını taşır. Çünkü, MapReduce kullanılarak üretilecek çözümler, fonksiyonel programlama dillerinin vazgeçilmezi map, reduce ve filter gibi yüksek dereceli fonksiyonların—argüman olarak fonksiyon alan ve/veya dönüş değeri olarak fonksiyon döndüren fonksiyon—birlikte kullanımını andıracaktır. Buna Hadoop temelli yazılım çerçevelerinin gerçekleştirim dilinin Java olması da eklendiğinde, çok çekirdekli hesaplamaya ince ayarlı bir JSM dili olan Clojure'un farklılaştırıcı özelliği takdir edilecektir.

Gelelim Lisp ailesi dillerinin belki de ustaları için en çekici olan özelliğine: bu dillerde kaynak kod ve veri için aynı gösterim kullanılır. Bir diğer deyişle, Clojure'un da üyesi olduğu Lisp ailesi dilleri eşgösterimlidir (İng., homoiconic). Bu, kaynak kodun veri olarak ele alınmasına olanak tanıdığı gibi, çalışmakta olan bir programın kendisine sunulan girdiyi kod olarak ele alıp işlemesine olanak tanır. Örneğin—Java kaynak kodu içinden XML dosyalarındaki kurulum bilgilerinin okunmasında olduğu gibi—yazılım sevkiyatı (İng., software deployment) sırasında güvenlik, seyir defteri güncelleme gibi müşteriye özel olarak farklı icra edilmesi istenebilecek hizmetlere dair bilgileri kurulum dosyasına Clojure programı yazar gibi yazıp bir diğer Clojure programından okuyarak işinizi görebilirsiniz. Ya da, kullanıcının girdi olarak sağladığı veriyi kod olarak ele alıp işleyerek programınızı çalışırken değiştirme şansına sahip olabilirsiniz.

Clojure'u özendirmek amacıyla öne süreceğimiz son sebep, eşgösterimlilik özelliği sayesinde diğer programlama dillerindekilerin çok ötesine geçen makro olanağıdır. Clojure makro işlemcisi, programın çalıştırılması öncesinde kaynak kodu o anda tanımlı bulunan makrolara uygun bir biçimde dönüştürür ve programcıların gördüğü ile yorumlayıcının işlediği kaynak kodun birbirlerinden farklılaşmasını sağlar. Böylece, programlama dilinde bulunmayan bir denetleme yapısının—mesela, koşut işlemeli bir döngü—dile kusursuz bir biçimde yamanarak pek çok programın daha kolay yazılması mümkün olacaktır. Benzer şekilde, yinelenen kod parçalarının şablon görevi gören makrolar yoluyla yazımı kolaylaştırılabilir. Programcının problem alanına yönelik yüksek düzey denetim yapıları ve kod şablonları yaratmasına olanak tanıyan bu özellik, Clojure'u (ve diğer Lisp ailesi dillerini) alana özel dil (İng., domain-specific language) gerektiren durumlarda öne çıkarmaktadır.

Kurulum

Sisteminizde bulunmadığı takdirde clojure.org/download adresinden indirebileceğiniz Clojure ortamının kurulumu, indirilen arşiv dosyasının içindeki clojure-x.y.z.jar dosyasının sınıf yolu üzerine konulması kadar basit.² Yorumlayıcı (Clojure komut kabuğu) anılan paketin veya bu paketteki main sınıfının JSM'ye geçirilmesi ile çalıştırılabileceği gibi, evvelden kurulu bir Clojure ortamının bulunması durumunda clojure komutu ile de çalıştırılabilir.³

$ # java -cp ".:/arşiv/yolu/clojure-1.3.0.jar:$CLASSPATH" clojure.main
$ # java -cp ".:$CLASSPATH" -jar /arşiv/yolu/clojure-1.3.0.jar
$ clojure
Clojure 1.3.0
user=>

Yorumlayıcının başlaması, oku-değerlendir-bas döngüsünün (İng., read-evaluate-print loop [REPL]) başladığı anlamına gelir. Bundan sonra yapmamız gereken, Clojure dilinin sözdizimine uygun bir şeyler girip basılan sonuçları gözlemlemektir.

user=> (+ 2 3) → 5
user=> (def sayı 5)
#'user/sayı
user=> (+ 2 3 sayı) → 10
user=> (* 2 (+ 3 4)) → 14
user=> (System/exit 0) ; Komut kabuğuna Ctrl-D ile de dönülebilir
$

Oturumu inceleyerek bazı saptamalarda bulunalım. Öncelikle; Clojure kaynak kodu, yorumu ilk konumundaki simgeye göre değişen, ayraçlarla çevrili formlardan oluşur. İstenecek olursa, bir form bir diğerinin içine gömülebilir. Böyle bir durumda, en son açılan ayracın ilk kapatılması ve dıştaki formun bittiği noktada eşleştirilmemiş ayraç olmaması gerektiği unutulmamalıdır.

Formlar, deyimler, makrolar ve özel formlar olmak üzere üçe ayrılır. Deyimler, ilk konumdaki simgenin geri kalanlara uygulandığı işlemler olarak ele alınırken, makrolar kodu dönüştüren işlemciler olarak görülebilir; özel formların işleyiş mantığı duruma göre değişir. Örneğin, (+ 2 3) toplamanın 2 ve 3 argümanlarına uygulandığı işleme karşılık gelen bir deyim iken, (def sayı 5) çalışma ortamını 5 değerine sahip sayı adlı tanımlayıcının varlığı ile güncelleyen bir özel formdur.

Kod ve veri gösterimi için işleç-önde gösterimin şaşkınlığını üzerinizden attıktan sonra, bu seçimin aslında bazı artılarının olduğunu görebilirsiniz. Örneğin, bu gösterimin bir sonucu olarak ortaya çıkan tüm deyimlerin ayraç çifti ile çevrelenmesi zorunluluğu, öncelik sırası sorununu ortadan kaldırır; her bir kapatıcı ayraç eşleştiği ayracın başlattığı formun değerlendirilmesi gerektiğini bildirir. Ayrıca, kapatıcı ayraca kadar her şey argüman olarak yorumlandığı için, aynı işleç argümansız kullanılabileceği gibi, 3 veya 5 argümanlı da kullanılabilir. Mesela, (*) çarpmanın etkisiz elemanı olan 1 değerini döndürürken, (* 1 2 3 4 5) 5!, yani 120, değerini döndürür.

Son olarak, System/exit Java platformundaki System sınıfının exit adlı metoduna atıfta bulunmaktadır. Yani, oturumun son satırında, bir Java programı olan yorumlayıcıya programdan 0 değeri döndürecek şekilde çıkmak istediğimizi söylüyoruz. Genelleştirecek olursak, Sınıf adlı bir Java platformu sınıfının üye adlı static bir özelliğini kullanmak istediğimizde yapmamız gereken, deyimimizin ilk konumuna Sınıf/üye koymaktan ibarettir.

Fonksiyonlar Birer Hesaplama Nesnesidir

Mesele fonksiyonel bir programlama dilini anlatmaya çalışmaksa, yapılması gereken ilk şeylerden biri, hiç kusku yok ki, birimsellik aracı olan fonksiyonun tanımı ve kullanımından bahsetmektir. Bahis esnasında fonksiyonların matematikteki adaşlarına benzediği ve diğer türden değerlerle birlikte birinci sınıf vatandaşlar olarak kullanılabileceği akıldan çıkarılmamalıdır. Gelin, ne kastedildiğini aşağıdaki tanımlardan görelim.

user=> (def çarp (fn [a b] (* a b)))
#'user/çarp
user=> (def çarp2 #(* %1 %2))) ; çarp ile aynı
#'user/çarp2
user=> (def arg1 3)
#'user/arg1
user=> (def arg2 (read)) ; standart girdiden veri alıyor
17
#'user/arg2
user=> (çarp arg1 arg2) → 51
user=> ((fn [x y] (* x y) 4 5) → 20
user=> (#(* % %2) 6 7) →42
user=> (def çarp3 (partial çarp 3))
#'user/çarp3
user=> (çarp3 20) → 60

çarp ve çarp2'nin arg1 ve arg2 ile aynı form kullanılarak tanımlandığına dikkatinizi çekerek başlayalım. Komutsal programlama dillerinden gelenlere başta aykırı gözükebilecek bu durum aslında çok doğal: ne de olsa, ister tamsayı olsun isterse fonksiyon, dört tanımlayıcı da birer değeri simgeliyor. Değerlerden ikisi sayma kavramının örnekleri iken, diğer ikisi hesaplama kavramının örneklerini veriyor; ikisi (arg1 ve arg2) matematikte bağımsız değişken olarak ifade edilirken, diğerleri iki argümanlı bağımlı değişkenler olarak adlandırılıyor. Dolayısıyla, heseplamayı soyutlayan fonksiyon değerlerinin, 11. ve 12. satırlarda olduğu gibi, ad verilmeksizin kullanılması da bir o kadar doğal. Ne de olsa, 3 sabitini arg1 değeri ile temsil etmeden de kendi başına kullanabiliyoruz, fonksiyon değerlerini de ad vermeden kullanabilmeliyiz.

çarp2'nin tanımı yüksek dereceli fonksiyonlara fonksiyon geçirilmesini kolaylaştıran #() ile yapılıyor. Tek kullanımlık fonksiyonların simgesel bir değişkene atanmadan adsız kullanımını kolaylaştıran bu gösterimde, % ilk argümanı temsil ederken, %n n nolu argümana karşılık gelir.

Bazı yüksek dereceli fonksiyonlar ve kullanımlarına dair örnekler aşağıdaki tabloda verilmiştir. Yorumlayıcının oku-değerlendir-bas döngüsünün değerlendirme aşamasında uyguladığı iki temel fonksiyondan biri olan apply—diğeri eval'dir—ilk argümanındaki fonksiyonu daha sonraki argümanlara uygular. Bu işlem sırasında, son argümandaki kap parçalanarak eleman sayısı kadar farklı argüman olarak uygulanması istenen fonksiyona geçirilir. comp fonksiyonu, matematikten bildiğimiz bileşke fonksiyon yaratma işlecidir ve aldığı 0 ya da daha fazla sayıda fonksiyonun bileşkesi olan bir fonksiyon döndürür. juxt parametre listesindeki fonksiyonları ayrı ayrı bilahare geçirilecek argümanlara uygulayacak bir fonksiyon döndürerek işini görür. memoize fonksiyonu argümanındaki fonksiyonun daha hızlı çalışmasını sağlayabilmek adına daha önce yapılan hesaplamaları önbellekte tutup tekrar hesaplamanın önüne geçerek hızlandırmaya çalışan bir fonksiyon döndürür. Son olarak, partial fonksiyonu ilk argümanındaki fonksiyonun istediğinden az sayıda argümanla uygulanmasını olanaklı kılarak geri kalan argümanları bekleyen bir başka fonksiyon döndürür.

*Bazı yüksek dereceli fonksiyonlar*
Fonksiyon	İşlev	Kullanım
`apply`	Fonksiyon uygulama	`(apply` fn arg `&` diğer-arglar`)` → değer
`comp`	Fonksiyon bileştirme	`(comp` `&` fnler`)` → fn
`juxt`	Fonksiyon uygulama	`(juxt` fn `&` diğer-fnler`)` → fn
`memoize`	Önbellekli fonksiyon uygulama	`(memoize` fn`)` → fn
`partial`	Kısmi fonksiyon uygulama	`(partial` fn arg `&` diğer-arglar`)` → fn

user=> (apply * 2 3 (range 4 10)) → 362880
user=> (def fog (comp #(* % %) #(+ %1 %2)))
#'user/fog
user=> (fog 3 4) → 49
user=> ((juxt * + /) 6 4) → [24 10 3/2]
user=> (def önbellekli-f (memoize f))
#'user/önbellekli-f
user=> (önbellekli-f ...) → ...

Seçtiğimiz örneğin basit olması nedeniyle yapılan tek deyim uzunluğundaki tanımlar sizi yanıltmasın; istenecek olursa, tıpkı kıvrımlı ayraçlarla ({}) belirtilen Java bloklarında olduğu gibi, do özel formunu kullanarak gövdeyi istediğimiz sayıda deyimden oluşacak biçimde uzatabiliriz. İçerdiği formları baştan sona ardışık bir şekilde işleyen bu form, sonucu olarak son işlenen formun döndürdüğü değeri döndürür. Mesela, çarp2'nin tanımının bir selamlama ile genişletilmesi istenecek olursa, bu #(do (println "Selam") (* %1 %2)) tanımı ile yapılabilir. Benzer bir değişikliğin fn formunun kullanıldığı örnekte yapılmasına gerek yoktur; bu form gizli bir do ile çevrelenmiş gibi çalışır.

Temel Veri Türleri

Desteklenen temel veri türlerine geçmeden şu noktayı vurgulayalım: Clojure dinamik türlü bir programlama dilidir. Yani, Clojure'da tanımlayıcılar dil işlemcisine yardım etmek amacıyla türe dair üstbilgi ile nitelenmezler; bir tanımlayıcının türü kendisine yapılan ilkleme/atama sonrasında temsil etmeye başlayacağı değere göre belirlenir. Statik türlemeli dillerde derleyicinin denetimi sonrasında yazılmasına izin verilmeyecek bazı işe yarar programların yazılıp çalıştırılabileceği anlamına gelen bu özellik, kimilerinin düşündüğünün aksine, Clojure'un zayıf bir tür denetimine sahip olması demek değildir. Kaynak kodun işlenmesi esnasında tüm işlemlerin tür denetimini yapan Clojure, türleme hatasına sahip herhangi bir işlemin icra edilmesine izin vermez. Özetlemek gerekirse, Clojure hem dinamik türlüdür hem de kuvvetli türlemeye sahiptir.⁴

Aşağıdaki tablodan da görülebileceği gibi, Clojure Java programlama dili ile ortak temel türlerden değerleri Java platformundaki sarmalayıcı sınıfların nesneleri olarak temsil eder. Biçimlendirme yapılmadığı müddetçe, tamsayılar Long, gerçel sayılar ise Double türüyle temsil edilirler. İstenecek olursa, Java'daki ilkel türlerle aynı adlara sahip fonksiyonlardan biri kullanılarak biçimlendirme yapılabilir. Örneğin, (byte 3) normalde Long olarak ele alınacak 3'ü Byte türlü bir sabite çevirecektir.

*Clojure'daki temel türler*
Gösterim	Tür	Kavram
`\a`	`java.lang.Character`	Karakter
`"Katar"`	`java.lang.String`	Karakter katarı
`5`	`java.lang.Long`	Tamsayı
`5N`^*	`clojure.lang.BigInt`	Tamsayı
`5.0`	`java.lang.Double`	Gerçel sayı
`5.0M`	`java.math.BigDecimal`	Gerçel sayı
`22/7`, `(/ 22 7)`	`clojure.lang.Ratio`	Kesirli sayı
`(> 1 0)`	`java.lang.Boolean`	Mantıksal değer
`'simge`	`clojure.lang.Symbol`	Tanımlayıcı adı, simgesel sabit, anahtar değeri
`:anahtar`	`clojure.lang.Keyword`	Simgesel sabit, anahtar değeri
^*: Clojure 1.3 ve sonrası.

Kayan noktalı sayı aritmetiğinde ortaya çıkabilecek taşmalar Java'da olduğu gibi kullanılmakta olan sayı formatındaki özel değerler ile temsil edilirken🔎, tamsayılarda sınır aşımı programcıya ArithmeticException ayrıksı durumu ile bildirilir. Bunun yerine Long'dan clojure.lang.BigInt'e bir genişletme istenecek olursa, aritmetik işlem adı sonuna ' eklenmesi yeterli olacaktır. Buna göre, (+ 1 Long/MAX_VALUE) ayrıksı duruma neden olurken, (+' 1 Long/MAX_VALUE) 9223372036854775808N değerini döndürecektir.⁵

İki tamsayının oranını temsil eden kesirler, pay ve paydanın sadeleştirilmesiyle elde edilen iki java.math.BigInteger (clojure.lang.BigInt değil!) nesnesi olarak tutulurlar. Her işlemin bu BigInteger nesnelerden yararlanarak yapılması ve nihai sonucun bunu takip eden sadeleştirmeden sonra elde edilmesi, kesirli sayılarla işlemlerin yavaş olmasına neden olur. Bundan dolayıdır ki, Clojure sadeleşme sonucu paydası 1 olan kesirleri tamsayıya dönüştürerek yoluna devam eder. Sizin de yüksek duyarlık gerektiren hesaplar dışında kesirleri kullanmaktan kaçınmanız yerinde olacaktır.

Lisp ailesi dışındaki programlama dillerinde pek görünmeyen simgeler, tanımlayıcı adlarının türü olarak tanımlanabilir. Bundan ne kastettiğimizi (def i 5) özel formunu inceleyerek açmaya çalışalım. Bu tanımlama sonrasında i simgesi 5 değerine sahip bir değişken olarak ortama eklenir. Bir diğer deyişle, bu tanımla birlikte i 5'i simgelemeye başlar. Bu noktadan sonra, i'ye atıfta bulunulduğunda yorumlayıcı i yerine i simgesinin ortamdaki değeri olan 5'i koyacaktır. Örneğin, (+ i 3) (+ 5 3) haline dönüştürülecektir. Ancak, istenecek olursa simgenin önüne ' konulmak suretiyle bu dönüşümün önüne geçilebilir ve simgelenen değer yerine simgenin kendisi kullanılabilir. Böylesine bir kullanım, hünerini içerdiği tutanak değerlerinin anahtarlar eşitliklerini denetleyerek sergileyen eşlemlerde (ve diğer arama yapılarında) oldukça sık görülür. Çünkü, simgelerde eşitlik denetimi çok hızlı yapılabilir. Aynı özellikten anahtar türü için de bahsedebiliriz. : ile başlayan anahtarlar, başka bir şeyi göstermeyen simgeler olarak düşünülebilir. Yani, yapılacak bir tanım yardımıyla bir değeri gösteren simgelerin aksine, anahtarlar herhangi bir değeri simgelemez. Aynı zamanda, simgelerin program metnindeki her geçişi diğer geçişlerinden farklı iken, herhangi bir anahtarın tüm geçişleri aynıdır.

Veri Kapları

Clojure tarafından sağlanan veri kapları doğrusal kaplar (liste, vektör🔎), kümeler, eşlemler🔎 ve karakter katarları🔎 olmak üzere dört kategoride incelenebilir. Kategoriler veri kaplarını eşitlik temelinde denklik sınıflarına ayırmakta da kullanılır. Eşit addedilmeleri için kapların aynı türden olması gerekmez; dolaşıldıklarında karşılıklı elemanlarının eşit olduğu görülen aynı kategorideki tüm kaplar birbirine eşittir.

Clojure'da desteklenen veri kapları, aşağıdaki tablodan da görülebileceği gibi, yapıcı görevi gören fonksiyonların yanısıra özel sözdizimi yardımıyla da yaratılabilir. Dikkat edilirse, küme ve eşlemler için, Java Veri Kapları Çerçevesi'ndekileri anımsatan, farklı yapıcılar sağlandığı görülecektir. Bu, aynı zamanda söz konusu kap için (class kap) deyimiyle keşfedilebilecek farklı bir gerçekleştirim seçildiği anlamına gelmektedir.

*Clojure destekli kaplar*
Cins	Yapıcı	Özel gösterim
Liste	`(list 1 2)`	`'(1 2)`
Vektör	`(vector 1 2)`	`[1 2]`
Eşlem		`{:Adana 1 :İzmir 35}`
	`(hash-map :Adana 1 :İzmir 35)`
	`(sorted-map :Adana 1 :İzmir 35)`
Küme	`(hash-set :insan :şempanze)`	`#{:insan :şempanze}`
Küme	`(sorted-set :insan :şempanze)`
Kar. katarı	`(str \a \b \c)`	`"abc"`

Clojure'dakilere ek olarak, Java Veri Kapları Çerçevesi'nce sağlanan eşdeğer kaplardan da yararlanılabilir. Aynı kategoride addedilen bir Clojure kabı ile Java eşdeğerinin hemen hemen aynı olduğu söylenebilir. Eşit içeriğe sahip eşdeğer kaplar birbirine eşittir; Clojure kaplarına uygulanan fonksiyonlar Java eşdeğerlerine de uygulanabildiği gibi, Clojure kapları Java nesnesi olarak da kullanılabilir. İlişkin örnekler aşağıda verilmiştir.

user=> (import '(java.util ArrayList Vector))
java.util.Vector
user=> (def java-ls (ArrayList.))
#'user/java-ls
user=> (.add java-ls 1) → true
user=> (doto java-ls (.add 2) (.add 3)) → #<ArrayList [1, 2, 3]>
user=> (def java-vek (Vector. java-ls))
#'user/java-vek
user=> (= java-vek '(1 2 3) [1 2 3] java-ls) → true
user=> (= #{1 2} '(1 2)) → false
user=> (map #(* % %) java-vek) → (1 4 9)
user=> (reduce (fn [a b] (if (> a b) a b)) '(80 70 85)) → 85
user=> (filter odd? [1 2 3 4 5]) → (1 3 5)
user=> (remove odd? #{1 2 3 4 5})) → (2 4)
user=> (.size [1 2 3 4]) → 4
user=> (apply str (map #(Character/toUpperCase %) "Abc")) → "ABC"

Kodu incelerken şu noktaların bilinmesi yardımcı olacaktır: i) import bir veya daha fazla sayıda sınıf dosyasını içselleştirip çalışma ortamında görünür hale getirir, ii) . ile sonlanan sınıf adları Java platformundaki bir sınıfın yapıcılarından birini çağırır, iii) önüne . eklenmiş fonksiyon adları ilk argümanda belirtilen alıcıya ileti göndermekte kullanılır, ve iv) doto makrosu ikinci ve sonrasındaki argümanlarda belirtilen iletileri ilk argümanda belirtilen alıcıya yönlendirir.

*Kaplar üzerinde çalışan bazı yüksek dereceli fonksiyonlar*
Fonksiyon	İşlev	Kullanım
`map`	Kap dönüşümü	`(map` fn k & diğer-kaplar`)` → kap
`reduce`	İndirgeme, özetleme	`(reduce` f k`)`, `(reduce` f ilk-değer k`)` → değer
`filter`	Süzme	`(filter` fn k`)` → kap
`remove`	Silerek süzme	`(remove` fn k`)` → kap

Clojure ve Java veri kapları arasındaki şu temel farklılık unutulmamalıdır: Java'da kap içeriği uygun iletiler yardımıyla değiştirilebilirken, Clojure'daki tüm kaplar değişmez içeriklidir. Bir başka deyişle, Clojure'da kaplar yaratılmaları sonrasında değiştirilemezler. Değişme etkisinin yaratılması için içerik güncelleme işlemleri yapan fonksiyonların dönüş değerlerinin kullanılması gerekir.

user=> (def çete '("Veli" "Selami"))
#'user/çete
user=> (def yeni-çete (conj çete "Ali"))
#'user/yeni-çete
user=> çete → ("Veli" "Selami")

Düşük maliyetli bir biçimde gerçekleştirilebilen bu stratejinin (bkz. 1, 2) temelinde programcıyı değişken içerikli kaplardan uzak tutmak suretiyle çok izlekli program yazma bağlamında daha kolay sınanabilir kod üretmeye sevketmektir. String sınıfının🔎 sabit içerikli olmasının temelinde de yatan bu yaklaşım, değişmeyecek bir kabın birden çok izlekten sakıncasız bir biçimde kullanılabileceği gerçeğinden yararlanır. Aslında, Java Veri Kapları Çerçevesi de dikkatle bakan gözlere aynı mesajı vermektedir: arayüzlerde yer alan tüm içerik güncelleyici iletilerin başlığı UnsupportedOperationException ayrıksı durumunu içerir. Clojure kapları buna dayanarak, Clojure'a özel fonksiyonlara ek olarak [Java kodu ile birlikte çalışmak adına] Veri Kapları Çerçevesi'nin ilişkin arayüzünü gerçekleştirdiklerinde söz konusu iletileri desteklemediklerini bildiren UnsupportedOperationException ayrıksı durumunu fırlatacak şekilde gerçekleştirir.

user=> (def vek [1 2])
#'user/vek
user=> (.size vek) → 2
user=> (.toString vek) → "1 2"
user=> (.add vek 3) → java.lang.UnsupportedOperationException (NO_SOURCE_FILE:0)

map, reduce gibi pek çok fonksiyonun ayırt etmeksizin tüm kaplara uygulanabilmesi, bu tür fonksiyonların diğer Lisp ailesi dillerinde olduğu gibi liste veya bir diğer türden kap almak yerine clojure.lang.ISeq arayüzünü gerçekleştiren bir kap alıyor olmasıyla mümkün olur. Buna göre, Clojure listelerinin gerçekleştirimini sağlayan Java sınıfının aşağıdaki gibi olduğunu söyleyebiliriz.

package clojure.lang;

public class PersistentList extends Obj implements ISeq, ... { ... }

ISeq arayüzü, eleman sayısını döndürüren count ve ilk argümanındaki kaba ikinci argümanındaki değerin eklenmiş halini döndüren conj'un yanısıra, yegâne argümanındaki kabın dolaşılmasına yarayan bir liste döndüren seq iletisini içerir.

Son olarak değineceğimiz nokta, vektör veya eşlem gösteren bir simgenin fonksiyon adı konumunda kullanılabilecek olmasıdır. Aşağıdaki kod parçasında olduğu gibi, bir vektöre indis, bir eşleme ise anahtar değeri verilecek olursa ilişkin kap içindeki o indis veya anahtar karşılık gelen değer döndürülür.

user=> ([1 2 3 4] 1) → 2
user=> (plaka-nolar :İzmir) → 35

Fonksiyon Tanımı, Yeniden

Tanımının uzamasıyla birlikte fonksiyon gövdesinin anlaşılması da zorlaşacaktır. Bu etkiyi azaltmak amacıyla, gerçekleştirimimize yorum ve üstbilgi eklemeyi düşünebiliriz. Böyle bir durumda, makro işlemcisi tarafından def ve fn formlarına dönüştürülecek olan defn makrosunu kullanmamız daha yerinde olacaktır.

Selamlar.clj

(import '(java.util Calendar GregorianCalendar))

(defn selamlar
  "Argümanında geçirilen kişilere selam verir. Bunu yaparken aşırı yüklemeden yararlanır."
  {:yazar "Tevfik AKTUĞLU" :tarih (GregorianCalendar. 2012 Calendar/JANUARY 7)}
  ([tanıdık] (println "Selam," tanıdık))
  ([x y & diğerleri] (println "Selam millet!"))
  ([] (println "Selam, kim olursan ol!")))
...

Yukarıdaki fonksiyon tanımı, üç farklı parametre listesine göre üç gövde sağlamaktadır. Bir bakıma, hepsinin adı selamlar olan üç ayrı fonksiyon tanımlanmaktadır. Bu fonksiyonlardan ilki tek argümanlı iken, ikincisi 2+ argüman beklemektedir; son gövde tanımı ise argümansız kullanım durumunda işlenecektir. Değişken sayıda argüman alan seçenekte, ikinci argüman sonrasında geçirilecek tüm değerlerin bir listeye konulup & imini takip eden parametreye (diğerleri) karşılık gelen argümanda geçirileceği söylenmektedir.

defn makrosu fonksiyon tanımında kullanılan diğer formların sunmadığı iki olanak sunmaktadır. Bunlardan ilki, tanımlanmakta olan fonksiyonun adını takiben sağlanan ve daha sonra doc fonksiyonuyla sorgulanabilecek dokümantasyon yorumudur. İkinci olanak ise, programcının gereksinimlerine göre seçeceği üstbilgilerin fonksiyon tanımına iliştirilmesidir. Örneğimizde, dokümantasyon yorumları sonrasındaki üstbilgi eşlemi vasıtasıyla kodu yazan kişi ve en son güncelleme tarihi bilgilerini selamlar simgesine iliştiriyoruz.

;;Sınıf yolu üzerinde bulunan Selamlar.clj dosyasındaki formları yükler. 
user=> (load "Selamlar") → nil
user=> (selamlar) → nil
Selam, kim olursan ol!
user=> (selamlar "Tevfik") → nil
Selam, Tevfik
user=> (selamlar "Ali" "Veli" "Selami") → nil
Selam millet!
user=> (doc selamlar) → nil
------------------------
user/selamlar
([tanıdık] [x y & diğerleri] [])
  Argümanında geçirilen kişilere selam verir. Bunu yaparken aşırı yüklemeden yararlanır.
user=> (meta (var selamlar))
{:ns #<Namespace user>, :name selamlar, :file "Selamlar.clj",..., :tarih ...}

selamlar'a alternatif olarak sunulan ve 0+ argüman geçirilerek çağrılabilecek aşağıdaki selamlar2 fonksiyonu, yeni bazı şeyler sunmakta. Bunlardan ilki, parametre listesi sonrasındaki önkoşul tanımıdır. Bilenlerin Eiffel programlama dilinden anımsayacağı sözleşme temelli tasarımın (İng., Design by Contract) bir parçası olan önkoşul (İng., precondition), fonksiyonun her çağrılışı öncesinde denetlenir. Sonucun olumsuz olması, sağlıklı çalışma için karşılanması zorunlu görülen bir koşulun oluşmadığı anlamına gelir ve bu bilgi fonksiyon çağrılmaksızın programın bitirilmesini takiben uygun bir mesajla kullanıcıya bildirilir. Mesela, selamlar2 örneğinde selam verilecek kişileri temsil eden argümanların toplandığı listenin 3 veya daha az sayıda elemanı olması bir önkoşul olarak tanımlanıyor. Tamamlayıcı bir denetim, fonksiyon çağrısının sona erdiği noktada karşılanması zorunlu görülen durumların belirtilmesini mümkün kılan sonkoşulları listeleyen :post ile yapılabilir.

...
(defn selamlar2
  "cond formundan yararlanarak argümanında geçirilen kişilere selam verir. Bu arada, önkoşul denetimiyle 4 ve daha fazla sayıda kişiden oluşan gruplara selam vermeyerek asayişi korur."
  {:yazar "Tevfik AKTUĞLU" :tarih (GregorianCalendar. 2012 Calendar/JANUARY 7)}
  [& ahali] {:pre [(< (count ahali) 4)]}
  (let [nüfus (count ahali)]
    (cond
      (> nüfus 1) (println "Selam millet!")
      (= nüfus 1) (println "Selam," (first ahali))
      :aksi-takdirde (println "Selam, kim olursan ol!"))))

Fonksiyon tanımında dikkat çekilmesi gereken bir diğer nokta, blok değişkenlerin tanımını olanaklı kılan let özel formudur. Kendisine sağlanan vektörün tek sayılı sıralardaki elemanlarını değişken adı olarak kabul eden let, değişkeni takip eden değeri ilkleme amacıyla kullanır. Buna göre örneğimizdeki let formu, nüfus adına sahip ve argümanda geçirilen listenin eleman sayısıyla ilklenmiş bir yerel değişken tanımlamaktadır. Tanımlanan blok içindeki cond makrosu ise, C-temelli dillerdeki switch-case yapısına benzer bir görev görür: koşulları tepeden aşağıya sıralı bir biçimde sınar ve doğru olduğunu gördüğü ilk kolun formunu işler. Tüm durumların kapsanması için son kola her zaman doğru olacağı bilinen bir koşul konmalıdır. false ve nil dışındaki tüm değerler doğru kabul edildiği için, örneğimizde bu görevi :aksi-takdirde anahtarı görmektedir.

user=> (selamlar "Ali" "Veli" "Selami" "Nuri") → nil
java.lang.AssertionError: Assert failed (< (count millet) 4) (NO_SOURCE_FILE:0)
user=> (find-doc "selamlar") → nil
------------------------
user/selamlar
([tanıdık] [x y & diğerleri] [])
  Argümanında geçirilen kişilere selam verir. Bunu yaparken aşırı yüklemeden yararlanır.
-------------------------
user/selamlar2
([& ahali])
  cond formundan yararlanarak argümanında geçirilen kişilere selam verir. Bu arada, önkoşul denetimiyle 4 ve daha fazla sayıda kişiden oluşan gruplara selam vermeyerek asayişi korur.

Özyineleme

Yazımızın son kısmında fonksiyonel programlama dillerinin birincil yineleme yöntemi olan özyinelemeye değineceğiz. Bu yapmamızın nedeni, Clojure'un komutsal dillerden gelenlere tanıdık gelecek türden döngüleri desteklememesi değil. Elbette ki, dilin kendisinde olmasa bile Clojure'daki gibi bir makro olanağınız varsa, bildik tüm döngüleri ve fazlasını özyineleme kavramını kullanarak tanımlayabilrsiniz. Derdimiz, fonksiyonel programlamadan optimize edilen özyinelemeli çağrılara alışmış olanlara ufak bir uyarıda bulunmak. Çok sallanmadan faktöryel fonksiyonunu gerçekleştiren aşağıdaki tanımla başlayalım.

(defn ! [n]
  {:pre (pos? (inc n))}
  (if (<= n 1)
    1
    (* n (! (dec n)))))

Argümanının eksi olmaması önkoşuluna sahip gerçekleştirimimiz, özyinelemenin bitiş koşulu olarak argümanının 1 veya 0 olmasını seçmiş ve bu durumda 1 döndürüyor. Aksi takdirde, tümevarım adımında ifade edildiği gibi, problem kendi türünden daha basit bir probleme indirgenerek çözüm sağlanıyor: argüman ile argümanın bir eksiğinin faktöryeli çarpılıp sonuç olarak döndürülüyor. Ancak, bildirimsel (İng., declarative) olması nedeniyle doğruluğu kolayca kanıtlanabilecek gerçekleştirimimizin—ne de olsa, çözümü programlama dünyasına özel yapıları kullanarak sağlamaktansa problem tanımını birebir çevirerek sağlıyoruz—sonsuz döngülerle boğuşmuş olanlara pek de yabancı gelmeyecek bir sorunu var: bitiş koşuluna uzak bir ilk durumun verilmesi durumunda, özyinelemeli çağrıların sayısı artacak ve argümanların yerleştirildiği çağrı yığıtı dolarak hesaplamamız sonuç döndürmeden StackOverflowError ile sona erecektir.

user=> (! 5) → 120
user=> (! 100000) → java.lang.StackOverflowError (NO_SOURCE_FILE:0)

Ortaya çıkan sorun iki şekilde çözülebilir: i) ürettiği ara sonuçları biriktirici argümanlar yoluyla bir sonraki çağrıya aktaran özyinelemeli bir çözümle, ii) özyineleme yerine döngü kullanarak. Gelin birinci şıkkın gerçekleştirimi olan aşağıdaki koda bir göz atalım.

(defn !2 [n]
  {:pre (pos? (inc n))}
  (letfn [
    (!-iç [n biriktirici]
      (if (<= n 1)
        biriktirici
        (!-iç (dec n) (* biriktirici n))))]
    (!-iç n 1)))

Örneğimizde, kullanıcının !2'ye sağladığı değer yerel fonksiyona o ana kadarki hesaplamanın özeti olarak niteleyebileceğimiz biriktiricinin ilk değeri ile birlikte geçiriliyor. Kullanıcının görmediği !-iç'i incelediğimizde, tümevarım adımının özyinelemeli çağrı sırasında ikinci argümanı o anki ilk argümanla çarparak güncellediğini ve bitiş koşulunun oluştuğu noktada ise 1 yerine biriktirilmiş değeri döndürdüğünü görüyoruz. Bu dönüşümü yapmaktaki amacımız, özyinelemeli çağrıyı fonksiyon içinde en son yapılan iş haline getirmek ve böylece fonksiyonel programlama dillerinde sıklıkla uygulandığını bildiğimiz kuyruk çağrısı eniyilemesinden yararlanmaktır. Gelin görün ki, kazın ayağı öyle değil! JSM üzerine inşa edilmiş olan Clojure, JSM'nin kuyruk çağrısı eniyileme desteği vermemesi nedeniyle bizi utandırıyor.

user=> (!2 100000) → java.lang.StackOverflowError (NO_SOURCE_FILE:0)

Derdimizin çaresi, Clojure'a işi JSM'ye bırakmadan kendi yapabildiği kadarıyla yapmasını söylemek. Bu ise, aşağıdaki gibi özyinelemeli çağrıların olduğu yerlerde, fonksiyon adı yerine recur yazmakla mümkündür. recur özel formu, kuyruk konumunda yapılan özyinelemeli çağrıları arka planda goto benzeri birer sıçrama komutuna çevirir. [Sadece özyinelemeli çağrılar eniyilenir; genel kuyruk çağrısı eniyilemesi yapılmaz!] Bu, çağrı yığıtında ilk çağrıdaki argümanların işgal ettiği yerlerin yeniden kullanılacağı ve dolayısıyla sabit bellekle işimizin halledileceği anlamına gelir; ayrıca, fonksiyon çağrıları yerini daha ucuz olan sıçrama komutlarına bırakacağı için çalışma hızı da olumlu etkilenecektir. Bunu time makrosu yardımıyla görebilirsiniz.

(defn !3 [n]
  {:pre (pos? (inc n))}
    (letfn [
      (!-iç [n biriktirici]
        (if (<= n 1)
          biriktirici
          (recur (dec n) (* biriktirici n))))]
      (!-iç n 1)))

user=> (time (!3 2000)) → "Elapsed time: 20.266474 msecs" 33162...
user=> (time (!2 2000)) → "Elapsed time: 24.969519 msecs" 33162...

Bir diğer çözüm yöntemi loop özel formundan yararlanır. Döngü tutkunu olanları özyinelemeye alıştırmak için önerilebilecek bu form, eniyilenmiş özyinelemeli kuyruk çağrısı çözümüne yakın, hatta daha iyi bir çalışma hızı sağlar. Hızı daha da iyileştirmek isteyenlere önbellekli fonksiyon uygulaması olanağını sağlayan memoize fonksiyonu önerilir. Ancak; önceden yapılmış bazı hesaplamaları tekrar hesaplamaktansa kaydettiği sonucu kullanarak işini gören bu yüksek dereceli fonksiyonun argümanları dışında çağrı ortamına bağımlılığı bulunan fonksiyonlarla çalışamayacağı akılda tutulmalıdır.

(defn !4 [n]
  {:pre (pos? (inc n))}
  (loop [i n, biriktirici 1]
    (if (<= i 1)
      biriktirici
      (recur (dec i) (* biriktirici i)))))

user=> (def !4-hızlı (memoize !4))
#'user/!4-hızlı
user=> (time (!4-hızlı 1900)) → "Elapsed time: 27.253187 msecs" 33162...
user=> (time (!4-hızlı 2000)) → "Elapsed time: 21.0582 msecs" 33162...

Tüm diğer zaman ölçümlerinde olduğu gibi, hıza dönük yorumların beklenen ortalama çalışma hızı düşünülerek yapıldığı unutulmamalıdır; döndürülen değerlerin sisteme ve yüke göre değişmesi, önbellekli uygulama örneklerinde önbellek yönetiminden kaynaklanan beklenmedik farkların oluşması sizi şaşırtmamalıdır.

BeanShell
Scala

Java SE 8 ile birlikte, kod örtülerinin bu eksikliği büyük ölçüde gidereceğini söyleyebiliriz. Dolayısıyla, 2013'ün ikinci yarısında yargımızın Java bölümü geçerliğini yitirmiş olacak. ↑
Clojure programlama dilinin resmi sitesine gittiğinizde, Screencast etiketli bir bağlantı gözünüze çarpabilir. Gezegenimizin mutlu insanlarını Clojure diliyle ilgili bir video serisine götüren bu bağlantı, Türkiye'de yaşayanlar için—henüz farkına varılmayan üniversite ve benzeri ortamlardaki mutlu azınlık dışında—alıştık İnternet sansürlerinden birini simgeliyor. [Son kontrol tarihi: 29-Aralık-2011] İşin hazin tarafı, bu durum Wikipedia'nın blip.tv sayfasında, ülkemizin Çin'le birlikte—listede üçüncü bir ülke yok!—anılması yoluyla reklam ediliyor. ↑
İllaki bol pencereli bir geliştirme ortamı istiyorsanız, size bu sayfaya bakmanızı öneririm. Ayrıca, çalışma ortamınızın özelliklerine bağlı olarak, örneklerdeki Türkçe'ye özel harflerde sıkıntı yaşayabilirsiniz. Bunun olası nedeni, kullanmakta olduğunuz Java arşivinin Türkçe'deki bu karakterleri dışlayacak bir kodlama ile derlenip oluşturulmasıdır. Tavsiyem, clojure komutuna öncelik vermeniz; bu da çözüm sağlamıyorsa, Clojure ortamını UTF-8 kodlaması ile derlemeniz. ↑
Aslına bakılırsa, Clojure tanımlayıcılar hakkında tür bilgilerinin sağlanması için isteğe bağlı olarak kullanılabilecek bir düzenek sağlıyor. Ancak, yazımızda bu olanağa değinmeyeceğiz. ↑
Clojure 1.3 öncesinde durum farklıydı. Öncelikle, nitelenmemiş bir sabitin türü Long değil, Integer idi. Ayrıca, taşma ayrıksı duruma sebep olmaktansa söz konusu değeri Integer ise Long'a, Long ise java.math.BigInteger—Clojure 1.3'te olduğu gibi clojure.lang.BigInt değil!—türüne terfi ettirerek sessizce geçiştiriliyordu. ↑

Hızlı Arama Zamanlı Kaplar-2

2011-12-02T10:45:00.001+02:00

Kaldığımız yerden devam ediyoruz. Dizimizin ikinci ve son yazısında, ilk yazıyı okuyanlara tanıdık gelecek aşağıdaki kısmi sıradüzenin eşlemler için dengeli ağaç temelli gerçekleştirim sağlayan kısmına değineceğiz. Buraya ilk yazıyı okumadan yolunuz düşüp de kavramsal olarak kendinizi hazır hissetmiyorsanız, size tavsiyem ilk yazıya bir göz atıp daha sonra buraya dönmeniz.🔎

İlk yazı🔎
TreeMap sınıfı
SortedMap arayüzü
NavigableMap arayüzü
Uzmanlaşmış eşlemler

`TreeMap` Sınıfı

Eşlem yapısı, altyapıda anahtar bilgisine göre oluşturulan bir dengeli ağaç kullanılarak da gerçekleştirilebilir. Bu yol izlenecek olursa çözüm, eşleme gönderilen iletilerin dengeli ağaca yönlendirilmesiyle sağlanır. Bu tür ağaçların ekleme, silme ve sorgulama işlemlerini O(lgn) zamanda yapması nedeniyle, anılan işlemlerin eşlemde de O(lgn) performanslı gerçekleştirilmesi mümkün olacaktır. Bu noktadan hareketle, standart Java kitaplığındaki TreeMap sınıfı eşlem yapısını kırmızı-siyah ağaçlardan yararlanarak gerçekleştirmiştir.¹

Altyapıda dengeli ağaç kullanılıyor olması, TreeMap sınıfının pek çok ekstra iletiyi düşük maliyetli bir gerçekleştirimle desteklemesini olanaklı kılar. Bunun başlıca nedeni, kök-ortada (İng., inorder) dolaşmanın ağaç içindeki bilgileri anahtara göre sıralı vermesidir. Bu sayede eşlem içeriği anahtara göre sıralı bir şekilde oluşturulabilir; ayrıca sıralama aşamasına gerek yoktur. Bunun doğal bir sonucu olarak, TreeMap sınıfı SortedMap ve NavigableMap arayüzlerinde listelenen eşlem içeriğinin uç değerleri ve dilimlerine dair iletileri de destekler. Ayrıca, Map🔎 arayüzünde tanımlanmış olan entrySet, keySet ve values iletilerinin gerçekleştirimleri de sonuçlarını anahtara göre sıralı değerlerden oluşan birer kap içinde döndürürler.

Kök-ortada dolaşmanın düğümleri anahtara göre sıralı üretebilmesi, anahtar-tutanak çiftlerinin altyapıdaki dengeli ağacın anahtar değerine göre belirlenen uygun düğümlerine eklenmeleri ile mümkün olur. Bu ise, eklenmekte olan anahtar değerinin eşlemde var olanların bir kısmı ile karşılaştırılmasıyla olanaklıdır. Benzer şekilde, silme ve sorgulama işlemlerinde de söz konusu anahtara karşılık gelen düğümün karşılaştırma işlemleri yardımıyla saptanıp işlemin tamamlanması mümkün olacaktır. Bütün bunlar, anahtar türünün karşılaştırılabilir olması zorunluluğunu beraberinde getirir. Yani, anahtar türü ya Comparable kategorisinde olmalıdır ya da java.util.Comparator arayüzünü gerçekleştirilen bir sınıf anahtar türüne ait nesneleri karşılaştırma desteğini sağlamalıdır. Gelin bu konuyu TreeMap sınıfının yapıcılarına açıklık getirerek anlamaya çalışalım.

...
import java.util.TreeMap;

public class Eşlemler {
  public static void main(String[] ksa) {
    ...
    Map<String, String> sözlük3 = new TreeMap<>();
    sözlüğüDoldur(sözlük3);
    System.out.println("Sözlük içeriği: " + sözlük3);
    ...
  } // void main(String[]) sonu
  ...
} // Eşlemler sınıfının sonu

Yukarıdaki kod parçasının işaretli satırındaki yapıcı çağrısı sonucunda yaratılan eşlem, karşılaştırma amacıyla, herhangi bir bilgi verilmediği için, anahtar bilgilerinin üyesi olduğu String sınıfınca gerçekleştirilen Comparable arayüzündeki compareTo iletisini kullanacaktır. Bunun sonucunda, sözlük3 adlı eşlemi standart çıktıya basan komut, sözcükleri büyük harfler önce olmak üzere alfabetik sıraya göre dizecektir. Ayrıca, bu iş yapılırken Türkçe'ye özel harfler beklediğimiz sıranın aksine sona doğru yer alacaktır. Bu sorunun çözümü, Türkçe'ye özel bir sözcük karşılaştırma sınıfı gerçekleştirmektir.

...
import java.text.Collator;
import java.util.Comparator;
import java.util.Locale;

public class Eşlemler {
  public static void main(String[] ksa) {
    ...
    Map<String, String> trSözlük =
      new TreeMap<>(new TürkçeSözcükKarşılaştırıcı());
    sözlüğüDoldur(trSözlük);
    System.out.println("Sözlük içeriği: " + trSözlük);
    ...
  } // void main(String[]) sonu
  ...
} // Eşlemler sınıfının sonu

class TürkçeSözcükKarşılaştırıcı implements Comparator<String> {
  private final static Collator trKarşılaştırıcısı =
    Collator.getInstance(new Locale("tr"));

  public int compare(String s1, String s2) {
    return trKarşılaştırıcısı.compare(s1.toLowerCase(), s2.toLowerCase());
  }
} // TürkçeSözcükKarşılaştırıcı sınıfının sonu

Yukarıdaki kod parçasının işaretli satırları, dengeli ağaç altyapılı boş bir eşlem yaratırken ağacın, ve dolayısıyla eşlemin, oluşturulması amacıyla kullanılacak karşılaştırma ölçütünün argümanda geçirilen nesne tarafından belirlendiğini söylemektedir. Bu nesnenin sınıfına bakacak olursak, sözcüklerin büyük-küçük ayrımı yapılmaksızın Türkçe alfabeye göre karşılaştırılacağını ve sıranın Türkçe'den alıştığımız şekilde oluşacağını görürüz.

TreeMap sınıfının diğer yapıcıları kopyalayan yapıcı olarak çalışır. Bunlardan yegâne argümanında SortedMap arayüzünü gerçekleştiren bir eşlem alanı, yaratılmakta olan eşlemi argümanda geçirilenin içeriği ile dolduracaktır. Birbirinden bağımsız iki eşlem oluşmasına yol açan bu işlemin sonrasında yeni eşleme uygulanacak işlemler argümandaki eşlemin kullandığı karşılaştırma ölçütü ile aynı olacaktır. Sonuncu yapıcı da buna benzer bir mantıkla çalışır. Bu sefer, kopyalamanın kaynağı olan eşlem Map arayüzünü gerçekleştiren herhangi bir eşlem olabilir. Yani, argüman olarak TreeMap nesnesi geçirilebileceği gibi, diğer altbölümlerde göreceğimiz sınıfların nesneleri de geçirilebilir ki, bu yaratılmakta olan eşlemin taklit edeceği bir karşılaştırma ölçütünün olmayabileceği anlamına gelir. Dolayısıyla, bu yapıcı çağrısının kullanımı sonrasında yeni yaratılan eşlemin içeriğinin düzenlenmesinde ölçüt olarak anahtar sınıfının compareTo iletisi kullanılacaktır.

Yaratılan eşlemin içeriğini var olan bir eşlemden alırken farklı bir ölçüt kullanmak olanaklı değil mi, diye sorabilirsiniz. Hemen sorunuzun yanıtının olumlu olduğunu söyleyelim. Bunun için yapmanız gereken, eşlemi uygun bir karşılaştırma ölçütü ile boş yaratıp putAll iletisi ile doldurmaktan ibarettir.

...
public class Eşlemler {
  public static void main(String[] ksa) {
    ...
    Map<String, String> sözlük4 =
      new TreeMap<>(new TürkçeSözcükKarşılaştırıcı());
    sözlük4.putAll(sözlük3);
    System.out.println("Sözlük içeriği: " + sözlük4);
    ...
  } // void main(String[]) sonu
  ...
} // Eşlemler sınıfının sonu

`SortedMap` Arayüzü

Gelelim, SortedMap arayüzünde olup TreeMap sınıfınca gerçekleştirilen iletilere. Bunlardan comparator, hedef eşlemin hangi ölçüte göre düzenlendiğini döndürür. Ancak, aklınızda olsun: bu iletinin null döndürmesi herhangi bir ölçüt kullanılmadığı anlamına gelmez; sadece, Comparable arayüzünü destekleyen anahtar sınıfının compareTo gerçekleştiriminin kullanıldığı anlamına gelir.

SortedMap arayüzünde listelenen diğer iletiler uç değer ve eşlem dilimi döndürmek suretiyle görüntü sağlayanlar olmak üzere iki grupta toplanabilir. TreeMap türlü eşlemlerin dengeli ağaçlarla temsil edilmesi sayesinde ucuz maliyetlerle gerçekleştirilebilen bu iletilerden firstKey ve lastKey, sırasıyla, hedef eşlemin ilk ve son anahtar bilgisini döndürür. İkinci gruptaki iletiler, argüman veya argümanlarında belirtilen anahtar bilgileri ile belirlenen anahtar-tutanak çiftlerinden oluşan ve SortedMap tutacağı ile gösterilen eşlem görüntüleri döndürür. Bunlardan subMap, ilk argümanı ile başlayıp ikinci argümanının hemen öncesinde biten eşlem dilimini döndürürken, headMap başlangıçtan argümandaki anahtarın öncesine kadar olan dilimi, tailMap ise argümanındaki anahtar ile başlayıp eşlemin sonuna kadar giden dilimi döndürür.

SortedMap<String, String> adanbye = trSözlük.subMap("a", "b"); // "b" hariç!
SortedMap<String, String> jyeKadar = trSözlük.headMap("j");
SortedMap<String, String> jdenSonra = trSözlük.tailMap("j");

Her üç iletinin de, görüntüleme grubundaki diğer iletiler gibi, yeni bir eşlem yaratmaktansa ileti alıcının gösterdiği eşlemi paylaştırdığı unutulmamalıdır. Bundan dolayı, yukarıdaki kodun işlenmesi sonrasında trSözlük dört farklı tutacak yoluyla değiştirilebilecektir. Mesela, adanbye tutacağı ile gösterilen dilimin herhangi bir eşlemesinin değiştirilmesi trSözlük yoluyla gösterilen eşlemi de etkileyecektir. Ancak; trSözlük yoluyla sözlüğe "eşlem" anahtarı ve anlamının girilmesi sadece jyeKadar ile temsil edilen dilimi etkileyecektir, diğerlerini değil. Ayrıca, hiçbir eşlemin geçerli olduğu dilimin dışındaki herhangi bir anahtara dair bilgiyi eklemekte kullanılamayacağı da bilinmelidir. Örneğin, jdenSonra aracılığıyla "eşlem" anahtarı ve ilişkin anlamın girilmeye çalışılması IllegalArgumentException ayrıksı durumuna neden olacaktır.

`NavigableMap` Arayüzü

Java SE6 ile birlikte eklenen NavigableMap arayüzü, SortedMap'tekilere benzer iletiler sunar; tanımlanan işlevsellik uç değer işleme ve görüntüleme iletilerinden oluşur. Örneğin, SortedMap'ten kalıtlanan firstKey ve lastKey iletilerine ceilingKey, floorKey, higherKey ve lowerKey iletileri eklenmiştir. ceilingKey argümanındaki anahtara eşit veya ondan büyük ilk anahtar değerini döndürürken, floorKey argümanındaki anahtara eşit veya ondan küçük son anahtar değerini döndürür; higherKey ve lowerKey iletileri ise eşitlik denetimi yapmayan, sırasıyla, ceilingKey ve floorKey gibi çalışır.

String cVeyaSonrasındakiİlkSözcük = trSözlük.ceilingKey("c");
String cSonrasındakiİlkSözcük = trSözlük.higherKey("c");
String cVeyaÖncesindekiSonSözcük = trSözlük.floorKey("c");
String cÖncesindekiSonSözcük = trSözlük.lowerKey("c");

Bir diğer ileti grubu, yukarıda adını andığımız iletilerle aynı şekilde çalışmakla birlikte anahtarı döndürmektense Map.Entry türlü bir tutacak aracılığıyla gösterilen eşlemeyi sarmalayan nesneyi döndürür. Bu iletilerin adları, ilişkin iletinin adındaki Key kısmı yerine Entry koymakla elde edilebilir. İstenecek olursa, bu noktadan sonra sarmalanan nesne Map.Entry arayüzündeki iletilerle sorgulanabilir.

NavigableMap arayüzünce eklenen görüntüleme iletilerinden olan descendingKeySet, adının da haykırdığı gibi hedef eşlemdeki anahtarları bir küme içinde döndürür. Ancak, döndürülen kümenin dolaşılması anahtarları keySet'in döndürdüğünün tersi sırada verecektir. Anahtarlara dair görüntüyü döndüren bir diğer ileti olan navigableKeySet, keySet'e daha da çok benzer; iki iletinin döndürdükleri kümenin içeriği ve sırası tümüyle aynıdır. Ne var ki, keySet Set dönüş türüne sahipken, navigableKeySet NavigableSet döndürür.

Tanıdık gelecek bir diğer ileti grubu dilim döndüren görüntüleme iletileridir. NavigableMap arayüzü, SortedMap'ten kalıtladıklarına ek olarak, uç değerlerin dahil edilip edilmeyeceğini belirleyen ekstra parametrelere sahip headMap, subMap ve tailMap adlı üç ileti destekler. Söz konusu iletiler, her bir uç değeri takiben geçirilen boolean değerlerle döndürülecek dilimin uç noktalarının nasıl ele alınacağını belirler; true geçirilmesi uç noktayı sonuca katarken, false geçirilmesi dışlar. Bu iletilerin bir diğer farkı, SortedMap'ten kalıtlanan aynı adlı iletilerin SortedMap döndürmesine karşılık, NavigableMap döndürmeleridir.

Bir önceki paragrafta anılanlarla ele alınabilecek bir ileti de, hedef eşlemi döndürülen NavigableMap tutacağı vasıtasıyla ters sırada görüntülemeye yarayan descendingMap'tir. Yani, sözlüğümüzü ters sırada işlemek isteyecek olursak, yapmamız gereken aşağıdaki tanımlamadan ibarettir.

NavigableMap<String, String> trSözlük2 = trSözlük.descendingMap();

Değineceğimiz son iletiler, uç değerleri denetleyerek [var olmaları halinde] silen pollFirstEntry ve pollLastEntry iletileridir. pollFirstEntry, hedef eşlemde ilk sırada bulunan eşlemeyi yoklayıp silerken, pollLastEntry son eşlemeyi siler. Her iki ileti de sildikleri eşlemeye dair bilgiyi Map.Entry tutacağı ile döndürürken, eşlemin boş olması halinde null döndürülür.

Uzmanlaşmış Eşlemler

Veri Kapları Çerçevesi, yukarıda anlatılanlara ek olarak içerebileceği anahtarların niteliklerinden dolayı özel bir şekilde gerçekleştirilmek suretiyle daha yüksek performanslı kullanılabilecek iki eşlem sınıfı daha sunar: EnumMap ve WeakHashMap.

Anahtar türünün bir sabit listesi (İng,. enum) olması durumunda, eşlemdeki anahtar sayısı ilişkin sabit listesindeki simgesel sabitlerin sayısı ile sınırlanacaktır. Bu gibi bir durumda, anlattığımız eşlem sınıflarından birini kullanmaktansa, anahtarlarının sabit listesi değerleri olduğunu varsayarak eniyileme yapan EnumMap sınıfının kullanılması daha doğru olacaktır.

WeakHashMap sınıfı da, tıpkı HashMap gibi, kıyım tablosu temelli bir gerçekleştirim sağlar. Ancak; WeakHashMap içine konulabilecek anahtar değerleri WeakReference türünden olmak zorundadır.² Bu ise tutanakların, eşlem kullanıcısının göndereceği remove iletilerinin yanısıra, çöp toplayıcısının vereceği bir karar sonrasında [kullanıcı kontrolunun dışında] usulca silinebileceği anlamına gelir. Henüz silinmesi istenmeyen bir tutanağın bu sondan korunması kuvvetli bir tutacak ile gösterilmesi sayesinde sağlanabilir.

İlk Yazı
Doğrusal Veri Kapları
Değişken Uzunluklu Diziler: Vector

Kırmızı-siyah ağaçlar, B-tree ailesindeki dengeli ağaçlardan [azami] dört düğümlü olanların, ki bu ağaçlara tepeden aşağıya 2-3-4'lü ağaçlar da denir, ikili ağaç şeklinde gerçekleştirilmiş biçimleridir.↑
java.lang.ref paketinin Reference köklü sıradüzenindeki sınıfların tutacakları, bir nesne göstermektense bir başka nesnenin tutacağını sarmalayarak onu nesneye çevirir. JSM tarafından özel muameleye tabii tutulan bu nesnelerin kullanım amacı, çöp toplayıcı ile etkileşerek kaynak yönetim sürecine uygulama gereksinimlerine göre müdahele edilmesini olanaklı kılmaktır.↑

Hızlı Arama Zamanlı Kaplar-1

2011-12-02T10:44:00.001+02:00

Dizi🔎, Vector🔎 veya liste yapısını gerçekleştiren ArrayList🔎 ve LinkedList🔎 gibi sınıfların bir zaafı, doğrusal bir yapıya sahip olmaları nedeniyle ortalama eleman arama zamanlarının yavaş olmasıdır. Örnek olarak, sırasız bir listede gözlerinizi baştan sona doğru gezdirerek adınızı aradığınızı düşünün. Yapmanız gereken, listenin başından adınızın bulunduğu yere kadar her sıradaki ad ile kendi adınızın eşitlik denetimini yapmaktır. Şanslıysanız, adınız başlardadır ve kısa zamanda kendinize dair bilgileri bulabilirsiniz; ancak, şansınızın yardım etmediği bir gün adınız listenin sonunda da olabilir ve aradığınız bilgiyi çok daha uzun bir zamanda elde edersiniz. Aynı listede adını arayanların harcadığı ortalama zaman ise—n kişi için toplam 1 + 2 + ... + n eşitlik denetimi olduğuna göre—n(n+1)/2n, yani (n+1)/2, eşitlik denetimi zamanı olacaktır.

Her eşitlik denetimi sonrasında arama uzayını sadece bir küçülten bu yöntem işi görür fakat büyük listelerde işkence halini alan bir performansa sahiptir. Biraz düzenli bir yapıya sahip olanlarınız, performans çözümlemede O(n) şeklinde ifade edilen bu sonucun aşağılara çekilmesinin olanaklı olduğunu bilirler. Mesela, bir kütüphaneye yolu düşüp de kitap arayanlarınız—iyi örnek olmadı galiba... müzik dükkânından albüm alanlarınız diyelim—hemen konuya [ya da tarza] göre indeksleme ve aynı konu içinde alfabetik sıraya dizmeyi önereceklerdir. Java standart kitaplığında doğrudan karşılığı olmadığı için, indekslemeyi köşeye koyup sıralamanın bize ne kazandırabileceğini görelim; bunu yaparken de—unutmayın, asıl konumuz işi bilgisayarlara yaptırmak—adımızın özelliklerine dayalı eniyilemelerin yapılamadığını varsayalım. İyi bir arama zamanını garanti etmek için izlenmesi gereken strateji, her eşitlik denetimi sonrasında arama uzayını olabildiğince yüksek oranda küçültmelidir. Konulan bu hedefe, "İlk elemanın ad bilgisi adıma eşit mi?" şeklinde sorulan sorunun "Ortadaki elemanın ad bilgisi adıma eşit mi, eşit değilse adımdan önce mi geliyor, sonra mı?" şeklinde değiştirilmesiyle erişilebilir. Böylesine bir değişiklik arama uzayımızı bir azaltmak yerine ikiye bölerek küçültecektir. Çünkü, sıralı olduğu bilinen listemizin orta elemanının aradığımız değere eşit olmaması durumunda, adımız ya ilk yarıdadır ya da ikinci yarıda; böylece, adımız hangi yarıda olursa olsun, arama uzayımız yarı yarıya küçülecektir. Bu ise, sorgumuzun olumlu veya olumsuz sonucunun O(n) yerine O(lgn) performansla verileceği anlamını taşır. İkili arama adı verilen ve java.util paketindeki Arrays🔎 ve Collections sınıflarının binarySearch metotlarında gerçekleştirilen bu algoritmanın ifade edilen performansı verebilmesi için veri kümesinin sıralı ve altyapıda kullanılan veri yapısının doğrudan erişimli dizi, Vector veya ArrayList gibi bir yapı olması gerekir. Çok özel durumlar¹ dışında sıralamanın O(nlgn) ve daha fazla bir ek yük getireceği düşünüldüğünde, bu algoritmanın, özellikle de ekleme ve silmelerle veri kümesinin büyüyüp küçüldüğü kullanım desenlerinde, her zaman sözü edilen performansı sağlayamayacağı görülür. Çözüm, ekleme/silme işlemlerinin de hızlı bir şekilde yapıldığı hızlı arama zamanlı kaplar olan ve iki yazılık dizimizin konusunu oluşturan eşlemlerdedir.

Giriş
Map arayüzü ve AbsractMap sınıfı
HashMap ve LinkedHashMap sınıfları
Hashtable sınıfı
İkinci yazı🔎

Giriş

Standart Java kitaplığına bakıldığında eşlemlerin Veri Kapları Çerçevesi'nin bir parçası olarak java.util paketi içinde tanımlanıp gerçekleştirildiği görülür. Temel işlevselliği tanımlayan Map arayüzü ve kimi işlemlerin altyapıda kullanılan veri yapısından bağımsız bir şekilde gerçekleştirildiği AbstractMap sınıfının temelini oluşturduğu eşlemlere dair sıradüzeninin önemli bir bölümü aşağıda verilmiştir. Object, Cloneable ve Serializable dışındakilerin java.util paketinde olduğu türlerden Hashtable, Java'nın ilk uyarlamasından itibaren var olup J2SDK 1.2 ile gelen Veri Kapları Çerçevesi'ne monte edilmiştir. Dolayısıyla, J2SDK 1.2 öncesi yazılmış programları çökertmemek adına Hashtable sınıfı, AbstractMap'ten kalıtlamaktansa, Map arayüzünü doğrudan gerçekleştirmiştir. Kadük olan Dictionary adlı soyut sınıfın kullanımından ise kesinlikle kaçınılmalıdır.

Map arayüzü ile başlamadan önce, nasıl kullanılabileceğini örneklendirerek eşlemlerin biçimsel olmayan tanımını yapalım. Eşlemler, anahtar-tutanak çifti olarak temsil edilen eşlemelerin hızlı bir biçimde işlenmesini sağlayacak şekilde düzenlenerek tutulduğu veri yapılarıdır. Doğal olarak temel işlemler, eşleme bir anahtar-tutanak çiftinin eklenmesi, sağlanan bir anahtara dair tutanak bilgisinin sorgulanması veya eşlemenin silinmesidir. Bu işlemlerin hızlı bir şekilde tamamlanması ise gerçekleştirimci tarafından karşılanacağı varsayılan temel bir beklentidir.

Kimi eşlemelerin eşlemlerin yanısıra diğer veri yapıları ile de temsil edilebileceği bir gerçektir. Örnek olarak, ülkemizdeki plaka kodları ile il adları arasındaki eşlemeleri düşünün. Söz konusu eşlemeler bir eşlemle tutulabileceği gibi, doğrudan erişimi destekleyen bir veri yapısı kullanılarak da tutulabilir. Aslına bakarsanız, veri kümemizin durağan yapısı—her dakika yeni bir il eklenmeyecek—ve plaka kodları ile doğrudan erişimde kullanılan indis arasındaki neredeyse mükemmel uyuşma nedeniyle—0 nolu indis boş bırakılırsa 1-1 bir uyuşmadan söz edebiliriz—dizinin kullanılması çok daha yerinde bir seçim olacaktır. Ancak; eşlemenin ters yönde (İl adı→Plaka kodu) olmasının istenmesi halinde işler değişir: doğrudan erişimden yararlanılabilmesi il adının kıyımdan geçirilerek bir tamsayıya dönüştürülmesi ile olanaklıdır. Bu gibi bir durumda, fazladan kıyım fonksiyonu yazıp belki de düşük verimli bir çözüm üretmektense, eşlem kullanmak daha doğru olacaktır.

Eşlemleri çekici kılan bir diğer kullanım deseni, veri kümesinin anahtar-tutanak eşlemelerinin eklenmesi ve silinmesi ile büyüyüp küçüldüğü problemlerdir. Bu gibi durumlarda, kıyım fonksiyonunun maliyetine ek olarak, altyapıda kullanılan veri yapısının büyümesi veya küçülmesi ve ekleme ile silmelerin kaydırmalar nedeniyle sebep olacağı maliyet, eşlem kullanımını cazip hale getirmektedir.

`Map` Arayüzü ve `AbstractMap` Sınıfı

Gelelim, Map arayüzüne. Anahtar ve tutanak bilgisi türlerinin tür parametresi olarak tanımlandığı bu soysal arayüzdeki isEmpty iletisi, hedef eşlemin boş olup olmadığı sorusuna yanıt verirken, size iletisi hedef eşlemdeki eşleme sayısını döndürür. Bu bağlamda, standart kitaplıkta sağlanan gerçekleştirimlerin aynı anahtara karşılık tek bir tutanak bilgisi tuttuğu hatırlatılmalıdır.²

Eşlemlere ekleme, argüman olarak, sırasıyla, anahtar ve tutacak bilgisini alan put iletisi ile yapılabilir. Anahtar değerinin eşlendiği bir önceki tutanağı döndüren bu işlemin aynı anahtar değeri kullanılarak birden çok kez icra edilmesi durumunda, en son ekleme etkili olacaktır. Birden çok sayıda eşlemenin eklenmesinin istenmesi halinde, arda arda kullanılacak put iletileri yerine eklenecek anahtar-tutanak bilgilerini içeren bir eşlem bekleyen putAll iletisi kullanılabilir.

get iletisi argümanındaki anahtarın hedef eşlemde eşlendiği tutanak bilgisini döndürür. Benzer bir ileti, kendisine geçirilen anahtarın bir tutanak ile eşlenip eşlenmediğini döndüren containsKey yüklemidir. containsValue ise containsKey yükleminin tersi olarak düşünülebilir; bu yüklem, argümanındaki tutanak bilgisinin herhangi bir anahtar ile eşlenip eşlenmediği sorusunu yanıtlar. Bir an için, get iletisinin containsKey iletisini gereksiz kıldığı düşünülebilir. Ne var ki, get iletisinin eşlemde olmayan bir anahtarın sorgulanmasına yanıt olarak null döndürmesi ve kimi eşlem yapısı gerçekleştirimlerinde anahtarların null ile eşlenebilir olması sonucu ortaya çıkan muğlaklık ancak containsKey iletisinin kullanımıyla ortadan kaldırılabilir. containsKey aynı anahtar için true döndürüyorsa anahtar null değerine eşlenmiş demektir, aksi takdirde anahtara dair bir eşleme yoktur.

Hedef eşlemden eleman silmek için iki ileti kullanılabilir. Bunlardan clear, eşlemi hızlı bir biçimde boşaltırken, remove argümanındaki anahtara ilişkin eşlemeyi silmekle yetinir ve sonucu olarak işlem öncesinde anahtarın ilişkilendirildiği tutanak bilgisini döndürür. Geçirilen anahtar değerinin hedef eşlemde bulunmaması halinde ise, remove bu gerçeği kullanıcısına null döndürerek bildirir.

Map arayüzünü gerçekleştiren sınıfların desteklemesi gereken bir diğer ileti grubu, hedef eşlemdeki anahtar-tutanak eşlemelerinin değişik görüntülerini sağlayanlardır. Bu gruptaki iletiler tarafından döndürülen kaplar ile hedef eşlemin belleği paylaştıkları ve dolayısıyla görüntü üzerinden yapılan değişikliklerin eşleme de yansıtılacağı akılda tutulmalıdır. Bunlardan keySet, anahtarları barındıran küme nesnesini gösteren bir java.util.Set tutacağı döndürürken, values iletisi tutanak bilgilerini içeren nesneyi temsil eden bir java.util.Collection tutacağı döndürür. İlk ileti için Set ikinci ileti içinse Collection türlü bir tutacak döndürülmesinin nedeni, eşlemlerin aynı anahtardan en fazla bir tane bulundururken, aynı tutanak bilgisinin birden çok sayıda eşlemede geçmesinin mümkün olmasıdır. Örnek olarak; anahtar türü String, tutanak türü Integer tanımlanmış bir eşleme "İzmir"→35 ve "Karşıyaka"→35 bilgilerinin eklendiğini varsayalım. Bu eşleme gönderilecek values iletisi, Collection tutacağı ile gösterilen iki elemanlı bir kap döndürürecektir: halbuki, dönüş türü olarak Set'in kullanılması her iki değerin de 35 olması nedeniyle tek elemanlı bir küme döndürülmesine neden olacaktı.

values ve keySet iletileri gibi görüntüleme grubuna ait olan entrySet, hedef eşlemdeki anahtar-tutanak çiftlerini bir küme içinde döndürür. Kümelerin tek tür ile parametrize edilebiliyor olmasından ötürü, döndürülen küme anahtar ve tutacak türleri ile parametrize edilen Map.Entry ile gösterilen nesneler içerir. Başka bir deyişle, Map arayüzünün iç arayüzü olan bu tür anahtar ve tutanak bilgilerini sarmalar; anahtar veya tutanak bilgilerine dair bir şeyler yapmak istediğimizde, entrySet iletisinin döndürdüğü kümenin elemanlarına uygun iletileri göndermemiz gerekir. Bu iletiler, anahtarın sorgulanması (getKey) tutanak bilgisinin sorgulanıp değiştirilmesi (getValue ve setValue) ve eşitlik denetimi (equals) ile kıyım fonksiyonundan (hashCode) ibarettir. Döndürülen küme nesnesinin eşlem nesnesi ile aynı altyapıyı kullandığı unutulmamalıdır. Yani, entrySet'in döndürdüğü küme yoluyla güncellenen bilgiler eşleme yansıyacaktır; benzer şekilde, küme tutacağı eşlem tutacağı ile yapılan değişiklikleri görebilecektir.

Son olarak göz atacağımız iletiler, Object sınıfından tanıdık gelecek olan equals ve hashCode. Sırasıyla, eşitlik denetimi ve kıyım fonksiyonuna karşılık gelen bu iletilerin, Map arayüzüne konulmasının nedeni, geliştiricinin yeni bir eşlem sınıfı gerçekleştirimi sunmak istemesi halinde dikkatsizlikle bu iletileri es geçmesinin önüne geçmektir. Diğer veri kapları gibi eşlemlerin de eşitlik denetimlerinin kap içeriği göz önüne alınarak yapılması equals iletisinin gerçekleştirilmesini zorunlu kılmaktadır. Elemanların belki de hepsini dolaşarak tamamlanacak bu pahalı işlemin maliyetinin düşürülmesi içinse kıyım fonksiyonundan yararlanılması olasılığı hashCode iletisinin gerçekleştirilmesini dikte etmektedir; ne de olsa, kıyım değerleri farklı olan iki nesnenin eşit olması olanaklı değildir.🔎

Bu noktada, önceki paragrafta andığımız iletilerin eşlemleri ilgilendirdiği, anahtar ve tutanak türleri için herhangi bir zorunluluk olmadığı vurgulanmalıdır. Ne var ki; eşlem yapısının arayüzünde yer alan iletilerin gerçekleştirimleri, alternatif bir yöntem olmadığı savlanamasa da, yüksek olasılıkla anahtar ve tutacak bilgilerinin eşitlik denetiminden yararlanarak işlerini göreceklerdir. Bir ihtimal eşlem yapısının gerçekleştirimcisi, eşitlik denetimini anahtar/tutacak bilgisinin kıyım fonksiyonundan yararlanarak kısa yoldan bitirmek isteyecektir. Dolayısıyla, eşlem yapısına konulacak nesnelerin sınıflarında equals ve hashCode iletilerinin gerçekleştirilip gerçekleştirilmeyeceği dikkatle düşünülmeli ve karara bağlanmalıdır.

Map arayüzündeki kimi iletiler, altyapıda kullanılan veri yapısından bağımsız bir biçimde gerçekleştirilebilir. Örneğin, get iletisi eşlemdeki entrySet'in döndürdüğü anahtar-tutanak çiftlerinin gezilerek eşitlik denetimi yapılmasıyla gerçekleştirilebilir. Bunun, farklı sınıflarda tekrarlanmaktansa, ortak bir üst sınıfa (AbstractMap) konulması ve eşlem sınıflarının (HahsMap, TreeMap, vd.) bu sınıftan kalıtlayarak gerçekleştirilmesi kodun yeniden kullanımını artıracaktır. Eşlem gerçekleştirimcisinin daha uygun bir çözümü olması durumunda ise, ilişkin metot ezilerek istenen yapılabilir.

`HashMap` ve `LinkedHashMap` Sınıfları

Eşlemlerin bir gerçekleştirim yöntemi, indis ile erişimin yüksek performansından yararlanmak amacıyla altyapıda doğrudan erişimli bir yapı kullanır. Amaç, eşleme gönderilen iletilerin arka plandaki yapı üzerinde uygulanan indis işlemleri haline dönüştürülmesi ve doğrudan erişimin keyfini sürmektir. Ancak, bu söylendiği kadar kolay gerçekleştirilemez; anahtar değerlerinin türü ve alabileceği değerler işi zora sokabilir. Plaka kodu→İl adı örneğimizde işimiz çok basitti ve bundan dolayı dizinin kullanılması düşünülebilir demiştik. Ne var ki, anahtar değerlerinin çok daha geniş ve seyrek bir aralığa dağılması veya tamsayı olmaması söz konusu olabilir. Mesela, farklı yıllarda kaydolmuş öğrencilerin aldığı bir derse dair No→Ad eşlemelerini tutan diziyi düşünün. 8-10 basamaklı bir tamsayı olan öğrenci numarası ve bu numaraların değişik yıllara dağılmış olması, numaradan indise geçişi zorlaştıracaktır. Peki ya, öğrenci numaraları tamsayı olarak değil de String olarak temsil ediliyor olsaydı? Ya da, sözcükler ve anlamları arasındaki eşlemeleri tutmak isteseydik?

Bir önceki paragrafta yöneltilen soruların yanıtı, anahtar değerlerin uygun bir şekilde kıyılıp tamsayıya çevrilmesinden geçer. Yapmamız gereken, önce anahtar değeri hashCode iletisini göndererek kıymak ve elde edilen tamsayıyı arka plandaki doğrudan erişimli yapıya indisli erişimde kullanmaktır. İşin püf noktası olan kıyım fonksiyonunu düzgün gerçekleştirirsek, kullandığımız yöntem neredeyse dizi veya Vector içindeki bir elemana erişim kadar hızlı olacaktır. Kıyım fonksiyonunun kötü olması ise, bir o kadar yavaş bir erişim zamanımız olacağı anlamına gelir. Dolayısıyla, mümkünse, işi bir bilene bırakmakta yarar vardır. Java'da bu yüce makam, HashMap sınıfıdır.

HashMap nesnelerinin performansını etkileyen iki parametre vardır: sığa ve doluluk oranı. Bunlar, sırasıyla, eşlem içeriğinin tutulduğu doğrudan erişimli yapının uzunluğunu ve eşlemdeki anahtar-tutanak çifti sayısının sığaya oranını bildirir. Eşleme eklenmek istenen bir anahtar-tutanak çifti, anahtar değerinin kıyılarak 0 ila sığa-1 arasında bir tamsayıya dönüştürülmesi sonrasında yapının ilişkin konumuna, ki bu konumlara kova denir, eklenecektir. Bu kovanın boş olmaması durumunda ise, anahtar-tutanak çifti daha önceden kovaya konulmuş olan diğer eşlemelerin bulunduğu bir listeye eklenir. Sorgulama ve silme işlemleri de işe anahtar bilgisini kıyarak başlar. Bunun takiben, altyapıdaki doğrudan erişimli yapının ilişkin kovasına bakılır. Söz konusu kova boşsa, her iki işlem de null döndürür. Aksi takdirde, kovada tutulan eşlemelerin bulunduğu listenin aranması sonrasında sonuç döndürülür. Kovanın boş olmaması, eşlemin anahtara dair bilgi içerdiği anlamını taşımaz; kovada yer alan eşlemeler aynı kıyım değerine sahip farklı anahtar değerlerine ilişkin eşlemeler de olabilir.

Zaman içinde ekleme yapıldıkça eşlem dolacak, hem altyapıda kullanılan doğrudan erişimli yapı kalabalıklaşacak hem de kovalar içindeki listeler uzayacaktır. Bu; ekleme, sorgulama ve silme için harcanan zamanların uzayacağı anlamına gelir. Böyle bir durumun oluşmasını engellemek adına HashMap, doluluk oranının belli bir değeri aşması üzerine doğrudan erişimli yapıyı büyütür ve içeriği yeniden düzenler. Oldukça pahalı bir işlem olması nedeniyle, yeniden düzenleme sayısının en aza indirilmesi performans açısından yararlı olacaktır. Bunun için, HashMap nesnesinin yaratılması sırasında sığa ve doluluk oranı parametrelerinin probleme uygun bir biçimde seçilmesi gerekir.

HashMap nesneleri dört yapıcıdan biri kullanılarak yaratılabilir. Bunlardan int ve float argüman alanı, nesneyi istenen ilk sığa ve doluluk oranına sahip olacak şekilde yaratır. Yapıcıya sağlanmayıp işlem sırasında çıkarsanamaması durumunda doluluk oranı 0.75, ilk sığa ise 16 olarak kabul edilir. Dolayısıyla, tek int argüman bekleyen yapıcının kullanılması durumunda, yaratılan eşlem argümanda geçirilen büyüklükte bir ilk sığaya ve 0.75 doluluk oranına sahip olacaktır. Varsayılan yapıcının kullanılması halinde ise, 16 ilk sığalı ve doluluk oranı 0.75 olan bir eşlem yaratılacaktır. Her üç durumda da yaratılan eşlem boş olacaktır. Nesnemizin içeriğe sahip olarak yaratılmasını istiyorsak, yapmamız gereken Map arayüzünü destekleyen bir sınıfın nesnesinin argüman geçirildiği yapıcıyı kullanmaktır. Ancak, şunu unutmayın: argümanındaki eşlem ile aynı sayıda eşlemeye sahip yaratılan yeni nesne doluluk oranını miras almayacak, 0.75 olarak kabul edecektir.

HashMap sınıfının akılda tutulması gereken bir özelliği, eşlem içeriğine dair görüntülerin (entrySet, keySet ve values) anahtar-tutanak çiftlerini herhangi bir sırada vermiyor olmasıdır. Hatta; doluluk oranının aşılması sonrasında yeniden düzenlenen eşlemlerin görüntüleri düzenleme öncesindekiyle alakalı olmayabilir. Bunu, aşağıdaki örneğin işaretli satırındaki örtük toString kullanımından da görebiliriz. Üretilen çıktıda ne ekleme zamanı, ne son erişim zamanı, ne de anahtar bilgileri arasındaki bir sıralama ölçütü dikkate alınmaktadır.

Eşlemler.java

import java.util.HashMap;
import java.util.Map;
import java.util.Scanner;

public class Eşlemler {
  public static void main(String[] ksa) {
    Map<String, String> sözlük = new HashMap<>();
    sözlüğüDoldur(sözlük);
    System.out.println("Sözlük içeriği: " + sözlük);
    ...
  } // void main(String[]) sonu

  private static void sözlüğüDoldur(Map<String, String> sözlük) {
    Scanner grdKnlı = new Scanner(System.in);
    for (;;) {
      System.out.print("Yeni bir sözcük giriniz: ");
      String sözcük = grdKnlı.nextLine();
      if (sözcük.toLowerCase().equals("bitti")) break;
      System.out.print("Anlam: ");
      String anlam = grdKnlı.nextLine();
      sözlük.put(sözcük, anlam);
    } 
  } // void sözlüğüDoldur(Map<String, String>) sonu 
  ...
} // Eşlemler sınıfının sonu

Derdimizin çaresi, sergilenen bu kaotik davranışı değiştiren LinkedHashMap sınıfındadır. HashMap'ten kalıtlayan bu sınıf, doğrudan erişimli yapıya ek olarak, altyapıda tuttuğu çift bağlaçlı bir liste ile eşlem içeriğini yapıcı çağrısı sırasında belirlenen iki ölçütten birine göre sıralı tutarak üretilen çıktıyı beklentinize göre oluşturacaktır. Aksi söylenmediği takdirde ekleme sırasında üretilecek olan çıktı, ilk sığa ve doluluk oranına ek olarak sağlanacak üçüncü bir argümanla en son erişim sırasına göre de oluşturulabilir. Örneğin, aşağıdaki kod parçasının işaretli satırındaki yapıcı çağrısı, sözlük2 tarafından temsil edilen eşlemin en son erişilen anahtar-tutanak çiftleri başta gelecek şekilde görüntülenmesini sağlar.

...
import java.util.LinkedHashMap;

public class Eşlemler {
  public static void main(String[] ksa) {
    Map<String, String> sözlük2 = new LinkedHashMap<>(100, 0.80, true);
    sözlüğüDoldur(sözlük2);
    // sözlük2'yi kullan...
    System.out.println("Sözlük içeriği: " + sözlük2);
    ...
  } // void main(String[]) sonu
  ...
} // Eşlemler sınıfının sonu

Diğer yapıcıları HashMap'tekilerle aynı şekilde çalışan LinkedHashMap sınıfı, HashMap'te olduğu gibi Map arayüzündekinden başka bir işlevsellik sunmaz.

`Hashtable` Sınıfı

Buraya kadar gelip de pes etmeyenlere müjde, Hashtable sınıfı HashMap ile neredeyse tamamıyla aynıdır. J2SDK 1.2 öncesinde tanımlanmış olan bu sınıfın HashMap'ten farklı olarak desteklediği kimi iletiler herhangi bir ekstra işlevsellik katmaz. Ancak, sakın ola ki, bu iki sınıfın her zaman birbirlerinin yerine kullanılabileceğini sanmayın. Bunun başlıca üç sebebi vardır:

Fazladan bir işlev katmamakla beraber Hashtable tarafından sağlanan J2SDK 1.2 öncesinden kalma contains, elements ve keys iletileri HashMap nesnelerine gönderilemez. [Eski kodlarınızı elden geçirirken bu iletileri, sırasıyla, containsValue, values ve keySet iletileri ile değiştirmenizi tavsiye ederim.]
Diğer eşlem sınıflarının aksine, Hashtable anahtar değeri olarak null değerinin kullanılmasına izin vermez.
Diğer eşlem sınıflarının aksine, Hashtable çok izlekli kullanım düşünülerek yazılmıştır. Yani, HashMap [ve TreeMap] nesnelerinin farklı izleklerden aynı anda kullanılmak istenmeleri durumunda programcının yapının tutarlılığını korumak adına eşgüdüm kodu yazması gerekirken, Hashtable için böyle bir şey söz konusu değildir.

İkinci Yazı
Doğrusal Veri Kapları
Değişken Uzunluklu Diziler: Vector

Çok özel eleman türü ve dağılımı istemeleri nedeniyle O(n) performans sergileseler de kimi algoritmaların bu gibi genel kullanımlarda zikredilmeleri mantıklı değildir.↑
Bu aslında o kadar da kısıtlayıcı bir şey değil. Anahtarın birden çok değer ile ilişkilendirilmesini istiyorsanız, tutanak türü kısmında List veya Set gibi bir kap türünün belirtilmesi yeterli olacaktır.↑

Düzenli Deyimler

2011-11-23T19:02:00.001+02:00

Bir hesaplama sürecine girdi sağlarken, kimi zaman farklı girdilerin aynı anlama geldiğini veya farklı da olsalar benzer anlamlar taşıdığını söylemek isteriz. Örneğin, bir işleme devam etmek isteyip istemediğimizin sorulması durumunda, "Hayır" yerine "H" veya "h"nin de işi görmesi bize zamandan kazandıracak ve—"hayır" yerine "hıyar" yazdığınızı düşünün—hata oranını azaltacaktır. İşte tam bu noktada, bir grup karakter katarını sahip oldukları içeriğin ortak özelliklerini temel alarak betimleyen özel bir çeşit karakter katarı şeklinde tanımlayabileceğimiz düzenli deyimler işin içine girer. Bu yazımızda da yapacağımız, Java'da düzenli deyimler için sağlanan desteğe bakmak olacak.

Temel Kullanım

Java'da düzenli deyim desteği java.util.regex paketindeki türler vasıtasıyla sağlanır. Bu türlerin sunduğu işlevsellikten yararlanarak, olası girdileri betimleyen düzenli deyimin, programın çalıştırılması sırasında sağlanan asıl girdi ile eşleşip eşleşmediği kontrol edilir. Bunun için yapılması gereken, düzenli deyim ile girdinin argüman olarak geçirildiği Pattern.matches metodunun çağrılmasıdır. Aşağıdaki kod parçasından da görülebileceği gibi, düzenli deyimin String olması beklenirken, girdinin CharSequence arayüzünü destekleyen herhangi bir sınıftan olması mümkündür.

import java.util.regex.Pattern;
...
String düzenliDeyim = ...;
String girdi1 = ...;
boolean tanındıMı = Pattern.matches(düzenliDeyim, girdi1);
...
StringBuilder girdi2 = new StringBuilder("...");
tanındıMı = Pattern.matches(düzenliDeyim, girdi2);

matches metodunun iki özelliği bizi ikinci bir yol aramaya sevkedecektir. Öncelikle, döndürülen boolean değer, kullanıcının sağladığı girdinin düzenli deyimle uyumlu olup olmadığı konusunda fikir verir; girdinin yapısı hakkında herhangi bir bilgi edinmek olanaksızdır. Ayrıca, matches metodu, kendisine geçirilen düzenli deyimi içsel bir gösterime çevirdikten sonra girdinin uyumunu denetler. Bu ise, aynı düzenli deyimin birden çok kez kullanılması durumunda, içsel gösterime dönüşümün tekrar tekrar yapılmasıyla zaman kaybetmek anlamına gelir ki, çözüm Pattern.compile metodunun kullanımından geçer. Bu metot, kendisine geçirilen düzenli deyimi dönüştürür ve dönüşümün sonucunu tutan desen nesnesinin tutacağını döndürür.¹ İstenecek olursa, bu tutacak aracılığıyla gönderilecek iletiler, girdinin düzenli deyimle uyuşması sonrasında girdinin bileşenlerine ilişkin sorgularımızı yanıtlayabilir.

import java.util.regex.*;
...
String düzenliDeyim = ...;
Pattern desen = Pattern.compile(düzenliDeyim);
String girdi1 = ...;
Matcher eşleştirci = desen.matcher(girdi1);
boolean tanındıMı = eşleştirici.matches();
if (tanındıMı) ... // girdi1'in bileşenlerini keşfet
...
StringBuilder girdi2 = new StringBuilder(...);
eşleştirici = desen.matcher(girdi1);
tanındıMı = eşleştirici.matches();
if (tanındıMı) ... // girdi2'nin bileşenlerini keşfet

Düzenli Deyim İçeriği

Düzenli deyim tanımında, betimlenmekte olan girdinin karakterleri ile birlikte bazı özel işleçler kullanılabilir. İstenecek olursa, düzenli deyim ile girdi arasındaki eşlemenin nasıl yapıldığını görebilmek adına düzenli deyim öbek adı verilen parçalara ayrılabilir. Ayrıca, eşleştirme sürecinin büyük/küçük harf ayrımı ve dönüşümü, satır ayırma gibi konularda nasıl davranacağını belirleyen bayraklardan da yararlanılabilir.

Düzenli deyim içeriğini oluşturan karakterlerin bazıları, tıpkı karakter sabitlerinde olduğu gibi, özel bir biçimde yorumlanır. Örneğin, '(' yeni bir öbek başlatırken ')' en son başlatılan öbeği kapatır. Dolayısıyla, bu karakterleri [ve diğerlerini] özel görevleri dışında sade bir karakter olarak görmek istediğimizde niyetimizi söz konusu karakterin önüne '\' koyarak belirtmemiz gerekir. Buna ek olarak, bazı sıradan karakterler, önlerine '\' konulmak suretiyle, tıpkı 'n' karakterinin '\n' haline getirilmesinde olduğu gibi, özel bir anlam kazanır. Mesela, 'd' alfabedeki bir harfe karşılık gelen karakteri temsil ederken, '\d' ondalık sayıları yazmakta kullanılan herhangi bir rakamı temsil eden karakter grubuna karşılık gelir. Dolayısıyla, "\\{\\d\\}" yegâne elemanı tek basamaklı bir ondalık sayı olan kümeleri betimler.

System.out.print(Pattern.matches("\\{\\d\\}", "{3}")); // ⇒ true

'\' karakterlerinin çokluğu başınızı döndürdü değil mi? Bunun nedeni, karakter katarımızın bir kez String sabiti, bir kez de düzenli deyim olarak yorumlanmasıdır. Yani, yukarıdaki komutun ilk argümanı önce String sabiti gibi yorumlanacak ve "\{\d\}" haline dönüştürüldükten sonra düzenli deyim olarak ele alınacaktır. Bu sıkıcı durum, alıntılama düzeneği ile biraz olsun düzeltilebilir. Düzenli deyimin içinde geçen \Q (İng., quote), \E (İng., end quote) görülene kadar hiçbir şeyin yorumlanmayacağını bildirir.² İstenecek olursa, kendisine geçirilen String nesneyi \Q ve \E ile çevreleyen Pattern.quote metodu da aynı amaçla kullanılabilir.

Tek bir karmaşık sayı içeren kümeyi betimleyen düzenli deyim aşağıda verilmiştir. Dikkat ederseniz, düzenli deyimin baş ve son tarafındaki yorumlanmayan parçaların sınırlarını belirleyen \Q ve \E yorumlanmakta olup, sırasıyla, \\Q ve \\E şeklinde yazılmak zorundadır.

import static java.lang.System.out;
import static java.util.regex.Pattern.*;
...
String desen ="\\d\\s*(\\+|-)\\s*\\d";
out.print(
  matches("\\Q{(\\E" + desen + "\\Q)}\\E", "{(3 -5i)}")); // ⇒ true
out.print(
  matches(quote("{(") + desen + quote(")}"), "{(3+4i)}")); // ⇒ true

Karakter Sınıfları

Düzenli deyim oluştururken, karakterlerin yanısıra ortak özellikleri bulunan karakterleri gruplayan karakter sınıflarını da kullanabiliriz. Örneğin, Java'da kullanılabilecek tanımlayıcı adlarını betimlemek istediğimizde, _ ve tüm alfabetik karakterlerin ilk karakter olarak geçebileceğini söyleyerek bu karakterleri aynı sınıfa koymuş oluyoruz. Bu noktada, karakter sınıflarının bir katarı değil tek bir karakteri tanımladığı unutulmamalıdır. Dolayısıyla, tek rakamları betimleyen bir karakter sınıfının düzenli deyim tanımında kullanılması tek rakamlardan oluşan çok basamaklı bir sayının değil, {1', '3', '5', '7', '9'} kümesinin bir tek elemanının kullanılabileceği anlamını taşır.

Köşeli ayraç çifti ile sınırlanan karakterler ve diğer karakter sınıflarından oluşan karakter sınıfları, içerilen karakterlerin yanyana yazılmasının yanısıra, tümleyen sınıfın dışlanması ile de tanımlanabilir. Örneğin, "[13579]" '1', '3', '5', '7' ve '9' karakterlerinden oluşan bir karakter sınıfını tanımlarken, "[^02468]" '0', '2', '4', '6' ve '8' karakterleri dışındaki tüm karakterleri kapsar. Bu noktada, ikinci örneğimizin sadece tek rakamları kapsamadığını, listelenenler dışındaki herhangi bir karakteri kapsadığının altını çizelim. Buna karşılık, rakamların ve çift sayı olmayan karakterlerin kesişimini alan "[0-9&&[^02468]]" deyimi, tümleme işleci (^) ve kesişim işlecinden (&&) yararlanarak ilk örneğimizle eşdeğer bir sonuç verir.

Betimlenen karakter sınıfındaki karakterlerin ardışık olması halinde, tüm karakterleri teker teker yazmaktansa aralık işlecini (-) kullanabiliriz. Buna göre, "[abcçde12345]" yerine "[a-eç1-5]" yazmak yeterli olacaktır. [Dikkat ederseniz, aralık tanımının ASCII temelli olması nedeniyle Türkçe'ye özel 'ç' ayrıca eklenmek zorunda.] Bunun bir sonucu olarak—karakterler arasında kullanıldığında aralık işleci görevini gördüğü için—'-' sınıf içinde ancak ve ancak birinci sırada geçebilir. Dolayısıyla, temel aritmetik işleçlerin tanımı "[-+*/]", bu sınıfın tümleyeni "[^-/*+]" şeklinde yapılmalıdır.

Sıklıkla kullanılan bazı karakter sınıfları önceden tanımlanmışlardır. Söz konusu karakter sınıflarının yeniden tanımlanması hem zamandan kayıp hem de hataya açık bir çabadır. Ancak, bu karakter sınıflarından bazılarının ASCII temelli tanımlandığı ve özel ayarlamalar yapılmadığı müddetçe alfabemizdeki kimi harfleri barındırmayacağı akılda tutulmalıdır.

.: Unicode tablosundaki herhangi bir karakter.
\p{ASCII} ([\x00-\x7F]): Unicode tablosunun ASCII altkümesinde bulunan karakterler.
\p{Alpha} ([a-zA-Z]): ASCII tablosundaki alfabetik karakterler. \p{Lower} ve \p{Upper}, sırasıyla, küçük ve büyük alfabetik karakterleri tanımlar.
\p{Digit} veya \d ([0-9]): Ondalık sayıların basamaklarında kullanılabilecek rakamlar. 16'lı tabandaki sayıların basamakları \p{XDigit} ile tanımlanır. Ondalık sayıların tümleyeni olan sınıf—yani, ondalık rakam olmayan karakterler—\D ile temsil edilir.
\p{Alnum} ([\p{Alpha}\p{Digit}]): Alfanümerik karakterler.
\w ([a-zA-Z0-9_]): Çoğu programlama dili tarafından tanımlayıcı adı oluşturmakta kullanılan karakterler. Tümleyen sınıf \W ile temsil edilir.
\p{Punct}: Noktalama imleri, ayırıcılar ve işleçler.
\p{Graph} ([\p{Alnum}\p{Punct}]): Fiziksel gösterimi bulunan karakterler.
\p{Print} ([\p{Graph}\x20]): Basılabilir karakterler. [\x20 boşluk karakterine karşılık geliyor.]
\p{Cntrl} ([\x00-\x1F\x7F]): Kontrol karakterleri.
\p{Space} veya \s ([ \t\n\x0B\f\r]): Bir metnin görünümünü düzenlemek için yararlanılan beyaz boşluk karakterleri.
\p{Blank} ([ \t]): Boşluk ve sekme karakterleri.

Yukarıdaki karakter sınıflarından ASCII tablosuna sınırlı olanların davranışı UNICODE_CHARACTER_CLASS bayrağı kullanılarak değiştirilebilir. Buna göre; "\p{Lower}" ile "ç" eşleşmezken, "(?U)\p{Lower}" ile "ç" eşleşecektir. Aynı etkiyi, Pattern.compile metoduna ikinci argüman olarak geçirilen bayraklar arasına UNICODE_CHARACTER_CLASS sabitini koyarak da yaratabiliriz.

import java.util.regex.Pattern;
import static java.util.regex.Pattern.*;
...
Pattern küçükHarf = compile("(?U)\\p{Lower}");
küçükHarf = compile("\\p{Lower}", UNICODE_CHARACTER_CLASS)); // Yukarıdakiyle aynı

Unicode tablosunu kullanmanın bir diğer yolu, Character sınıfındaki yüklemler vasıtasıyla işini gören karakter sınıflarından yararlanmaktır. Bu karakter sınıflarının adları, Character sınıfının ilişkin yüklemindeki is öneki yerine java konulmasıyla oluşturulur. Örnek olarak, argümanının birbirini tamamlayan karakter çiftlerinden ((), [], {}, <>, vd.) birine ait olup olmadığını denetleyen isMirrored yüklemini ele alalım. Düzenli deyimimizdeki bir karakterin bu tür bir karakter ile eşleşmesini istediğimizde yapmamız gereken, isMirrored'ı javaMirrored'a çevirmek ve karakter sınıfı adı olarak kullanmaktır. Dolayısıyla, "\p{javaMirrored}" ">" veya "(" ile eşleşirken çift olarak gelmeyen diğer karakterlerle eşleşmeyecektir.

küçükHarf = compile("\\p{javaLowerCase}"); // Yukarıdakilerle aynı
Pattern çifttenBiri = compile("\\p{javaMirrored}");

Düzenli Deyim İşleçleri

Temel düzenli deyim oluşturma işleci olan bitiştirme, iki karakterin [veya karakter öbeğinin] yanyana yazılmasıyla ifade edilip özel bir simgenin kullanımını gerektirmezken, geçiş sayısını belirtmek amacıyla farklı niceleme işleçlerinden yararlanılabilir. Karakteri takiben yazılan bu işleçlerden joker grubu olarak adlandırabileceklerimiz *, + ve ?, sırasıyla, 0 veya daha fazla sayıda, 1 veya daha fazla sayıda ve 0 veya 1 kez anlamına gelir. Yineleme sayısının kesin olması durumunda, kıvrımlı ayraç çifti ({}) arasında yazılacak bir sayı işi görecektir; yineleme sayısının alt ve üstten sınırlandırılması ise virgülle ayrılmış sınırların kıvrımlı ayraç çifti arasında verilmesiyle mümkün olurken, üst sınırın yazılmaması yinelemenin alt sınırdan az olmamak üzere belirsiz bir sayıda olabileceği anlamına gelir.

Yineleme işleçlerinden +, * ve bitiştirmenin birlikte kullanımına denk olduğu için işlevsellik adına bir şey katmaz. Örneğin "a+" "aa*" şeklinde ifade edilebilir. Ancak; okunabilirliği artırması ve düzenli deyim derleyicisinin kimi eniyilemeleri yapmasını olanaklı kılması nedeniyle "a+" deyiminin kullanımı daha doğru olacaktır. Benzer gözlemler diğer işleçlerin bazı kullanımları için de yapılabilir. Mesela, aynı nedenlerden ötürü (okunabilirlik ve eniyileme) "(ab|b)" yerine—|, ayırdığı deyimler arasında uygulanan "veya" işlecine karşılık gelir—"a?b" deyiminin yeğlenmesi yerinde olacaktır.

Niceleyicilerin sadece en son karakteri [veya karakter öbeğini] nicelediği unutulmamalıdır. Örneğin, "Ali+" "Al" ile başlayıp bir veya daha fazla sayıda 'i' ile devam eden girdileri betimler, bir veya daha fazla sayıda "Ali" değerini değil. Buna karşılık, "(Ali){2,}" şeklinde tanımlanan düzenli deyim, ayraçlar vasıtasıyla yapılan öbek tanımı sayesinde, iki veya daha fazla sayıda "Ali" değerinin geçtiği karakter katarlarını betimler.

Önceki paragraflarda anlatılan niceleyicilerin işleyiş mantığı, girdide sağlanan karakterlerden mümkün olduğunca çok tüketecek şekilde bir eşleme yapmak şeklindedir. Örneğin, "birberber" sabitini başarılı bir şekilde betimleyen ".*ber" düzenli deyiminde bulunan ".*" olabildiğince çok karakter yutacak ve "birber" ile eşleşecektir. Bir diğer deyişle, düzenli deyimin sonundaki "ber" girdinin sonundaki "ber" ile eşleşecektir. Yinelemenin en az sayıda karakter yutularak yapılması için ise niceleyici sonrasına ? konulması gerekir. Mesela, "*.?ber" deyimindeki "*.?", "birberber" içindeki ilk üç karakteri tüketecektir. Yani, eşleşmenin mümkün olduğu durumlarda ilk kullanımdaki niceleyici olabildiğince çok yiyerek açgözlü davranırken ikincisi olabildiğince az yiyerek gönülsüz davranacaktır.

İşleyiş ayrıntılarına girildiğinde, açgözlü niceleyicilerin bir zaafı ortaya çıkar: düşük performans. Örneğimiz üzerinden anlamaya çalışalım. Eşleştirici, "birberber" sabitinin ".*ber" düzenli deyiminin betimlediği kümede olup olmadığına karar vermek istediğinde, öncelikle ".*" ile tüm girdiyi tüketir ve "ber" kısmının eşleştirilmesi için geriye hiçbir şey kalmaz. Sonucun başarısızlık olması üzerine eşleştirici, bir karakter geriye sarar ve ".*" ile "birberbe" sabitini eşleştirerek "ber" kısmını "r" ile eşleştirmeye çalışır. Bu da olmayınca, yapılacak olan bir kere daha geriye sarmaktır. Bu sefer, ".*" "birberb" ile eşleştirilir ve arda "er" kalır. Üçüncü hüsranın sonrasında girdinin geriye sarılması ile "*." "birber", "ber" ise sondaki "ber" ile eşleşir ve bu güzel haber [dördüncü denemeyi takiben] kullanıcıya muştulanır. Geri sarmanın getireceği performans düşüklüğünün önüne geçmek, kimi zaman bir diğer niceleyici grubunun kullanılması ile mümkün olabilir: sahiplenici niceleyiciler. Benzer şekilde çalışan bu niceleyiciler, açgözlü eşdeğerlerinin aksine geri sarma işlemine başvurmaz ve eşleştirmenin başarısızlıkla sonlandığını ilan eder. Bundan dolayı, "birberber" ".*+ber" tarafından kabul edilmeyecektir. Çünkü, ".*+" açgözlü davranarak tüm girdiyi tüketecek ve geriye "ber" ile eşleştirilecek bir şey kalmayacaktır. Bu, geriye sarmanın olmaması ile birleştiğinde, sonucun olumsuz olacağı anlamına gelir. Yani, açgözlü niceleyiciyle eşleştirilen bazı girdiler sahiplenici niceleyiciyle eşleştirilemeyecektir. O zaman, işlev açısından eşdeğer olup bize performans açısından kazandırdıkları bir örnek görerek sahiplenici niceleyicilerin gerekliliğine ikna olalım.

Pattern.matches("\\d*+\\(Ev\\)", "123456789Ev)") // → false

Bir numarayı ev telefonu olduğu bilgisiyle birlikte betimleyen bu düzenli deyimde, sahiplenici niceleyici (*+) yerine açgözlü uyarlamanın (*) kullanılması yarar getirmeyeceği gibi daha düşük bir performansa neden olacaktır. Çünkü, dokuz basamaklı sayıyı yedikten sonra girdide '(' arayan eşleştirici, dokuz kez geriye sarıp önceki karakterlerin hiçbirinin aradığı karakter olmadığını pahalı yoldan öğrenecektir. Yani, geriye sarma sonucunda fazladan keşfedilecek bir eşlemenin olmaması geri sarmaya tenezzül etmeyen sahiplenici niceleyiciyi öne çıkarmaktadır.

Bayraklar

Pattern.compile metodu, eşlemenin nasıl yapılacağını etkileyen bayraklar da alabilir. Eşleştiricinin üzerinde çalışacağı tüm girdiler için geçerli olacak bu bayraklar, istenecek olursa, benzer bilgilerin düzenli deyimin içine yerleştirilmesi suretiyle de etkinleştirilebilir veya geçersiz hale getirilebilir. Pattern sınıfı içinde sabit olarak tanımlanan bu bayraklar ve anlamları şöyledir.

UNICODE_CASE (?u): Büyük küçük harfler arasındaki dönüşüm ve eşitlik denetimleri Unicode tablosu temel alınarak yapılır. Türkçe'yi temel alarak işlem yapmak istiyorsanız—mesela, i'den I yerine İ'ye dönüşüm yapılmasını istiyorsanız—bu bayrağı aklınızdan çıkarmamanızda yarar olacaktır.
CASE_INSENSITIVE (?i): Harflerin eşlenmesi sırasında büyük küçük ayrımı yapılmayacaktır. UNICODE_CASE ile birlikte kullanılmadıkça bu bayrağın etkisinin ASCII tablosundaki karakterlere sınırlı kalacağı unutulmamalıdır.
UNICODE_CHARACTER_CLASS (?U): Kullanılacak ASCII temelli karakter sınıflarının Unicode tablosunu temel alarak işlev görmesini sağlar. Bu bayrağın etkin kılınması ile birlikte, UNICODE_CASE bayrağının da otomatikman etkinleştirildiği akılda tutulmalıdır.
COMMENTS (?x): Düzenli deyim içindeki beyaz boşluklar ve '#' karakteri ile sonrasındaki satır sonuna kadar her şey göz ardı edilir.
MULTILINE (?m): Girdinin satır ayırıcı karakter(ler)inin (Unix temelli işletim dizgelerinde yeni satır karakteri ('\n'), Microsoft işletim dizgelerinde satır başı ('\r') ve yeni satır karakterleri) olduğu yerlerden ayırarak satırlar halinde incelenmesini sağlar. Buna göre, ^ ve $ artık girdinin başı ve sonunu değil, incelenmekte olan satırın başı ve sonunu belirtecektir.
UNIX_LINES (?d): Satırların Unix temelli işletim dizgelerinde olduğu gibi yeni satır karakteri ile sonlandığı varsayılacaktır.
DOTALL (?s): "." deyiminin satır ayırıcıları da betimlemesini sağlar. Bu, satır ayırıcılarının da ".*" ile yutulacağı anlamına gelir ve bu sebepten dolayı kimi zaman tek satır kipi olarak da adlandırılır.
LITERAL: Eşleştiricinin karakter katarını yorumlamayacağını bildiren bu bayrağın etkisi, düzenli deyimin "\Q"-"\E" çiftiyle çevrelenmesi yoluyla da elde edilebilir.
CANON_EQ: Unicode tablosunda birden çok nokta ile temsil edilen veya birden çok karakterin bileştirilmesi ile de oluşturulabilecek karakterlerin değişik karşılıklarının birbirine eşit olmasını sağlar. Örneğin, 231 (0xE7) nolu konumdaki ç harfi, c harfine kanca iminin (\u0327) monte edilmesiyle de oluşturulabilir.
```
Pattern desen = compile("c\u0327", CANON_EQ);
out.println(desen.matcher("ç").matches()); // ⇒ true
```
Dikkat edecek olursanız, \u önekiyle sağlanan karakterlerin, String sabitinin oluşturulması sırasında içselleştirilmesi nedeniyle, önüne ikinci bir \ konulmasına gerek yoktur.

Bayrakların düzenli deyim içinde belirtilmesi durumunda, birden çok sayıda bayrak aynı noktada etkinleştirilebileceği gibi, istenen bayraklar geçersiz de kılınabilir. Örneğin, (?Ui) betimlemenin Unicode tablosunu temel alarak büyük-küçük farkı gözetmeksizin yapılacağını ifade ederken, (?-d) [belki de daha önce etkinleştirilmiş olan] Unix usulü satır ayırıcı bayrağını o anki noktadan itibaren geçersiz hale getirmektedir.

Öbekler

Kimi zaman, düzenli deyimle girdi arasında bir eşleşmenin olup olmamasının yanısıra, eşleşme ile ilgili kimi ayrıntıları da öğrenmek isteriz. Örneğin, telefon numaralarını betimleyen bir düzenli deyimde, alan kodu ve numara ile ayrı ayrı ilgileniyor olabiliriz. Bu gibi bir durumda yapmamız gereken, düzenli deyimi karakter öbeklerine ayırmak ve eşleme sonrasında bu öbekleri sorgulamak olmalıdır.

Öbekler, ilgilenilen karakterlerin ayraç çifti arasına alınması ile oluşturulur. Eşleştirme sonrasında atıfta bulunulabilmesi için, öbekler açış ayraçlarının düzenli deyimdeki geçiş sırasına göre numaralandırılırlar. Örneğin, genç kızlık soyadını koruyarak adını yazan bayanların adları "(\p{Alpha}+)\s((\p{Alpha}+)-(\p{Alpha}+))" ile betimlenebilir. [Düzenli deyimi sınamak istediğinizde, \ yerine \\ koymayı unutmayınız.] Bu düzenli deyim, ad ile başlayıp bir boşlukla devam eden ve birbirinden - ile ayrılmış iki soyadını tanımlamaktadır. Ad ilk öbekle eşleşirken, tüm soyadı ikinci, eşin soyadı üçüncü, ve nihayet, genç kızlık soyadı dördüncü öbek olarak eşleştirilecektir.

Oluşturulan bir öbeği atıfta bulunarak kullanmak istediğimizde, bunu geçiş sırasının önüne \ koyarak sağlayabiliriz; \0 her zaman girdinin tümü ile eşleştirilir. İlk üç rakamın alan kodu ile aynı olduğu telefon numaralarını betimleyerek buna bir örnek verelim: "(\d{3})-(\1\d{4})". İlk öbeği alan kodu, ikinci öbeği telefon numarası ile eşleştiren bu düzenli deyim, "532-5321234" numarasını betimlerken "232-5321234" numarasını betimlemeyecektir.

İstediğimiz takdirde, öbeklere kendilerine verilen ad ile de atıfta bulunulabilir. Bunun için, öbeğe uygun görülen adın üçgen ayraç çifti arasına alınıp adlı öbeği başlatan (? sonrasına yazılması gerekir; öbeğe atıfta bulunmak istenmesi durumunda ise, öbek adının üçgen ayraçlarla birlikte \k'ye eklenmesi yeterli olacaktır. Buna göre, telefon numarası örneğimiz şöyle de yazılabilir: "(?<kod>\d{3})-(\k<kod>\d{4})". Bu arada; bir öbeğe ad verilmesi, söz konusu öbeğin geçiş sırasının geçersiz olduğu anlamına gelmez. İsteyecek olursak, düzenli deyimimizi "(?<kod>\d{3})-(\1\d{4})" olarak da tanımlayabiliriz.

Kimi zaman, eşleştirilen bir öbeği göz ardı etmek isteyebiliriz. Yani; eşleşmenin başarılı olması sonrasında söz konusu öbeğin hesaba katılmasını istemeyebiliriz. Bunun için yapmamız gereken şey, öbeğin (?: ile başlatılmasından ibarettir. Bu durumda, göz ardı edilen öbeğin açış ayracı öbek sırasını saptamakta yararlanılan sayacı etkilemeyecektir. Son olarak, şu nokta da unutulmamalıdır: adlandırılan öbekler göz ardı edilemezler.

Eşleştirici Kipleri

Java'daki düzenli deyim desteği, Pattern ve Matcher sınıflarındaki matches metotlarında gerçekleştirilenden farklı eşleştiriciler de sağlar. Bunlardan Pattern sınıfındaki split iletisi, argümanındaki CharSequence kategorisine ait katarı, ileti alıcının temsil ettiği deseni kullanarak String nesnelerine böler ve bu String'leri içeren diziyi döndürür.

...
Pattern desen = Pattern.compile(":");
String[] bilgi = desen.split("Gökçe Begüm:Ege:532-1234567");
// bilgi[0] ← "Gökçe Begüm", bilgi[1] ← "Ege", bilgi[2] ← "532-1234567"

İstenecek olursa, split'e sağlanacak ikinci argüman ile döndürülecek dizinin eleman sayısı sınırlandırılabilir. Örneğin, yukarıdaki kullanımda ikinci argüman olarak 2 geçirilmesi, ilki "Gökçe Begüm" ikincisi "Ege:532-1234567" değerine sahip iki elemanlı bir dizi döndürecektir.

Göz atacağımız diğer eşleştiriciler marifetlerini Matcher nesnelerine gönderilen iletiler yoluyla gösterirler. Dolayısıyla, düzenli deyimin compile metodu ile derlenmesi sonucu elde edilen desene (Pattern nesnesi) matcher iletisinin gönderilmesi yapacağımız şeylerin başında gelmelidir. İkinci adım olan eşleştiricinin çağrılması öncesinde, işlemin etkili olacağı girdi bölgesi region iletisi ile belirtilebilir. [Daha sonra eşleştiricimizin girdinin hangi bölümünü ele aldığını görmek istersek, ilişkin bölgenin tanımlanmasında kullanılan argüman değerlerini döndüren regionStart ve regionEnd iletilerinden yararlanabiliriz.] Son adım olarak ise, desen ile girdinin uyuşması halinde icra edilecek bir inceleme aşaması vardır. Bu, String argümanlı group iletisinin yanısıra MatchResult arayüzünde yer alan iletilerin eşleştiriciye gönderilmesi ile yapılablir. Dolayısıyla, tipik eşleştirici kullanımı aşağıdaki şablonu takip edecektir.

import java.util.regex.*;
...
Pattern desen = Pattern.compile(...);
Matcher eşleştirici = desen.matcher(...);
eşleştirici.region(başİndis, sonİndis + 1); // Seçimli
... // Eşleştiriciyi uygun bir kipte kullan.
if (tanındıMı) {
  MatchResult sonuç = eşleştirici.toMatchResult();
  ... // sonuç'u incele
}

Eşleştiricinin yaratılması sonrasında girdinin ele alınması noktasında farklı çalışma kiplerini temsil eden üç yüklemden bahsedebiliriz: matches, lookingAt, find. Önceki örneklerimizden de gördüğümüz gibi matches, girdi ile [düzenli deyimin içselleştirilmiş karşılığı olan] deseni eşleştirirken girdinin tümünü tüketmeye çalışır; aksi takdirde, eşleştirme sonucu olumsuz olacaktır. Bundan dolayıdır ki, ".*ber" "birberbere" sabitini tanımaz. Çünkü, ".*" ile "birber" ve "ber" ile girdideki "ber" eşleşmesini takiben sondaki "e" açıkta kalır ki, bu matches metodundan false döndürülmesine neden olur. Artık girdinin eşleşmeyi engellemesi istenmiyorsa, matches yerine lookingAt iletisi kullanılmalıdır. matches'da olduğu gibi, girdinin ilgilenilen bölgesinin başından itibaren eşleştirerek işini gören lookingAt, girdinin sonunda eşleşme ile kapsanmayan karakterlerin kalmasına itiraz etmez ve true döndürür. Dolayısıyla, bu eşleştirici kipinde ".*ber" "birberbere" sabitini betimliyor kabul edilecektir. Ne var ki, lookingAt iletisi de, tıpkı matches gibi, girdi başının desenle uyuşmaması durumunda devamında ne olursa olsun false döndürür. Örneğin "a.*b", ne matches ne de lookingAt ile kullanıldığında, "qawdesb" girdisini betimlemeyecektir. Çünkü, her iki eşleştirici kipi de düzenleyici deyim başındaki 'a' değerini girdinin en başında arayacak ve başarısızlık sonrasında false döndürecektir. Sıkıntımızın çözümü, eşleştiriciyi find kipiyle kullanmakta yatar. Seçimli bir int argüman bekleyen bu eşleştirici kipi, girdinin başındaki eşleşmeyen karakterleri atlar ve deseni girdi içinde arar; girdinin başındaki ve sonundaki eşleşmeyen parçalar sonucun olumsuz olmasına neden olmaz. Dolayısıyla, "a.*b" düzenli deyiminin "qawdesbc" içinde aranması, baştaki "q" değerini göz ardı ettikten sonra, "awsdesb" ile eşlemeyi sağlayacak ve sonda artan "c" değerine rağmen true döndürecektir.

Eşleştirici kipleri arasındaki bir diğer fark, daha önceden eşleştirilmiş desen-girdi çiftinin sıfırlanmaksızın tekrar kullanılması durumunda sergilediği davranış biçimidir. Girdinin tümünü eşleştirmeye çalışan matches, girdiyi tüketmiş olduğu için ikinci ve sonraki kullanımlarında her zaman false döndürürken, lookingAt her zaman ilk kullanımda döndürdüğü sonucu döndürür. Dolayısıyla, aşağıdaki kod parçası sonsuz döngü içinde standart çıktı ortamına ba yazmaktan başka bir şey yapmayacaktır. [MatchResult arayüzü iletilerinden olan group, argümanında geçirilen sıradaki öbeği döndürür; 0 eşleştirilen tüm girdi parçasına karşılık gelir ve aynı etki group iletisini argümansız kullanmakla da yaratılabilir.]

String düzenliDeyim = "ba", girdi = "baba";
Pattern desen = Pattern.compile(düzenliDeyim);
Matcher e = desen.matcher(girdi);
while (e.lookingAt())
  System.out.println(e.group(0));

Bu durumun önüne geçilmesi lookingAt iletisinin üzerinde çalıştığı bölgenin aşağıdaki gibi değiştirilmesi ile mümkündür. Argümansız end iletisi, en son eşleştirmenin tükettiği son karakterin ötesindeki ilk karakterin indisini döndürür; öbek sayısını belirten bir tamsayının geçirilmesi halinde ise, aynı ileti belirtilen öbeğin sonunu takip eden karakterin indisini döndürür. [e.end() gönderisinin etkisi, e.start() + e.group().length() ile de sağlanabilir.]

while (e.lookingAt()) {
  System.out.println(e.group(0));
  e.region(e.end(), girdi.length());
}

find iletisi ise, başarılı eşleştirmenin ardından girdinin eşleşme sonrasındaki karakterinden devam ederek işini görür. Buna göre, yukarıdaki kod parçası şöyle de yazılabilir.

while (e.find())
  System.out.println(e.group(0));

Girdinin aynı veya farklı bölgelerinin farklı desenler kullanılarak eşleştirilmesi için, girdiyi parçalamak ve farklı eşleştiriciler kullanmaktansa, usePattern iletisi tercih edilmelidir. Bu iletinin kullanıldığı noktadan itibaren, ileti alıcı konumundaki eşleştirici girdinin sonuna veya bir sonraki usePattern kullanımına kadar tüm eşleştirmeleri söz konusu iletiye geçirilen deseni kullanarak yapacaktır.

String düzenliDeyim = "ab", girdi = "abba";
Pattern desen = Pattern.compile(düzenliDeyim);
Matcher e = desen.matcher(girdi);
if (e.find()) {
  System.out.println(e.group(0));
  e.usePattern(Pattern.compile("ba"));
  if (e.find())
    System.out.println(e.group());
}

Aynı eşleştiricinin farklı bir desenle kullanılmasını olanaklı kılan bir diğer ileti, CharSequence kategorisindeki yeni düzenli deyimi argüman olarak bekleyen reset'tir. usePattern'dan farklı olarak bu ileti, eşleştiriciyi girdinin başına konumlandırarak bölge tanımlarını geçersiz kılar. Bu işlemin desen değiştirilmeden yapılması için reset iletisinin argümansız uyarlamasının kullanılması yeterli olacaktır.

Eşleştiricilerin kimi kullanım desenleri, yüksek kullanım potansiyelleri nedeniyle Matcher sınıfında gerçekleştirilen iletiler halinde desteklenirler. Bunlardan biri olan appendReplacement, daha ziyade find ile birlikte kullanılır ve girdinin eşleşmeyen kısmını ilk argümanındaki StringBuffer türlü karakter tamponuna olduğu gibi eklerken, eşleştirilen parça yerine ikinci argümandaki String'i koyar. Bu iletiyi tamamlayan appendTail ise, başarısız bir eşleştirme çabası sonrasında girdinin ilişkin parçasını argümanındaki karakter tamponunun sonuna ekler.

String düzenliDeyim = "k", girdi = "bakbakbakşuna";
Pattern desen = Pattern.compile(düzenliDeyim);
Matcher e = desen.matcher(girdi);
StringBuffer tampon = new StringBuffer();
while (e.find())
  e.appendReplacement(tampon, "h");
String sonuç = e.appendTail(tampon).toString();

Buna göre, yukarıdaki döngünün ilk dönüşündeki eşleştirme ilk iki karakteri atlayacak ve desenimizi üçüncü konumdaki "k" ile eşleştirecektir. Sonuç olarak, tampon ile gösterilen bölgeye atlanan parça ("ba") değiştirilmeden, eşleştirilen parça ("k") ise "h" olarak eklenecektir. Dolayısıyla, ilk döngünün sonuna gelindiğinde tampon değişkeninde "bah" biriktirilmiş olacaktır. Döngünün ikinci ve üçüncü dönüşlerinde de benzer şekilde çalışan kod parçası, tamponda biriktirilen değeri "bahbahbah" haline dönüştürecektir. Dördüncü dönüşte, deseni "şuna" ile eşleştirmeye çalışan find olumsuz sonuç döndürecek ve döngüden çıkılacaktır. Bunu takiben gönderilen appendTail iletisi ise eşleştirilemeyen girdiyi tampon sonuna ekleyerek işi tamamlayacaktır.

Bir önceki paragrafta anlatılan değiştirme işlemi, replaceAll iletisi ile de yapılabilir. Anılan ileti, desenin eşleştirildiği girdi bölümlerini argümanında geçirilen String ile değiştirir. Benzer bir işlev gören repeatFirst ise, değişikliği eşleşmenin olduğu ilk noktada yapmakla yetinir.

String düzenliDeyim = "k", girdi = "bakbakbakşuna";
Pattern desen = Pattern.compile(düzenliDeyim);
Matcher e = desen.matcher(girdi);
String sonuç = e.replaceAll("h"); // sonuç ← "bahbahbahşuna"

Karakter Katarı Sınıfları

İki yöntem ile bir programın doğrudan yorumlanması ve Bytecode gibi bir aradile çevrildikten sonra yorumlanması arasında koşutluk kurabiliriz. ↑
Bu uygulama, ifadenin konuşmacı tarafından yorum katılmadan aktarıldığını ifade eden dilimizdeki "Başbakan aynen şöyle dedi: ...", İngilizce'deki "The Prime Minister said, quote ... end quote" kalıplarına benzetilebilir. ↑

Soysallık

2011-11-10T18:15:00.001+02:00

Kalıtlamanın getirilerinden biri, sınıflar arası ortak yönlerin bir üstsınıfta toplanmasına olanak tanıyarak kodun yeniden kullanımını sağlamasıdır.¹ Bu sayede, değişikliğin gerektiği durumlarda birçok sınıfta değişiklik yapmaktansa üstsınıftaki kodun değiştirilmesi ile işin daha kısa sürede ve daha düşük hata oranlı bir biçimde yapılması mümkün olacaktır. Ne var ki, aynı yöntemin değişik türden verileri tutmada yararlanılan veri kaplarının gerçekleştiriminde kullanılması derleme zamanında denetlenebilecek kimi hataların çalışma zamanına kaymasına neden olmaktadır ki, bu piyasaya çıkmış bir yazılımın müşterinin "hatalı" kullanımı sonrasında göçebileceği anlamına gelir. Ne kastettiğimizi son giren ilk çıkar mantığıyla çalışan yığıt veri yapısının aşağıdaki gerçekleştirimi üzerinden görelim.

YığıtBoşDurumu.java

package vy.ayrıksıdurumlar;

public class YığıtBoşDurumu extends RuntimeException { ... }

IYığıt.java

package vy.arayüzler;

import vy.ayrıksıdurumlar.YığıtBoşDurumu;

public interface IYığıt {
  Object çıkar() throws YığıtBoşDurumu;
  void ekle(Object yeniElm);
  Object gözAt() throws YığıtBoşDurumu;
  boolean boşMu();
} // IYığıt arayüzünün sonu

Yığıt.java

package vy;

import java.util.Vector;
import vy.ayrıksıdurumlar.YığıtBoşDurumu;
import vy.arayüzler.IYığıt;

public class Yığıt implements IYığıt {
  public Yığıt() { _kap = new Vector(); }
  ...
  public Object çıkar() throws YığıtBoşDurumu {
    if (boşMu()) throw new YığıtBoşDurumu();

    Object üstteki = _kap.get(_kap.size() - 1);
    _kap.remove(_kap.size() - 1);

    return üstteki;
  } // Object çıkar() sonu 
  ...
  private Vector _kap;
} // Yığıt sınıfının sonu

Ekleme ve çıkarmanın elemanları tutan kabın aynı ucuna—mesela, Vector sonu veya LinkedList başı—yapılarak gerçekleştirilebilecek yığıt, söz konusu işlemlerin ilişkin arayüz tanımında da belirtildiği üzre Object tutacakları ile işlerini görmeleri nedeniyle herhangi türden bir nesneyi tutabilecektir. Buna göre, Yığıt sınıfının nesneleri yeri geldiğinde Öğrenci nesneleri tutarken, yeri geldiğinde Öğretmen nesneleri de tutabilecektir. Ancak, dikkat etmediğimiz takdirde aşağıda olduğu gibi bir durumun ortaya çıkması da olanaklıdır.

public static void yığıtıKullan() {
  IYığıt sınıf = new Yığıt();
  sınıf.ekle(new Öğrenci(...));
  Öğrenci ilkÖğrenci = (Öğrenci) sınıf.gözAt();
  if (Math.random() > Math.random())
    sınıf.ekle(new Öğrenci(...));
    else sınıf.ekle(new Öğretmen(...));
  ...
  Öğrenci sonÖğrenci = (Öğrenci) sınıf.çıkar();
  ...
} // void yığıtıKullan() sonu

Yığıt tanımımız Object tutacağı ile gösterilebilen türden—yani, Java'daki bileşke türlerin tümü—nesne tutabileceği için elemanların türdeş olma garantisi derleyici tarafından denetlenemez. Her ikisi de eninde sonunda Object'ten kalıtladığı için, aynı yığıta Öğrenci nesnesi de Öğretmen nesnesi de eklenebilmektedir. Bu ise, yukarıdaki kod parçasının son satırında olduğu gibi türdeşlik garantisinden hareketle yazılan satırların programın çalıştırılması sırasında ClassCastException ayrıksı durumuna neden olması demektir. Yani, yığıtımız ekleme sırasında itiraz etmediği nesnenin geri döndürülmesi sırasında kullanıcının kodunu göçertmektedir. Bunun önüne geçmek ancak öngörülen türlerin tümü için ayrı yığıt gerçekleştirimlerinin sağlanması ile olanaklıdır. Bu ise aşağıdaki gibi gereğinden kalabalık ve bakımı zor bir sınıf sıradüzeni anlamına gelir.

Object

Kişi

Çalışan

Öğretmen
Müstahdem

Öğrenci

Yığıt_Object, Yığıt_Kişi, Yığıt_Çalışan, Yığıt_Öğrenci, Yığıt_Öğretmen, Yığıt_Müstahdem, ...

Dilimizde iki ucu gaytalı değnek şeklinde nitelenen bu durum, J2SE 5.0 sürümüne kadar geçerli olmuş ve anılan sürüm ile birlikte Java diline eklenen soysallık yoluyla ortadan kaldırılabilmiştir. Bu özellik sayesinde, olası biçimlendirme hatalarının derleme zamanında önüne geçilerek tür güvenliği sağlanmış ve tek bir tür tanımının kullanılması ile kod bakımı kolaylaştırılmıştir. Soysallıktan yararlanarak oluşturulan sıradüzeni aşağıdaki gibi olacaktir.

Object

Kişi

Çalışan

Öğretmen
Müstahdem

Öğrenci

Yığıt<E>

Soysal Türlerin Tanımı ve Kullanımı

Soysal türlerin tanımı ve kullanımı metotları andırır. Nasıl ki, metotların hangi türden değerler geçirilerek işletilebileceğini belirtmek için ayraç çifti arasında belirtilen parametre listesi kullanılır, soysal türlerin hangi türler için parametrize edildiğini belirtmek için üçgen ayraç çifti arasında belirtilen tür parametre listesinden yararlanılır. Buna göre, yukarıdaki arayüz ve sınıfın soysal uyarlaması aşağıdaki gibi olacaktır.

IYığıt.java

package vy.arayüzler;

import vy.ayrıksıdurumlar.YığıtBoşDurumu;

public interface IYığıt<E> {
  E çıkar() throws YığıtBoşDurumu;
  void ekle(E yeniElm);
  E gözAt() throws YığıtBoşDurumu;
  boolean boşMu();
} // IYığıt<E> arayüzünün sonu

Yığıt.java

package vy;

import java.util.Vector;
import vy.ayrıksıdurumlar.YığıtBoşDurumu;
import vy.arayüzler.IYığıt;

public class Yığıt<E> implements IYığıt<E> {
  public Yığıt() { _kap = new Vector<E>(); }
  ...
  public E çıkar() throws YığıtBoşDurumu {
    if (boşMu()) throw new YığıtBoşDurumu();

    E üstteki = _kap.get(_kap.size() - 1);
    _kap.remove(_kap.size() - 1);

    return üstteki;
  } // E çıkar() sonu
  ...
  private Vector<E> _kap;
} // Yığıt<E> sınıfının sonu

Bir soysal türün nesnesinin yaratılması, tür parametrelerine karşılık gelen tür argümanlarının soysal türün adının ardından sağlanmasıyla mümkün olur. Bunun sonucunda soysal türün örneği olarak kullanılacak türe parametreli tür denir. Örneğin, aşağıdaki kod parçasında IYığıt<Öğrenci> parametreli türüne sahip sınıf değişkeni Yığıt<Öğrenci> parametreli sınıfına ait bir kabı göstermektedir ve bu kap Öğrenci tutacakları—dolayısıyla, Öğrenci köklü sıradüzenindaki sınıfların türünden nesneler—içerecektir.² Ayrıca, dikkat ederseniz, tür parametresi ile belirtilen dönüş türlerine sahip iletiler/metotlar (gözAt, çıkar) biçimlendirme olmaksızın kullanılmaktadır; zira, biçimlendirme derleyici tarafından eklenen kod sayesinde otomatikman yapılmaktadır.

public static void yığıtıKullan() {
  IYığıt<Öğrenci> sınıf = new Yığıt<>();
  sınıf.ekle(new Öğrenci(...));
  // Biçimlendirmeye gerek yok
  Öğrenci ilkÖğrenci = sınıf.gözAt();
  if (Math.random() > Math.random())
    sınıf.ekle(new Öğrenci(...));
    else sınıf.ekle(new Öğretmen(...)); // Derleme hatası!!!
  ...
  Öğrenci öğr = sınıf.çıkar();
  ...
} // void yığıtıKullan() sonu

Bu noktada, tür argümanlarının bileşke türlü olmak zorunluluğu hatırlatılmalıdır. Dolayısıyla, IYığıt<int> tamsayılar = new Yığıt<>(); şeklinde bir tanımın yapılması derleyici tarafından kabul görmeyecektir. Ancak bu, parametreli sınıflara ait kaplara ilkel türlü değerlerin konulamayacağı anlamına gelmez. Yapılması gereken, kabı söz konusu ilkel türün karşılığındaki sarmalayıcı tür ile ilan edip işin gerisini derleyiciye bırakmaktır. Derleyici, eklenmek istenen ilkel türlü değeri usulca sarmalarken (İng., boxing, wrapping) döndürülen tutacağın gösterdiği nesneyi açarak (İng., unboxing) içeriği ilkel değere dönüştürecektir.

IYığıt<Integer> tamsayılar = new Yığıt<>();
tamsayılar.ekle(3); // Aşağıdaki ile aynı
tamsayılar.ekle(new Integer(3));
...
int üstteki = tamsayılar.çıkar();
// ≡ int üstteki = tamsayılar.çıkar.intValue();

Gerektiği takdirde, tür parametresine sınır getirerek kullanım noktasında geçirilmesi beklenen türlerin kısıtlanması sağlanabilir. Örnek olarak, sadece Number köklü sıradüzenindeki sınıfların nesnelerini içerebilecek bir kap düşünün. Bu istem, aşağıdaki sınıf başlığında olduğu gibi, Number sınıfının soysal türün parametresine üst sınır olarak getirilmesiyle ifade edilir. Böylece, SayıKabı soysal sınıfına üye parametreli sınıfların tür argümanı Number ya da Number'dan kalıtlayan sınıflara sınırlı olacaktır; derleyici diğer kullanımları hatalı kabul edecektir. Buna göre, SayıKabı<Byte> ve SayıKabı<Float> kabul görürken, SayıKabı<Object> ve SayıKabı<Character> reddedilecektir.

public class SayıKabı<E extends Number> { ... }

İstendiği takdirde, tür parametreleri gerçekleştirilmesi beklenen bir arayüz ile de sınırlandırılabilir. Hatta, sınıf adı ve birden çok arayüz adı birlikte verilerek de sınır konulabilir. Mesela, aşağıdaki soysal türün kullanımı noktasındaki kabul edilebilir tür argümanlarının Snf'den kalıtlaması ve Aryz1 ile Aryz2 arayüzlerini gerçekleştirmesi zorunludur.

public class SoysalTür<E extends Snf & Aryz1 & Aryz2> { ... }

J2SE 5.0 Öncesi Kod İle Birliktelik: Ham Türler

Java'daki soysal türler, J2SE 5.0 sürümüne dek geçen dokuz yıla yakın sürede üretilen kodun kullanılmasını sağlamak adına ham türleri destekler. Bu desteğin amacı, hali hazırda var olan milyonlarca satırın çöpe gitmesini önlemek ve söz konusu soysallık öncesi kodun zaman içinde dönüştürülmesini sağlamaktır.

Ham türlü tanımlayıcılar, soysal bir türün üçgen ayraç çifti ve tür argümanları olmaksızın, yani J2SE 5.0 öncesindeki gibi, kullanılması ile tanımlanır. Soysal türü tür parametrelerine Object geçiriliyormuş gibi kullanmaya denk olan bu kullanım, her şey eninde sonunda Object tutacağı yoluyla görülebileceği için, derleyicinin kullanım hatalarını denetleme yeteneğini ortadan kaldırır. Dolayısıyla, soysallık sonrası yazılan kod içinde ham türlerin kullanımından kaçınılmalıdır.

Ham türlerin kullanımı iki durumda zorunludur: i) Yeni kod içinden soysallık öncesi kod kullanıldığında, ii) eski kod içinden soysal kod kullanıldığında. Örneğimiz ile devam ederek iki duruma da bir bakalım. Varsayalım ki, soysallık öncesinde IYığıt ve Yığıt türlerini tanımladık ve sınadıktan sonra kullanıma sunduk. Bu türler, soysallığa dair tür parametreleri olmadığı için, tür argümanları geçirilerek kullanılamaz; kullanım, ister soysallık öncesi kod içinden olsun isterse soysallık sonrası kod içinden, aşağıdaki gibi olacaktır.

public static yığıtıKullan() {
  IYığıt sınıf = new Yığıt();
  sınıf.ekle(new Öğrenci(...));
  Öğrenci ilkÖğrenci = (Öğrenci) sınıf.gözAt();
  if (Math.random() > Math.random())
    sınıf.ekle(new Öğrenci(...));
    else sınıf.ekle(new Öğretmen(...)); // Derleme hatası vermez!
  ...
  Öğrenci sonÖğrenci = (Öğrenci) sınıf.çıkar();
  ...
} // void yığıtıKullan() sonu

Soysallık sonrası yazılmış olan kullanıcı kodun derlenmesi hataya sebep olmamakla birlikte, derleyicinin, bu çeşit bir kullanımı potansiyel çalışma zamanı hatalarına davet çıkarmak olarak görmesi nedeniyle, denetlenemeyen olası hata uyarısını (İng., unchecked warning) vermesine yol açacaktır. Yani, soysallık öncesindeki gibi sessiz kalmaktansa, derleyici olası hataya işaret etmekte ve bizden ya kullanıcı kodunu değiştirerek duruma açıklık getirmemizi ya da elimizin altındaysa hem kullanılan kodu hem de kullanıcı kodunu soysallık sonrası standartlarına getirmemizi istemektedir. Kullanılan kodun elimizin altında olmaması halinde, iki şey yapılabilir: i) Kullanılan kod soysal değilse, kodumuz içinde kullanımımızın doğru olduğuna dair derleyiciye garanti veririz, ii) kullanılan kod soysalsa soysal türü kullanma niyetimizi belirten tür argümanlarını kullanırız. İlk şık, aşağıdaki şekilde SuppressWarnings açımlamasıyla yerine getirilebileceği gibi derleyiciye geçirilecek -Xlint:-unchecked opsiyonu ile de yerine getirilebilir. Her iki durumda da yaptığımız, derleyiciye "unchecked" etiketli uyarıları göz ardı etmesini söylemektir. Ancak; ilk yöntemde uyarılar açımlamanın öncesine yerleştirildiği metot boyunca göz ardı edilirken, derleme opsiyonu yeğlendiğinde derleyicinin hoşgörüsü derlenen tüm koda yaygınlaştırılmaktadır.

@SuppressWarnings({"unchecked"})
public static void yığıtıKullan() {
  IYığıt sınıf = new Yığıt();
  sınıf.ekle(new Öğrenci(...));
  Öğrenci ilkÖğrenci = (Öğrenci) sınıf.gözAt();
  if (Math.random() > Math.random())
    sınıf.ekle(new Öğrenci(...));
    else sınıf.ekle(new Öğretmen(...));
  ...
  Öğrenci sonÖğrenci = (Öğrenci) sınıf.çıkar();
  ...
} // void yığıtıKullan() sonu

Kullanılan kodun elimizin altında olması halinde, verilen uyarı dikkate alınmalı ve kaynak kod soysallık sonrası standartlara getirilerek yeniden derlenmelidir. Yeniden derlenen kodun eski kullanıcıları bu değişiklikten etkilenmeyeceklerdir. Çünkü, soysallık öncesinde yazılmış kullanıcılar değiştirilmiş kodun gözünde ham türlerden yararlanan yeni koddan farklı değildir.

Daha Esnek Metot İmzaları İçin Joker Türler

Pek çok ölümlü Java programcısı için soysallık desteğini ustaların erişilmez alemine sınırlı kılan en başlıca etken, joker tür argümanlarının varlığıdır. Değişik biçimlerde kendini gösteren bu korkunç yaratığı, iki kümenin sahip olduğu ortak elemanların sayısını döndüren metodu gerçekleştirerek tanımaya başlayalım. Veri Kapları Çerçevesi'nin sağladığı Set arayüzünde karşılanmayan bu işlem, birinci argümandaki kümenin her bir elemanının diğer kümede var olup olmamasına göre sayaç değişkenini güncelleyen aşağıdaki metotla gerçekleştirilebilir.

import java.util.Set;
...
public static int ortakElmSayısı(Set km1, Set Km2) {
  int elmSayısı = 0;
  for (Object elm : km1)
    if (km2.contains(elm)) elmSayısı++;

  return elmSayısı;
} // int ortakElmSayısı(Set, Set) sonu

Bir önceki altbölümden dersini almış olanlarınız, metot imzasındaki ham türlere bakıp bildiklerinden kuşkuya düşerek, neden Set<Object> kullanılmamış, diye sorabilirler. Öncelikle, bu arkadaşları doğru yolda olduklarını söyleyerek yatıştıralım; gerçekten de, yukarıdaki imzada bulunan ham türler derleyicinin tür denetim desteğini engellemek suretiyle tehlikeye davet çıkarıyor. Ancak; ham tür yerine Set<Object> kullanmak da sorunu halletmiyor. Şöyle ki; T'nin S'den kalıtladığı ve G'nin soysal tür olduğu bir ortamda, G<T> G<S>'den kalıtlamaz. Bir diğer deyişle, G<T> nesneleri G<S> nesneleri olarak ele alınamaz. Somutlaştıracak olursak, Integer'ın Object'ten kalıtlıyor olmasına karşın, Set<Integer> Set<Object>'ten kalıtlamaz. Bu ise, iki türün uyumsuz olduğu ve birbirlerini ilklemekte veya birbirlerine atanmakta kullanılamayacağı anlamına gelir. Gelin, bu sonucu aşağıdaki kod parçasının üzerinden giderek pekiştirelim. Öncelikle, 3. satırda kümeyi yaratırken elemanlarımızın Integer (ve otomatikman sarmalanarak Integer'a dönüştürülen int) ile tür uyumlu olabileceğini ilan ediyoruz. Daha sonraki satırlarda, verdiğimiz bu söze uyarak kümemize eleman ekliyoruz. Ancak; intKüme ile Set<Object> türlü objKüme'yi ilkleyen son satır, derleyicinin sıkı denetimini aşamıyor ve hataya neden oluyor. Bunun sebebi, iki tutacak tarafından paylaşılan ve başta Integer ile tür uyumlu nesneler ile doldurulacağı ilan edilen küme nesnesinin artık objKüme aracılığıyla Object ile tür uyumlu nesneler—yani, Java nesne alemindeki bütün nesneler—ile doldurulması ihtimalidir.

import java.util.*;
...
Set<Integer> intKüme = new TreeSet<>();
intKüme.add(new Integer(0));
...
Set<Object> objKüme = intKüme; // Derleme hatası!!!

Derdimizin çaresi tür argümanı olarak joker kullanımından geçer. ? ile belirtilen joker, adını bilmediğimiz veya umursamadığımız türler için kullanılır. Aşağıdaki metot imzasını buna uygun okuyacak olursak, ortakElmSayısı'nın herhangi bir türden elemanlara sahip iki Set beklediğini söyleyebiliriz.

public static int ortakElmSayısı(Set<?> km1, Set<?> Km2) {
  ...
} // int ortakElmSayısı(Set<?>, Set<?>) sonu

Şu iki noktanın akılda tutulmasında yarar olacaktır: i) farklı parametrelerde kullanılan jokerler birbirinden bağımsızdır ve farklı türlerle eşleştirilebilirler, ii) joker parametreli türün nesnesine eleman olarak sadece null eklenebilir.³

Yığıt arayüzüne iki yeni ileti ekleyerek devam edelim. Bunlardan yükle, argümanındaki kabın elemanlarını teker teker hedef nesneye eklerken, temizle hedef nesneyi boşaltırken silinen elemenları daha sonraki kullanımlar için argümanda geçirilen kaba kaydediyor.

import java.util.Collection;

public class IYığıt<E> {
  ...
  public void temizle(Collection<E> kopya); // Kapsayıcı değil!
  public void yükle(Collection<E> kaynak); // Kapsayıcı değil!
  ...
} // IYığıt<E> arayüzünün sonu

İlk denememiz, soysal türlerin daha önceden bahsettiğimiz kalıtlama ile birlikte değişmeme özelliğinden dolayı tüm kullanımları kapsamıyor ve kimi zaman kullanıcı tarafında derleme hatasına neden olabiliyor. Anılan özelliği yinelemektense, yükle iletisinin bir kullanım örneğine bakarak durumu anlamaya çalışalım.

IYığıt<Kişi> güruh = new Yığıt<>();
// güruh'a bir şeyler koy
Vector<Öğrenci> sınıf = new Vector<>();
// sınıf'a bir şeyler koy
güruh.yükle(sınıf); // Derleme hatası!!!

Belli ki, yukarıdaki kodu yazan arkadaş Öğrenci sınıfının Kişi'den kalıtladığını düşünerek Vector<Öğrenci> adlı parametreli türün de Collection<Kişi>'yi gerçekleştiren Vector<Kişi>'den kalıtladığı sonucuna varmış. Ne var ki, soysallığın kalıtlama ile birlikte değişme özelliği olmaması nedeniyle, öncülü doğru olan bu tümcenin sonuç kısmı hatalı. Yani, Vector<Öğrenci> Vector<Kişi>'den kalıtlamaz. İş böyle olunca, kodun son satırı parametre (Collection<Kişi>) ile argüman (Vector<Öğrenci>) arasındaki tür uyumsuzluğu nedeniyle derleme hatasına yol açıyor.

İçine düştüğümüz sıkıntı, sınırlı joker kullanımıyla çözülebilir. Yukarıdaki örneği sürdürerek ifade edecek olursak; derleyiciye söylememiz gereken, Yığıt<Kişi> türlü bir yığıta Kişi veya Kişi'den kalıtlayan herhangi bir sınıfa ait elemanlar içeren bir kap ile yükleme yapılabileceğidir. Bu ise, yükle'nin parametresinin Collection<? extends E> türüne sahip ilan edilmesi ile olanaklıdır. Yani, hedef nesneye girdi sağlama görevi gören kap, üst sınırlı joker türüyle tanımlanmalıdır.

temizle iletisinin imzasında ortaya çıkan sorun da sınırlı jokerlerin koşut bir kullanım biçimiyle sağlanabilir. Önce derleyicinin kabul etmeyeceği bir kullanıcı kodu görelim.

IYığıt<Öğrenci> sınıf = new Yığıt<>();
// sınıf'a bir şeyler koy
Vector<Kişi> güruh = new Vector<>();
sınıf.temizle(güruh); // Derleme hatası!!!

Bu örnekte de esnek olmayan bir imzanın cezasını çekiyoruz: Öğrenci tür argümanıyla yaratılan sınıf ancak ve ancak Öğrenci tutacakları içeren bir kaba kaydedilebiliyor. Kullanıcının yapmak istediği gibi kap Kişi eleman türüne sahip olduğunda, derleyici karşımıza dikiliveriyor. Halbuki, Öğrenci tutacağı ile görülebilen nesneler Öğrenci'nın atası olan tüm sınıfların (Kişi ve Object) tutacakları ile de görülebilir. Yani, imzanın kullanıcımızın yapmak istediğine izin verecek şekilde gevşetilmesi gerekir. Bir diğer deyişle, yığıt içeriğinin kaydedildiği kabın eleman türünün Öğrenci ve Öğrenci'nin atası olan herhangi bir sınıf olabileceğini derleyiciye bildirmemiz gerekir. Bu ise, alt sınırlı bir joker türünün kullanımı ile olanaklıdır ve örneğimizde imzadaki parametre türünün Collection<? super E> şeklinde değiştirilmesi işimizi görecektir.

Buna göre, arayüze eklenmek istenen iletilerin imzası şu şekilde oluşur. Ortaya çıkan imzalar, parametre listesindeki kaplar için genelde izlenmesinde yarar olacak bir kuralı da ele vermektedir: Hedef nesneye girdi sağlama görevi gören kaplar üst sınırlı joker tür, hedef nesnenin ürettiği çıktının kaydedildiği çıktı amaçlı kaplar ise alt sınırlı joker tür ile tanımlanmalıdır.

import java.util.Collection;

public class Collections {
  ...
  public void temizle(Collection<? super E> kopya);
  public void yükle(Collection<? extends E> kaynak);
  ...
} // IYığıt<E> arayüzünün sonu

Soysal Metotlar

Veri kapları dışında soysallıktan yararlanılan bir diğer programlama öğesi metotlardır. Genelde soysal kaplar üzerinde çalışan bu metotların soysallığı, niteleyicilerinin sonrasında kullanılan tür parametreleri yoluyla ifade edilir. Standart Veri Kapları Çerçevesi'ndeki değişik türden kaplar üzerinde uygulanabilecek metotları içeren java.util.Collections sınıfında bulunan sıralama metotlarına bakarak görelim.

package java.util;

public class Collections {
  ...
  public static <E extends Comparable<? super E>> void
    sort(List<E> liste) { ... }
  public static <E> void
    sort(List<E> liste, Comparator<? super E> karşılaştırıcı) { ... }
  ...
} // Collections sınıfının sonu

Sıralama, çok özel koşullarda kullanılabilecek bazı algoritmalar dışında, elemanların karşılaştırılması yardımıyla icra edilen bir yeniden düzenleme işlemidir. Dolayısıyla, sıralanması istenen kabın elemanlarının karşılaştırılabilir bir türe ait olması gerekir. Bu beklenti Java'da iki şekilde karşılanabilir:

Elemanların ait olduğu sınıf Comparable arayüzünü gerçekleştirir. Bu noktada, gerçekleştirme ilişkisinin doğrudan olması gerekmediği unutulmamalıdır. Genel olarak, bir nesne üyesi bulunduğu sınıfın atası olan herhangi bir sınıftaki compareTo metodu ile karşılaştırılabilir. Bu sebepten ötürü, List<E>'nin sıralanabilmesi için E'nin Comparable arayüzünü gerçekleştirmesi veya gerçekleştiren bir üstsınıfa sahip olması gerekir. Bu ise yukarıdaki imzada olduğu gibi alt sınırlı bir joker tür ile belirtilebilir.
Elemanları karşılaştırmayı bilen bir başka sınıf bu talebi karşılar. Bunun için, söz konusu sınıfın java.util paketindeki Comparator arayüzünü eleman türüne uyumlu bir şekilde gerçekleştirmesi gerekir. Tür uyumluluğu, bir önceki maddede olduğu gibi alt sınırlı joker tür ile belirtilmelidir.

Soysallık ve Diziler

İlk öğrendikleri programlama dilinin komutsal olması nedeniyle Java'da da gerekli gereksiz dizi kullanmaya alışanları soysal türler kötü bir sürprizle karşılar: dizilerin bileşen türü tür parametresi kullanılarak ifade edilemez. Örneğin, Yığıt sınıfının aşağıdaki şekilde dizi kullanacak biçimde gerçekleştirilmesi derleme hatasına neden olacaktır.

...
public class Yığıt<E> implements IYığıt<E> {
  public Yığıt() { 
    _kap = new E[]; // Derleme hatası!!!
    ...
  } // varsayılan yapıcı sonu
  ...
  private E[] _kap;
} // Yığıt<E> sınıfının sonu

Bunun sebebi, dizi ve soysal türler arasındaki temel bir farktan kaynaklanır: dizilerin tür bilgileri derleme sonrasına da taşınırken, soysal türlerin tür bilgileri derleyicinin kullanımı sonrasında silinir. Mesela, aşağıdaki kod parçasında intDz değişkeninin [ve tüm diğer Integer elemanlı dizilerin] üstnesnesi Integer[].class iken dblDz değişkeninin [ve tüm diğer Double elemanlı dizilerin] üstnesnesi Double[].class'dır. İstenecek olursa, ilişkin üstnesne (ve eleman türünün üstnesi [Integer.class ve Double.class]) kullanılarak içgörü≝ (İng., reflection, introspection) yardımıyla Integer veya Double elemanlı yeni diziler yaratılabilir. Buna karşılık, intVec ve dblVec değişkenlerinin her ikisi de aynı üstnesneye sahip olacaktır: Vector.class. Çünkü, derleme sırasında kullanılan tür bilgileri tür silme (İng., type erasure) sonunda yok olmuş ve tüm parametreli türler aynı üstnesneyle temsil edilmek zorunda kalmıştır.⁴

Integer[] intDz = new Integer[10]();
Double[] dblDz = new Double[5]();
...
Vector<Integer> intVec = new Vector<>();
Vector<Double> dblVec = new Vector<>();

Bu nedenden ötürü, dizi kullandığımız yukarıdaki gibi durumlarda, ya dizi kullanmaktan vazgeçerek soysal türlerden birine yönelmemiz ya da derleme hatası vermemekle birlikte derleyici uyarısına neden olan şu kodu tercih etmemiz gerekir. Tavsiye edilen birinci yolun seçimidir.

...
public class Yığıt<E> implements IYığıt<E> {
  public Yığıt() { 
    _kap = (E[]) new Object[]; // Derleyici uyarısı!
    ...
  } // varsayılan yapıcı sonu
  ...
  private E[] _kap;
} // Yığıt<E> sınıfının sonu

Anlatım, haklı olarak, kalıtlamanın sadece sınıflar arası geçerli bir ilişki olduğu izlenimini uyandırabilir. Fakat bu kesinlikle doğru değil; kalıtlama sınıflar arasında olduğu gibi arayüzler arasında da geçerli olan bir ilişkidir. ↑
Kod parçasında Java SE 7 ile eklenen elmas işlecinin kullanımına dikkat ediniz. Dolayısıyla, çalışma ortamını henüz güncellememiş olanlar bu kodu denediklerinde derleyici hatası ile karşılaşacaktır. Bu hatanın giderilmesi için tanımın şu şekilde tür çıkarsama olmaksızın yapılması gerekir.

IYığıt<Öğrenci> sınıf = new Yığıt<Öğrenci>();

Elmas işleci ve diğer Java SE 7 yenilikleri için buraya🔎 bakınız.↑
Bazılarınızın bunun çalışma zamanı hatasına gebe bir durum olduğunu söylediklerini duyar gibiyim. Doğru ya, ilk argüman olarak Öğrenci nesneleri tutan, ikinci argüman olaraksa Öğrenci ile alakasız Koyun sınıfının nesnelerini tutan bir kullanım düşünebiliriz. Bu durumda, metodumuzdaki contains iletisinin gerçekleştirimindeki equals çağrısı, Öğrenci nesneleri ile Koyun nesneleri karşılaştırılamayacağı için, çuvallayacak ... mıdır acaba? equals iletisinin Object sınıfında tanımlanan genel sözleşmesine baktığınızda, true döndürme koşulunun hedef nesne ile uyumlu bir türe ait argümandaki null olmayan nesnenin eşit addedilmesi olduğu, geri kalan durumlarda ise false döndürülmesi gerektiğini görürsünüz. Dolayısıyla, equals iletisinin Öğrenci sınıfındaki gerçekleştirimi hedef nesne ile uyumsuz olan bir nesne gördüğünde, kodun devamında bir hatanın oluşmasına sebebiyet vermeden false döndürmelidir. ↑
Bunun bir sonucu olarak, üstnesneden yararlanarak işini gören instanceof işleci de soysal türün ham tür halini bekler. Yani, kullanım if (nesne instanceof Yığıt) ... şeklinde olmalıdır. ↑

Hatasız Programcı Olmaz: Java'da Hata Kotarımı

2011-10-27T17:40:00.001+03:00

Yazılım gerçek dünyada var olan somut/soyut süreçlerin bilgisayar donanımı üzerinde çalıştırılan benzetimleridir. Amaç, sürecin, etkileşimde bulunulan diğer süreçler ile birlikte daha verimli ve sağlıklı bir şekilde işletilmesini sağlamaktır. Mesela, bir otomasyon yazılımı zayiatı azaltmak ve bakımı hızlandırmak suretiyle parçası olduğu üretim sürecinin daha verimli olmasını sağlayacaktır. Doğal olarak, bir yazılımın başarılı kabul edilmesindeki en önemli ölçüt, bilgisayarda oluşturulan hesaplama sürecinin benzetimi yapılmakta olan sürecin algılanışına¹ sadık kalıp kalmadığı şeklinde ifade edilebilecek doğruluk (İng., correctness) özelliğidir. Peşinden koşulması gereken bir diğer özellik, yazılımın öngörülmeyen koşullar altında da kabul edilebilir bir tepki göstermesi olarak da tanımlayabileceğimiz dayanıklılıktır (İng., robustness). Bu beklentiler yazılım sektörünün rekabete dayalı pragmatik bir dünya olması gerçeği ile birlikte ele alındığında, yazılım üreticisinin birincil görevinin düzgün bir peformansa sahip, doğru ve dayanıklı—yani, güvenilir (İng., reliable)—programların makul bir hızda geliştirilmesi olduğu söylenebilir. İşte bu yazıda, ifade edilen görev tanımındaki güvenilirlik özelliğine yönelik olarak Java programlama dili tarafından sağlanan desteğe değineceğiz.

Kötü bir haber vererek başlayalım: Java, programlarınızın doğruluğunu sağlamak bağlamında kaynak kodunuzun dilin yazım kurallarına uygunluğunu denetlemek dışında pek bir destek sağlamaz; sözdizimsel hataların ötesinde Java derleyicisinin yapacağı çok şey yoktur. Aşağıdaki örnek üzerinden ne demek istediğimizi açalım.

Faktöryel.java

import static java.lang.System.out;
...

public class Faktöryel {
  public static void main(String[] ksa) {
    byte b = Byte.parseByte(ksa[0]);
    out.println(b + "!: " + fakt(b));
    ...
  } // void main(String[]) sonu
 
  public static long fakt(byte n) {
    long çarpım = 1;
    for (byte i = 2; i <= n; i++) çarpım += i;
  
    return çarpım;
  } // long fakt(byte) sonu
  ...
} // Faktöryel sınıfının sonu

$ javac -encoding UTF-8 Faktöryel.java
$ java Faktöryel 5
5!: 15 ✘

Görüldüğü gibi, sözdizimsel bir hata bulunmamakla birlikte, faktöryel kavramının hatalı gerçekleştiriminden kaynaklanan bir mantıksal hata ortaya çıkmıştır. Derleyicinin müdahele ederek işaretli satırdaki + yerine * yazılması gerektiği yorumunu yapması olanaksızdır. Bu gibi hataların, kodun sınanması sırasında keşfedilerek programcı tarafından ortadan kaldırılması gerekir. Bir an için bunun yapıldığını ve hatanın düzeltilerek doğru bir gerçekleştirimin sağlandığını düşünelim. Bu durumda, programımızın çalıştırılması aşağıdaki sonuçları verecektir.

$ java Faktöryel 5
5!: 120 ✔
$ java Faktöryel 20
20!: 2432902008176640000 ✔
$ java Faktöryel 21
21!: -4249290049419214848 ✘

Bir ihtimal Java'daki tamsayı türlerinin taşma davranışını bilmeyenleriniz, herhangi bir sayının eksi değerli bir faktöryele sahip olduğuna şaşırabilir. Bu gruptaki arkadaşlara önerim, daha fazla ilerlemeden şu yazıya🔎 bir göz atmaları. Diğer arkadaşlar ise, bunun sebebinin çarpım sonucunun long değerler için söz konusu olan aralığa düşmemesi nedeniyle kırpılması olduğunu bileceklerdir. Peki bu durumda, faktöryel metodumuzun doğru olmadığını söyleyebilir miyiz? Faktöryelin tanımını bilen herkesin bu soruya hayır yanıtı vermesi gerekir; ortada olan şey bir hatadan çok yetersizliktir ve muhtemelen metodun kullanıcısı ile iletişim eksikliğinden kaynaklanmaktadır. Soruna değişik şekillerde çözüm getirilebilir.

Gerçekleştirime dokunulmaz ve kullanıcıya sağlanan belgelerde metodun 0 ile 20 arasındaki tamsayılar için doğru çözümler ürettiği ve dolayısıyla sağlanması beklenen argüman değerinin bu aralıkta olması gerektiği söylenir.
Duruma has bir başka çözüm sağlanarak eksiklik giderilir. Örneğimizde, dönüş türü olarak long yerine java.math.BigInteger türünün kullanılması ve kodda buna göre değişikliklerin yapılması işimizi görecektir.
Geçirilen argüman değerinin beklenen aralıkta olup olmadığı denetlenir. Bu, basit bir if komutuyla yapılabileceği gibi doğruluk savı (İng.; assertion) denetimiyle de yapılabilir. İlk yolun seçilmesi durumunda, görülen olumsuzluk dönüşte [0 gibi] özel olarak yorumlanan bir değerle belirtilebileceği gibi söz konusu durumu özetleyen bir ayrıksı durum (İng., exception(al condition)) nesnesi ile de bildirilebilir.

İkinci ve üçüncü maddelerdeki yaklaşımların nasıl gerçekleştirilebileceğini aşağıdaki alternatif çözümü izleyerek görelim. Özyinelemeli olan yeni metodumuzda, argümanın eksi olması hali, ki bu beklenilmeyen bir kullanıma işaret eder, çağırıcıya IllegalArgumentException türündeki bir ayrıksı durum nesnesi ile bildirilirken, argümanın 0 veya 1 olması halinde 1, geri kalan durumlarda ise matematikten tanıdık n * (n-1)! değeri döndürülmektedir. java.lang paketinde tanımlanan IllegalArgumentException, sağlanan argüman değerinin, -5'in faktöryelinin bulunmaya çalışılmasında olduğu gibi, uygunsuz olduğuna işaret eder.

...
import java.math.BigInteger;

public class Faktöryel {
  public static void main(String[] ksa) {
    ...
    long l = Long.parseLong(ksa[1]);
    try { out.println(l + "!: " + fakt2(l)); }
      catch(IllegalArgumentException a) {
        out.println(l + "!: " + fakt2(Math.abs(l)) + "!!!");
      }
  } // void main(String[]) sonu
  ...
  public static BigInteger fakt2(long n) {
    if (n < 0)
      throw new IllegalArgumentException(String.valueOf(n));
    if (n < 2)
      return BigInteger.ONE;
      else return BigInteger.valueOf(n)
                            .multiply(fakt2(n - 1));
  } // BigInteger fakt2(long) sonu
} // Faktöryel sınıfının sonu

$ java Faktöryel 21 21
21!: -4249290049419214848 ✘
21!: 51090942171709440000 ✔
$ java Faktöryel 5 -5
5!: 120 ✔
-5!: 120!!!

Beklenmedik koşulların oluştuğu noktada, özet bilgi içeren bir ayrıksı durum nesnesinin yaratılıp throw komutu ile fırlatılması gerekir. Bunun sonrasında, ortaya çıkan durumun çözümünü bilen birisinin duruma el atıp bir şeyler yapması beklenir. Biraz düşünüldüğünde, çözümün içine düşülen duruma sebep olanlar tarafından sağlanabileceği görülecektir. Bu ise, ayrıksı durumun ortaya çıktığı noktaya gelinene kadar izlenen çağrı zinciri üzerindeki noktalar demektir. Bir diğer deyişle, çare ya sorunun ortaya çıktığı noktada ya da o noktaya gelinmesi ile son bulan çağrı yığıtındaki diğer metotlarda bulunabilir. Çözüme dair bir şeyler yapabileceğini düşünenlerin bu iddialarını try-catch yapısı içinde bildirmeleri beklenir. try, takip eden kıvrımlı ayraç çifti arasındaki komutların sorun çıkarabileceğini bildirirken, kotarıcı olarak adlandırılan catch bloğu/blokları iliştirildikleri korumalı bölgede ortaya çıkabilecek sorunların tümü veya bazıları için çözümler sunar. Çağrı zinciri üzerindeki noktaların hiçbirinde çözüm önerilmemesi halinde ise, top denetim akışı geriye sarılarak programı başlatan JSM'ye atılacak ve JSM de ortaya çıkan durumu oluştuğu yerden başlayarak nerelere uğrayarak çözmeye çalıştığını söyleyen bir raporu standart hata ortamına² yazarak programı sonlandıracaktır. Bunun nasıl olduğuna aşağıdaki çıktıya göz atarak bir bakalım.

...
public class Faktöryel {
  public static void main(String[] ksa) {
    ...
    long l = Long.parseLong(ksa[1]);
    out.println(l + "!: " + fakt2(l));
  } // void main(String[]) sonu
  ...
  public static BigInteger fakt2(long n) {
    if (n < 0)
      throw new IllegalArgumentException(String.valueOf(n));
    ...
  } // BigInteger fakt2(long) sonu
} // Faktöryel sınıfının sonu

$ java Faktöryel 5 -5
5!: 120 ✔
Exception in thread "main" java.lang.IllegalArgumentException: -5
 at Faktöryel.fakt2(Faktöryel.java:20)
 at Faktöryel.main(Faktöryel.java:9)

JSM'ye bakılacak olursa, programın [main adına sahip] ana izleğinde Faktöryel sınıfının main metodu içinden 9. satırda aynı sınıftaki fakt2 metodu çağrılmış ve denetim akışı bu metottta iken 20. satırda IllegalArgumentException ayrıksı durumu ortaya çıkmış. Anlamadıysanız ikinci bir örnekle açıklık getirmeye çalışalım; anlayanlar da bu sayede pekiştirmiş olurlar.

import java.io.BufferedReader;
import java.io.FileReader;
import java.util.Scanner;

public class Örnek {
  public static void main(String[] ksa) {
    // ...
    m1();
    // ...
  } // void main(String[]) sonu

  private static void m1() {
    // ...
    m2();
    // ...
  } // void m1() sonu

  private static void m2() {
    String dosyaAdı;
    Scanner grdKanalı = new Scanner(System.in);
    System.out.print("Dosya adını giriniz: ");
    dosyaAdı = grdKanalı.nextLine();
    // ...
    m3(dosyaAdı);
    // ...
  } // void m2() sonu

  private static void m3(String dosyaAdı) {
    BufferedReader dosya =
      new BufferedReader(new FileReader(dosyaAdı));
    // ...
  } // void m3(String) sonu
} // Örnek sınıfının sonu

İşaretli satırlarda, argümanda geçirilen ada sahip ve o anki çalışma dizini içinde bulunan bir dosyanın tamponlanarak ve karakter yönelimli bir biçimde okunması için uygun türden bir akak nesnesi yaratılıyor. Bu işlem, sağlanan ada sahip bir dosyanın bulunmaması halinde java.io.FileNotFoundException ayrıksı durumu ile sonlanacaktır. Dolayısıyla, programın derlenip var olmayan bir dosyanın adı verilerek çalıştırılması, yukardakine benzer bir çağrı yığıtı özetinin üretilmesine neden olacaktır diye düşünebiliriz. Ancak, gelin görün ki, program derlendiğinde durumun hiç de öyle olmadığı görülür.

$ javac -encoding UTF-8 Örnek.java 
Örnek.java:29: error: unreported exception FileNotFoundException; must be caught or declared to be thrown
      new BufferedReader(new FileReader(dosyaAdı));
                         ^
1 error

Yukarıdaki çıktıdan da görülebileceği gibi, IllegalArgumentException için sesini bile çıkarmayan derleyici, iş FileNotFoundException'a geldiğinde yaygarayı basmaktadır. Çifte standardın sebebi, ayrıksı durumların iki kategoriye ayrılmasıdır:

RuntimeException köklü sınıf sıradüzeninde olanlar: Bu kategoriye giren ayrıksı durumlar, ya ortaya çıktıkları noktada yakalanıp kotarılmalı ya da çağrı yığıtındaki diğer metotlardan birinde kotarılması gerektiğini hatırlatmak için metot imzasında ilan edilmelidirler.
Diğerleri: Bu ayrıksı durumların ne yakalanması ne de, yakalanmadıkları takdirde, metot başlığında ilan edilmeleri zorunludur.

Dolayısıyla, ilk kategoriye giren FileNotFoundException ayrıksı durumunun ortaya çıkması olasılığının belirmesiyle derleyici bizim kotarmak ya da bu görevi ihale etmek yönünde bir karar verdiğimizi görmek ister. Bu istemin karşılanmaması halinde ise söz konusu eksikliğe dikkat çekerek derlemenin başarısızlıkla sonlandığını bildirir. Burada bir noktanın özellikle vurgulanması yerinde olacaktır: derleyici, kodu okuyup var olmayan bir dosyanın girileceğinden emin olduğu için değil, böyle bir olasılığın var olduğu için itiraz etmektedir. Derleyicinin gözünde, FileReader sınıfının kullanılan yapıcısı FileNotFoundException türlü bir ayrıksı durum nesnesi fırlatabilir ve programcının da buna karşı hazırlıklı olduğunu kanıtlaması gerekir.

Kotarımın sorunun çıktığı nokta yerine çağrı yığıtındaki diğer metotlara bırakıldığı metot başlığına eklenen throws bildirimi ile ilan edilir. Buna bir örnek aşağıda verilmiştir: m3'te ortaya çıkabilecek sorun öngörülmüş fakat metot içinde çözülmektense metot başlığında belirtilmek suretiyle çağrı yığıtındaki diğer metotlara bırakılmıştır. Daha kesin ifade edecek olursak, m3'te ortaya çıkabilecek sorun için top önce m2'ye ve oradan da m1'e atılmış ve hal çaresi bu metot içinde sağlanmıştır.

...
import java.io.FileNotFoundException;

public class Örnek {
  public static void main(String[] ksa) {
    // ...
    m1();
    // ...
  } // void main(String[]) sonu

  private static void m1() {
    // ...
    try { m2(); } catch(FileNotFoundException a) { ... }
    // ...
  } // void m1() sonu

  private static void m2() throws FileNotFoundException {
    ...
    // ...
    m3(dosyaAdı);
    // ...
  } // void m2() sonu

  private static void m3(String dosyaAdı)
    throws FileNotFoundException {
    BufferedReader dosya =
      new BufferedReader(new FileReader(dosyaAdı));
    // ...
  } // void m3(String) sonu
} // Örnek sınıfının sonu

Kotarıcıların iliştirildikleri korumalı bölgeye özel oldukları unutulmamalıdır. Bundan dolayı, aşağıdaki kod parçası derleyici tarafından kabul görmeyecektir; kotarıcı m2 metodunun sadece birinci kullanımına çözüm sağlamaktadır.

private static void m1() {
    // ...
    try { m2(); } catch(FileNotFoundException a) { ... }
    // ...
    m2(); // ⇒ Derleme hatası!
    // ...
  } // void m1() sonu

Bu noktada, neden iki kategori olduğunu soruyor olabilirsiniz. Aşağıdaki örnekle anlamaya çalışalım. Belli ki, bu basit programı yazan arkadaş Java'da dizilerin 0-temelli indislere sahip olduğunu unutmuş ve üç elemanlı bir int dizisi yarattıktan sonra üçüncü eleman yerine 3 indisiyle gösterilen elemanın değerini 4 olarak güncellemek istemiş. Yani, Java programlama bilgisi eksik olan arkadaş derleme zamanında yakalanamayan bir hata yapmış. Takdir edersiniz ki, böylesine bir hatanın kotarıcıda düzeltilmesi ve programa devam edilmesi olanaklı değildir. Yapılması gereken, programcı arkadaşımızın dizileri daha iyi öğrenmesi ve kullanıcıdan 0..2 aralığında değer istemesi gerektiğini farketmesidir. Çünkü, ayrıksı durum düzeneği programın beklenmedik durumlarda daha sağlıklı bir tepki vermesini sağlamak için kullanılır, kötü programcıların programlama hatalarını düzeltmesi gibi erişilmesi olanaksız bir amaç için değil.

import java.util.Scanner;

public class DiziKullanımı {
  public static void main(String[] ksa) {
    int[] iDz = {1, 2, 3};
    Scanner grdKanalı =  new Scanner(System.in);
    System.out.print("1..3 aralığında bir sayı giriniz: ");
    iDz[grdKanalı.nextInt()] = 4;
  } // void main(String[]) sonu
} // DiziKullanımı sınıfının sonu

$ javac -encoding UTF-8 DiziKullanımı.java
$ java DiziKullanımı
1..3 aralığında bir sayı giriniz: 3
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 3
 at DiziKullanımı.main(DiziKullanımı.java:8)

Benzer bir gözlem null değerli bir tutacak yoluyla ileti gönderilmeye çalışılması sonrasında ortaya çıkan NullPointerException için de yapılabilir. Sıkça kendini gösteren bu ayrıksı durumun da sebebi programlama hatasıdır ve kotarılması olanaksızdır. Dolayısıyla, yakalanması veya metot başlığında ilan edilmesi pek anlamlı olmayacaktır.³ Buna karşılık, bir dosyanın olmaması kullanıcının dosya adını giren kullanıcının dikkatsizliğinden kaynaklanabilir. Doğal olarak, bu beklenmedik durumun öngörülerek kotarıcıda ikinci bir hak verilerek programın boş yere sona ermesinin önüne geçilmelidir.

Peki, ya sizin ve kullanıcının iradesi dışında gelişen sebepler nedeniyle programınız göçecek olursa. Mesela, arkadaşınız ortaklaşa kullandığınız bilgisayardan programınızın çalışması için gerekli olan bir sınıf dosyasını silecek olursa, ne olur? Ya da, dosyanın diskte kaydedildiği sektörlerden birinin bozulması nedeniyle sınıf dosyasının okunarak içselleştirilmesi söz konusu olamazsa, ne olur? Ya da ya da, programınızın işlemesi için gereksinilen kaynaklar JSM tarafından sağlanamayacak kadar büyük olmaya başlarsa, ne olur? Gelin bu soruların yanıtını Faktöryel sınıfını ikinci komut satırı argümanı çok büyük bir sayı ile deneyerek birlikte görelim.

$ java Faktöryel 5 5827 2> StackOverflowError.txt
5!: 120 ✔

Standart hata ortamını yönlendirerek hata mesajlarını StackOverflowError.txt dosyasına gönderen yukarıdaki komutun ürettiği bilgi incelendiğinde, fakt2'nin sürekli kendini çağırdığı ve programın StackOverflowError ile sonlandığı görülecektir. Yani, JSM özyinelemeli çağrılar sonucu genişleyen çağrı yığıtını doldurmuş ve taşmanın vuku bulduğu noktada imdat çağrısını yapmıştır. Bu hatanın ortaya çıkışı, JSM'nin yararlandığı yığıt büyüklüğünü -Xss512k veya -Xss1m gibi bir opsiyonla büyüterek ertelenebilir. Ancak; işin özünde çaresiz olan JSM'dir ve belleğin bittiği yerde o da bir şey yapamayacaktır. Bir diğer deyişle, beklenmedik durum dış kaynaklıdır ve programcının yapacağı fazla bir şey yoktur. Örneğimizde, özyinelemeli çözümü for döngülüsüyle değiştirerek belki bir şeyler yapabiliriz ama bu her zaman mümkün olmayacaktır. İş böyle olunca, kotarımdan söz etmek de mantıksızdır.

Bu ana kadarki bilgilerimizi maddeleyerek özetleyecek olursak aşağıdaki listeyi elde ederiz. Java programları, iç ve dış koşullara göre beklenenden farklı bir şekilde davranabilir. Davranış sapması programcının müdahele edemeyeceği dış kaynaklardan ötürüyse, programcı Error köklü sıradüzenindeki sınıflardan birisinin nesnesi ile haberdar edilir. Yok eğer oluşan durum içselse ve programcı tarafından çözüm bulunabilecek gibi gözüküyorsa, programcının ihtiyacının duyduğu bilgi RuntimeException köklü sıradüzenindeki sınıflardan birisinin nesnesi ile sağlanır. Aksi takdirde, programcının yaptığı mantıksal bir hata dönüşerek ayrıksı durum haline gelmiştir ve bu, programcının dersini tamamlaması için, Exception köklü sıradüzenindeki diğer sınıfların nesneleri ile haber verilmelidir.

Throwable: Hata ve ayrıksı durumlar

Error: JSM'nin göçmesine neden olan hatalar

Exception: Ayrıksı durumlar

RuntimeException ve altsınıfları: Kotarılması zorunlu olmayanlar
Kotarılması zorunlu olanlar

Hangi kategoriye giriyor olursa olsun, programcı tüm koşullar altında elinden gelenin en iyisini sergilemelidir. Mümkünse, kotarıcıdaki kod ile programın sağlıklı bir şekilde devamı sağlanmalı, bu mümkün olmuyorsa, nasıl olsa bir şey yapamıyorum, denilerek oturmaktansa programın zarif bir şekilde bitmesi için elden gelen yapılmalıdır. Mesela, kullanılmakta olan dış kaynaklar kotarıcıda döndürülmeli, programın bakıcısının muhtemel bir programlama hatasını bulmasını kolaylaştırmak adına bir seyir defterine neden ile ilgili bilgiler not düşülmelidir. Bu noktada karşımıza, ayrıksı durum oluşsa da oluşmasa da çalıştırılacak kodu içeren bir kotarıcı olarak finally çıkıyor. Bir örnek ile görelim.

public void m() {
  ...
  try {
    FileReader dosya = new FileReader(...);
    ... 
  } catch (java.io.IOException a) { ... }
    catch (ADurumu a) { return; }
    ...
    catch (Exception a) { ... }
    finally { dosya.close(); ... }
  ...
} // void m() sonu

Birden çok kotarıcıya sahip yukarıdaki kod parçasında, try bloğunun işlenmesi sırasında oluşacak duruma göre farklı kotarıcılar devreye girebilir ya da işler yolunda giderse denetim akışı finally sonrasındaki komutla devam eder. Ancak, ne olursa olsun, finally kotarıcısı herhalükâda işlenecektir. Bu, başka hiçbir şey yapmadan çağırıcıya dönen ADurumu ayrıksı durumu için de geçerlidir; çünkü metottan dönüş öncesinde işlenmemiş finally kotarıcıları sırayla işlenir. Dolayısıyla, ortaya çıkan ayrıksı durum nedeniyle işlenen kotarıcıda metottan dönülse bile kapatılamamış olan dosya muhakkak kapatılacaktır.

Kod parçasında dikkat çekilmesi gereken bir diğer nokta, kotarıcıların yerleştiriliş sırasının önemli olduğudur. Bir kotarıcı sadece argümanındaki sınıfa ait nesneleri değil, o sınıfın kökü olduğu sıradüzeni içindeki tüm sınıfların nesnelerini yakalar. Örneğin, yukarıdaki ilk kotarıcı IOException nesnelerini yakaladığı gibi, FileNotFoundException'ın da içinde bulunduğu pek çok sayıda sınıfın nesnelerini de yakalayacaktır. Benzer şekilde, Exception argümanlı kotarıcı, kendisinden önce geçen kotarıcılarda yakalanmayan tüm ayrıksı durum nesnelerini yakalayarak amansız—bir o kadar da anlamsız—bir gümrük memuru görevini görecektir. Böylesine bir kotarıcının başa konulması—genelde, bir üstsınıf türlü argümana sahip kotarıcının altsınıf türlü argümana sahip kotarıcıdan önce gelmesi—her şeyi yakaladığı için takip eden kotarıcıları anlamsız kılacaktır. Kotarıcıların, özelden genele olacak şekilde sıralanması gerekir.

Evet, geldik kendi ayrıksı durumunu kendin pişirmeye. Ama, yazımızın vardığı uzunluğu ve muhtemel konsantrasyon azalmasını düşünerek bunu bir başka yazıya bırakalım. Onun için, şimdilik bu kadar. Unutmayın, hatasız program(cı) olmaz; birazcık defansif programlama ortaya çıkabilecek zararın faturasını azaltır. Onun için sadece doğruluk değil, dayanıklılığa da önem verin. Yani, güvenilir yazılım üretin.

Yazılımın benzetimi yapılan sürecin geliştiriciler (alan uzmanı, gereksinim toplayıcı, mimar, tasarımcı ve gerçekleştirimci) tarafından yorumlanması ile ortaya çıktığı unutulumamalıdır. Dolayısıyla, doğruluk özelliğini sürecin algılanışına göre yapmak daha doğru olur. ↑
Standart hata ortamı, bir programın işleyişi sırasında üretilen hata mesajlarının gönderildiği aygıttır ve yeniden yönlendirme yapılmadığı veya System.setErr metodu kullanılarak değiştirilmediği müddetçe standart çıktının da gönderildiği varsayılan aygıt olan ekrandır. ↑
Yapılan ayrımın bir diğer olumlu yanı, programların fazladan try-catch yapıları ve throws bildirimleri ile doldurulmamasıdır. Örnek olarak verdiğimiz iki ayrıksı durum düşünüldüğünde—tüm dizi erişimi ve ileti gönderimlerinin try-catch yapısı içine alındığını veya bu işlemleri içeren metotların imzasına ayrıksı durum ilanının eklendiğini düşünün—kotarımın zorunlu olmamasının kaynak kodun okunabilirliğine yaptığı katkı takdir edilecektir. ↑

Java Platformunun Dikkate Değer Bir Dili: Scala-2

2011-10-14T01:44:00.001+03:00

İlk yazı

Scala üzerine ikinci yazımızda bu JSM dilinin sağladığı sınıf tanımlama imkânına daha yakından bakacağız ve bunu yaparken de Java ile olan farklılıklara değinmeye çalışacağız.¹ Matematikteki kesirli sayı kavramını soyutlayan aşağıdaki sınıf iskeletiyle başlayalım.²

Kesir.scala

package com.ta.matematik
...
class Kesir(pay: Long = 1, payda: Long = 1) {
  require(payda != 0)
  private var (_pay, _payda) = (pay, payda)
  sadeleştir()
  ...
  private def sadeleştir() = { ... }
} // Kesir sınıfının sonu

Java'dan gelenlerin gözüne çarpacak farklılıklardan belki de ilki, public niteleyicisinin sırra kadem basmış olması. Bu durumun sebebi, paket çapında erişimin varsayıldığı Java'dan farklı olarak, Scala'da programlama öğelerinin nitelenmemeleri halinde public erişime sahip kılınmasıdır. Dolayısıyla, Kesir ve erişim niteleyicisi bulunmayan tüm sınıf öğeleri herkes tarafından kullanılabilecektir. Bunun uygun olmaması halinde, programcının niyetini protected veya private niteleyicilerinden birini kullanarak bildirmesi gerekir. Bu noktada, protected niteleyicisinin paket içindeki türleri kapsamayıp, söz konusu öğeyi sadece o anki türden doğrudan veya dolaylı bir biçimde kalıtlayan türlere erişilebilir kıldığını söylemekte yarar vardır.³ Ayrıca, paket çapında erişimden de bahsedilmediği dikkatinizi çekmiştir. Ancak, telaşa düşmeyin; nitelenmekte olan öğeyi içeren paket, sınıf veya tek-örnekli sınıf adlarından birinin protected veya private ile birlikte belirtilerek daha rafine erişim politikalarının ifade edilmesi mümkündür. Örneğin, private yerine private[com.ta.matematik] nitelemesinin yapılması, sadeleştir adlı metodu sınıfa özel olmaktan çıkaracak ve com.ta.matematik paketindeki tüm öğelere görünür kılacaktır.

Java'dan gelenleri başlarda şaşırtabilecek bir diğer nokta, nesnenin yaratılması esnasında yapıcıya geçirilmesi beklenen argümanların özelliklerini belirten parametre listesinin sınıf adı sonrasında bulunmasıdır. Buna göre, Kesir sınıfının örneği ks1 = new Kesir(6, 10) şeklinde yaratılabilecektir. İlkleme ise Kesir sınıfının tanımındaki metotların dışında kalan tüm öğelerin koddaki geçiş sırasında işlenmesiyle yapılacaktır. Yani, sınıf gövdesindeki söz konusu öğeler nesne ilkleme bloğu görevini görecektir; Scala terminolojisiyle konuşacak olursak, sınıf gövdesindeki öğeler birincil yapıcı olarak ele alınacaktır. Örneğimiz üzerinden gidecek olursak; Predef adlı tek örnekli sınıftan ithal edilen require metodu ile geçirilen paydanın uygunluk denetiminin yapılmasını takiben, yaratılmakta olan nesnenin altalanları olan _pay ve _payda koşut bir biçimde pay ve payda ile ilklendikten sonra yaratılmakta olan kesir sadeleştirilecektir. Bu noktada, koşut atamanın tüm kollarının aynı anda işleniyormuş gibi düşünülmesi gerektiği unutulmamalıdır.

Haklı olarak, Predef sınıfının nereden çıktığını sorabilirsiniz. Yanıtı, Scala derleyicisinin, Java derleyicisinin java.lang paketini otomatikman ithal edilmiş kabul etmesindeki gibi, java.lang ve scala paketleriyle scala.Predef tek örneklisini otomatikman tüm programlara ithal etmesinde yatar. Bunun sonucunda, Predef tanımı da evrensel olarak görünür hale gelecek ve bazı işlemler öncesinde önkoşul denetimine yarayan require metodu da yukarıdaki gibi kullanılabilecektir.

Bir diğer farklılık, Java'da aynı adlı metotların ezilmesi ile öykünülen varsayılan argümanların kullanımı. Scala 2.8'den başlayarak geçerli olan bu özellik sayesinde, varsayılan değerin uygun olması durumunda, argümanın es geçilmesi de olanaklıdır. Örneğin, yukarıdaki sınıf tanımının geçerli olduğu bir ortamda, tamsayı = new Kesir(7) ve bir = new Kesir(), sırasıyla, 7/1 ve 1/1 değerlerini temsil eden kesirli sayıları yaratacaktır. Bu noktada, varsayılan argümanların metot imzasının sonunda yer alması zorunluluğu unutulmamalıdır. Dolayısıyla, 1/7 kesrini temsil eden nesnenin yaratılması için her iki argümanın da geçirilmesi gerekecektir.

Scala 2.8 ile birlikte, ileti gönderileri ve metot çağrıları sırasında argümanların parametre adları kullanılarak konumlarından farklı bir sırada geçirilmesi de olanaklı kılınmıştır. Buna göre, önceki paragraflardaki ks ve tamsayı tanımlayıcılarının, sırasıyla, new Kesir(payda = 5, pay= 3) ve new Kesir(pay= 7) şeklinde tanımlanması mümkün olacaktır. Bu sayede, birBölüYedi = new Kesir(payda = 7) tanımlamasının da geçerli olması sağlanarak 1/7 kesrine karşılık gelen nesnenin tek argüman geçirilerek yaratılması da mümkün olmaktadır.

Yukarıdaki örnekte varsayılan argümanlar yardımıyla sağlanan değişik sayıda argümanlarla kullanılabilen yapıcı metotlar görüntüsü, yardımcı yapıcı metotlar yoluyla da sağlanabilir. Varsayılan argümanlarla birlikte de yararlanılabilecek bu yaklaşımda, programcı ilk iş olarak uygun argümanlarla birincil yapıcıyı veya diğer yardımcı yapıcılardan birini çağıran this adına sahip metotlar yazar. Örneğin, aşağıdaki kod parçasında iki argümanın da sağlanması durumunda birincil yapıcı çağrılırken, bir veya sıfır argümanın sağlanması halinde, sırasıyla, 7. ve 8. satırlardaki yardımcı yapıcılar çağrılacaktır. Dikkat ederseniz, her iki yapıcı da işini bir diğer yapıcıya havale ederek görmekte.

...
class Kesir(private var _pay: Long,
            private var _payda: Long) {
  require(_payda != 0)
  sadeleştir()
  ...
  def this(_pay: Long) = this(_pay, 1)
  def this() = this(1)

  def pay = _pay
  def payda = _payda
  ...
  override def toString() = _pay + "/" + _payda
  ...
} // Kesir sınıfının sonu

Birincil yapıcının parametre listesindeki değişiklik de gözünüze çarpmıştır, Tanımının önüne var niteleyicisinin konulmasıyla ilişkin parametrenin değişken içeriğe sahip kılınması nedeniyle, daha önceki kod parçasında olduğu gibi yapıcıya geçirilen argümanların değişken içerikli altalanları ilklemesi ve değişikliklerin bu altalanlarda yapılması artık gerekli değildir. Ancak, birincil yapıcıya özel bu durum, Scala'nın atıf geçirme (İng., pass by reference) yöntemini desteklediği şeklinde yorumlanmamalıdır; Java'da olduğu gibi, Scala'da da argümanlar ilişkin metoda değer geçirme (İng., pass by value) yöntemiyle sağlanır.

Java'dan tanıdık gelecek bir nokta, üstsınıflardan kalıtlanan bir metodun ezilmekte olduğunu bildiren override niteleyicisidir. Ancak, Java dengi @Override açımlamasının kullanımı seçimli olup sadece tavsiye edilirken, Scala'daki bu niteleyicinin kullanımı aynı imzaya sahip metotların varlığında zorunludur. Bu kurala uyulmaması, derleyicinin hata mesajıyla karşılanacaktır.

toString'i bir yerlerden gözünüzün ısırdığını düşünüyorsanız, belleğinizin sizi aldatmadığını söyleyebilirim; Java'dan bildiğimiz bu ileti, Scala'da da hoş yazım amacıyla kullanılıyor. Tıpkı Java'da olduğu gibi, programcıların belli bir türe ait değerlerin hoş yazımı için kök sınıf tarafından sağlanan ilişkin metot gerçekleştirimini ezmesi gerekiyor. Ancak, toString'in Scala tür sıradüzeni içinde nereden nasıl kalıtlandığını daha iyi anlamak için, Java'da olmayan bir üstkavramın tanıtılmasında yarar var: çeşni (İng., mixin). Kaynak kodda trait anahtar sözcüğüyle karşılık bulan bu programlama kavramının anlaşılması, Java ve Scala türleri arasındaki etkileşimi daha iyi kavramak için de yardımcı olacaktır. O zaman, karşılaştırılabilirlik kategorisini tanımlayan scala.math.Ordered çeşnisinin Scala'nın resmi sitesindeki gerçekleştirimine ve Kesir sınıfına söz konusu çeşninin nasıl katıldığına göz atarak bu üstkavramı anlamaya çalışalım.

Soysal olan Ordered çeşnisi, başlığındaki kalıtlama ilişkisinden de görülebileceği gibi, Java platformundaki karşılaştırılabilir nesnelerin kategorisini tanımlayan Comparable arayüzünden kalıtlar. Scala türlerinin Java'dakileri geliştirebileceğine örnek oluşturan bu başlığın anlamı, işini compare metoduna havale ederek gören compareTo metodu gerçekleştiriminden de gözlemlenebilir. Böylece, Scala'da yazılan bir sınıfın nesneleri Java programları içinden de kullanılabilecektir.

Ordered.scala

package scala.math

trait Ordered[A] extends java.lang.Comparable[A] {
  def compare(sağ: A): Int
  def <(sağ: A): Boolean = (this compare sağ) <  0
  def >(sağ: A): Boolean = (this compare sağ) >  0
  def <=(sağ: A): Boolean = (this compare sağ) <= 0
  def >=(sağ: A): Boolean = (this compare sağ) >= 0
  def compareTo(sağ: A): Int = compare(sağ)
} // Ordered[A] çeşnisinin sonu

object Ordered { 
  implicit def orderingToOrdered[T](x: T)
    (implicit ord: Ordering[T]): Ordered[T] = 
    new Ordered[T] {
      def compare(sağ: T): Int = ord.compare(x, sağ)
    }
} // Ordered tek-örneklisinin sonu

Ordered çeşnisinin gövdesine baktığımızda, tanımlanan kategorideki iki Scala nesnesinin—ileti alıcı (this) ve sağ—karşılaştırılma sonucunu döndüren compare metodunun gövdesi verilmeden sağlandığını görüyoruz. Bu durum, Scala derleyicisi tarafından söz konusu metodun soyut olarak ele alınacağı anlamını taşır; derleyicinin yaptığı bu varsayım yüzünden programcının ayrıca çeşniyi veya metodu soyut olarak nitelemesine gerek yoktur.

Yukarıdaki kod parçasının ortaya koyduğu bir diğer önemli nokta, Scala'nın, Java'nın aksine, işleçlerin aşırı yüklenmesini—ya da, işin doğrusunu söylemek gerekirse, bu tür bir yanılsamayı yaratabilecek özellikleri—desteklediğidir. Öncelikle, tanımlayıcı adlarının oluşturulmasında kullanılan karakterler kullanageldiğimiz işleçlerin simgelerini de kapsayan daha geniş bir yelpazeden seçilebilir.⁴ Ayrıca, tek argüman alan iletiler işleç ortada sözdizimiyle de kullanılabilir. Örneğin +, topla veya add kadar geçerli bir tanımlayıcı adıdır. İsteyecek olursak, değişken/sabit veya ileti/metot adlarını topla veya add yerine + olarak da seçebiliriz. Aynı zamanda, adı ne şekilde verilmiş olursa olsun, tek argüman alan iletileri, alıcı.ileti(arg) yerine alıcı ileti arg şeklinde de gönderebiliriz. Dolayısıyla, yukarıdaki this compare sağ ifadesi this.compare(sağ) ile eşdeğerdir.

Kod parçamızda dikkat çeken bir diğer bölüm, tek-örneklimizin tanımında geçen implicit anahtar sözcüğüdür. Bu sözcük, söz konusu metodun, programcının açıkça kullanması dışında kimi zaman arka planda derleyicinin sentezlediği kod tarafından da çağrılabileceğini belirtir. Örneğimizde olduğu gibi dönüşüm amacıyla kullanılan bu tür metotlar, nesne tutacağını argüman türünden (Ordering) eşlik eden türe (Ordered) çevirir. Mesela, Ordering çeşnisi tutacağıyla bir nesneye ileti gönderilmesi ve bu iletinin geçerli olmadığının anlaşılması durumunda, derleyici yukarıdaki ve benzeri metotlardan birini usulca kullanarak nesneyi başka bir açıdan görecek ve program hata vermeden devam edecektir.

Tanımlanmış bir çeşni, bir diğer çeşni tarafından kalıtlanmak suretiyle geliştirilebileceği gibi, içerdiği soyut öğelerin sağlanması ve/veya bazı öğelerinin ezilmesi yoluyla bir sınıfa katılabilir. Her iki durum da extends seçilmiş sözcüğü ile ifade edilir. Ancak; sınıfın bir başka sınıftan kalıtlaması halinde, extends üstsınıfı belirtmek için kullanılırken, sınıfa katılan çeşniler with anahtar sözcüğü ile belirtilir. Çeşniler arası kalıtlama ilişkisinin çoklu olmasının yanısıra, bir sınıf birden çok çeşniyi gerçekleştirebilir.

Ordered çeşnisinin Kesir sınıfı tarafından gerçekleştirilmesi aşağıda verilmiştir. Bu tanıma göre, yaratılacak Kesir ve Kesir'den kalıtlayan tüm sınıfların nesneleri karşılaştırılabilir nesneler kategorisine gireceklerdir. Bu özellik, Ordered çeşnisinin Comparable'dan kalıtlaması nedeniyle, söz konusu nesnelerin sadece Scala programlarında kullanılmaları halinde değil, Java ve diğer Java platformu dillerinde yazılmış programlar içinden kullanılmalarında da geçerli olacaktır. Mesela, Kesir nesneleri ile doldurulmuş bir liste java.util paketindeki Collections.sort metodu ile sıralanabildiği gibi, scala.collection.immutable.List sınıfının sort metoduyla da sıralanabilir.

...
import scala.math

class Kesir extends Ordered[Kesir] {
  ...
  def equals(sağ: Kesir) = compare(sağ) == 0
  
  def compare(sağ:Kesir) = {
    val fark = this - sağ
    if (fark._pay < 0) -1
    else if (fark._pay > 0) 1
      else 0
  } // compare(Kesir): Int sonu
  ...
  def -(sağ: Kesir): Kesir = {
    val pay = _pay * sağ._payda - _payda * sağ._pay

    new Kesir(pay, _payda * sağ._payda).sadeleştir()
  } // -(Kesir): Kesir sonu
  ...
} // Kesir sınıfının sonu

Kesir sınıfındaki equals metodunun Ordered çeşnisindeki compare ile uyumlu olacak şekilde ezilerek gerçekleştirildiği gözünüze çarpmıştır. Sakın ola ki, Java'yı iyi bilen biri olarak, bunun eşitlik denetimi işlecini (==) etkilemeyeceğini düşünmeyin. Çünkü, Scala'da equals ile == her zaman aynı şekilde çalışır: kök sınıftaki equals gerçekleştiriminin bir sınıf tarafından ezilmesi == işlecinin de anlamını değiştirir. Eşitlik denetimine ek olarak aynılık denetimi isteyenlerin, eq ve onun değillemesi olan ne iletilerini kullanması tavsiye edilir.

Bir sınıfa çeşni katılması nesnenin yaratıldığı noktada, dinamik olarak da gerçekleştirilebilir. Örnek olarak, KesirEksik sınıfının Ordered çeşnisi katılmadan tanımlanmış olduğunu varsayalım. Bu takdirde, aşağıdaki kod parçasından da görebileceğiniz gibi, bu sınıfa ait [1/11 değerine sahip] bir nesne Java'daki adsız sınıflara benzer bir tanımla söz konusu çeşniye sahip kılınabilir.

val ks =
  new KesirEksik(3, 33) with Ordered[KesirEksik] {
    def compare(sağ: KesirEksik) = {
      val fark = this - sağ
      if (fark.pay < 0) -1
      else if (fark.pay > 0) 1
        else 0
    } // compare(KesirEksik): Int sonu
  
    def equals(sağ: KesirEksik) = compare(sağ) == 0
  } // Kesir'i geliştiren adsız sınıfın sonu

toString'in soy ağacını öğrenmek için yola çıkmıştık, şimdi equals ve arkadaşlarının da katılımı ile iş daha da karıştı, değil mi? Üzülmeyin, aşağıdaki kısmi tür sıradüzeninin açıklanması her şeyi yoluna koyacaktır. [Yatık yazılı türler çeşnileri, diğerleri ise sınıfları temsil ediyor.]

Any

AnyRef ≡ java.lang.Object

... // Java'dan ithal ediilen bileşke türler
ScalaObject

... // Scala'da tanımlanan bileşke türler

AnyVal

Boolean + scala.runtime.RichBoolean
Byte + scala.runtime.RichByte
...
Unit

Java'daki bileşke tür ve ilkel tür ayrımı Scala'da bire bir karşılık bulmaz; ilkel türlerin ele alınışını C# diline benzeterek anlamak daha kolay olacaktır. Çünkü, arka planda işlemcinin desteklediği türlerden birine eşleştirilerek işlenen bu çeşit değerler, kaynak kod düzeyinde kalıtlanarak geliştirilemeyen—yani final—özel sınıfların nesneleri gibi ele alınır. Dolayısıyla, ilkel türden değerler de ileti alıcı konumunda kullanılabilir. Bunu akılda tutarak yukarıda verilen sıradüzenini açalım. Öncelikle, ister ilkel olsun isterse bileşke, tüm türlerin kökü ==, !=, equals, toString ve diğer temel iletileri içeren Any sınıfına gider. Scala nesnesi olduğunun anlaşılması için ScalaObject adlı bir gösterge çeşninin katıldığı bileşke türlü değerler, java.lang.Object'tekilere ek olarak eq ve ne gibi Scala nesnelerine özel iletiler içeren AnyRef sınıfında belirlenen sözleşmeye göre davranırlar. İlkel türlü değerler ise, ilişkin sınıfları işaretlemek için kullanılan AnyVal çeşnisi katılmış sınıflara aittir. Buna ek olarak, Predef tek-örneklisinde yapılan dönüşümler sayesinde, tüm ilkel tür değerler daha zengin bir arayüze sahipmiş gibi görünebilirler. Örnek olarak, 1'den 10'a tüm tamsayıları standart çıktıya yazan for (i <- 1 to 10) System.out.println(i) komutunun perde arkasına bir göz atalım. Unuttuysanız hatırlatalım, tek argümanlı ileti gönderileri işleç ortada sözdizimiyle de yazılabilir. Dolayısıyla, ileti alıcıdan başlayarak argümanındaki değere kadar olan tamsayıları içeren bir dilim döndüren to iletisini dönüştürerek döngümüzü for (i <- 1.to(10)) System.out.println(i) şeklinde yazmak da aynı işi görecektir. Yani, Int türlü 1'e to iletisi gönderilecek ve döndürülen dilim nesnesi gezilerek döngü işlenecektir. Ne var ki, Int sınıfının arayüzüne bakıldığında, to adında bir iletinin olmadığı görülecektir. O zaman, nasıl oluyor da Scala derleyicisi böyle bir durumda itiraz etmeden yukarıda anlatılan şeyi yapıyor? Bu sorunun yanıtı, Predef tek-örneklisinde sağlanan dönüştürücü metodun örtük çağrısında (İng., implicit call) yatıyor: derleyici, iletinin desteklenmediğini görmesinin ardından Int türlü hedef nesneyi scala.runtime.RichInt nesnesine çeviriyor ve iletiyi bu nesneye gönderiyor. Bir diğer deyişle, Int sınıfındaki işlevsellik RichInt sınıfında sağlanan işlevsellikle zenginleştiriliyor.

Bu haliyle çeşnilerin soyut sınıflardan çok da farklı olmadığını düşünebilirsiniz: tıpkı soyut sınıflarda olduğu gibi, çeşniler altalan tanımlarının yanısıra iletiler ve bu iletilerin bazıları veya tümü için gerçekleştirimler içerebilir. Buna karşılık, çeşniler yardımcı yapıcılara sahip olamaz; ek olarak, birincil yapıcılar argüman alamadığı gibi kalıtladıkları türlerin yapıcılarına argüman geçiremez. Ayrıca, (soyut) sınıflar için tekli kalıtlama geçerliyken çeşniler birden çok çeşniden kalıtlayabilir. Bundan dolayı bazılarınız, önceki paragraflardaki kategori sözcüğünün kullanımının da katkısıyla, çeşnilerin biraz da arayüzlere benzediğini düşünebilir. İki grubun da bir yere kadar haklı olduğu söylenebilir. Kimin haklı olduğunu ilan etmeden önce, Scala derleyicisinin çoklu sınıf kalıtlamanın desteklenmediği JSM üzerinde nasıl olur da soyut sınıf özellikleri sergileyen çeşnilerin çoklu kalıtımını olduruyor, ona bir bakalım. Bunun için sınıf dosyalarını tanımlanan türün üyelerini listeleyerek tersine bütünleştiren javap komutunu ve Scala derleyicisinin bir opsiyonunu kullanacağız.

Çeşni.scala

trait Çeşni { def ileti() { println("iletide ...") } }

$ scalac Çeşni.scala
$ ls Çeşni*.class
Çeşni.class Çeşni$class.class
$ javap Çeşni
Compiled from Çeşni.scala
public interface Çeşni extends scala.ScalaObject {
  public abstract void ileti();
}

Çeşni.class dosyasının incelenme sonucu, tercihini arayüzden yana kullananları haklı çıkarmış gibi gözüküyor; javap komutunun çıktısına göre, tanımlamakta olduğumuz iletinin imzası arayüze aynen taşınmış. Ancak, doğal olarak, arayüzlerin gerçekleştirim ayrıntısı içerememesi nedeniyle, metot gövdesi uçup gidivermiş. Bu sihirbazlığa açıklık getirilmesi gerekli. İşte bu noktada, Scala derleyicisine geçirilecek print opsiyonu yardım çağrımıza yanıt verecektir.

$ scalac -print Çeşni.scala
[[syntax trees at end of cleanup]]// Scala source: Çeşni.scala
package <empty> {
  abstract trait Çeşni extends java.lang.Object with ScalaObject {
    def ileti(): Unit
  };
  abstract trait Çeşni$class extends  {
    def ileti($this: Çeşni): Unit = scala.this.Predef.println("ileti içinde ...");
    def /*Çeşni$class*/$init$($this: Çeşni): Unit = {
      ()
    }
  }
}

Görünen o ki, metot gövdesi yukarıda yaptığımız sorgu sonrasında listelenen ikinci dosyaya, Çeşni$class.class, taşınmış. Yani, ortada kaybolup giden bir şey yok. Ama,çeşnimizin dönüşümünü Scala üstkavramları cinsinden veren bu çıktıda açıklama getirilmesi gereken bir nokta var: Çeşni$class çeşnisi, Java'ya nasıl çevrilecek? Çok bekletmeden yanıtını verelim: soyut sınıf olarak. Her şeyi bir arada gösteren aşağıdaki kod üzerinden anlamaya çalışalım.

trait Çeşni { def ileti() = println("ileti içinde...") }

⇓ Scala → Java

public interface Çeşni { public abstract void ileti(); }

public abstract class Çeşni$class {
  static void ileti1(Çeşni $this) = { ... }
  ...
}

class ÇeşniciBaşı extends Çeşni { ... }

⇓ Scala → Java

public class ÇeşniciBaşı implements Çeşni {
  ...
  void ileti() { Çeşni$class.ileti(this) }
  ...
}

Özetleyecek olursak; çeşni tanımının sözleşmesi bir arayüze, gerçekleştirim ayrıntıları ise bir soyut sınıfa konulur; çeşninin katıldığı sınıfta ise çeşninin arayüzündeki iletilere karşılık gelen metotlar, işlerini soyut sınıftaki gerçekleştirime havale ederek görürler.

Dikkatinizi çekeceğimiz son nokta, çeşni katılmış bir sınıfın nesnesine gönderilen iletilerin işlemesi sırasında super anahtar sözcüğünün anlamını ilgilendiriyor. Tekli sınıf kalıtlamanın geçerli olduğu ve arayüzlerin gerçekleştirim ayrıntısı içermediği Java'da üstsınıftaki yapıcı veya diğer metotlara atıfta bulunmak için kullanılan bu sözcük, çoklu çeşni kalıtlama, bir sınıfa birden çok çeşni katılabilmesi ve çeşnilerin gerçekleştirim ayrıntısı içermesi nedeniyle Scala'da anlaşılması daha zor bir anlama sahiptir. Programming in Scala kitabındaki örnek ile anlamaya çalışalım.

class Hayvan
trait Tüylü extends Hayvan
trait Bacaklı extends Hayvan
trait DörtBacaklı extends Bacaklı
class Kedi extends Hayvan with Tüylü with DörtBacaklı

super çağrılarının etkisini anlamak için, Scala'nın sıradüzenindeki türleri nasıl sıraya dizdiğini anlamak gerekir. Doğrusallaştırma adı verilen bu işlemin üç temel kuralı vardır:

Bir sınıf üstsınıfları ve katılan çeşnilerinin öncesinde doğrusallaştırılır.
Doğrusallaştırılmada daha önceden geçmiş bir tür bir daha sıraya konmaz.
Bir sınıfın üstsınıfı ve birden çok çeşnisi olması durumunda, ilk olarak en son katılan çeşni doğrusallaştırılır.

Anlamanızı kolaylaştırmak için yalın bir tanımı olan Hayvan sınıfından başlayalım. Birinci madde gereği, doğrusallaştırma sonucu türler Hayvan, AnyRef, Any şeklinde sıralanacaktır. Yani, Hayvan sınıfının içinde geçen bir super çağrısı, AnyRef sınıfı içindeki ilişkin metoda atıfta bulunacaktır. Hayvan'ı geliştiren Tüylü çeşnisinin doğrusallaştırılması ise, kendisi ve Hayvan'ın doğrusallaştırılması ile elde edilen Tüylü, Hayvan, AnyRef, Any sırasını verecektir. Bacaklı ve DörtBacaklı için de benzer bir şekilde oluşturulan sıralama, sırasıyla, Bacaklı, Hayvan, AnyRef, Any ve DörtBacaklı, Bacaklı, Hayvan, AnyRef, Any olarak bulunacaktır. Hayvan sınıfına doğrudan ve Tüylü ve DörtBacaklı çeşnileri üzerinden olmak üzere üç değişik yoldan ulaşan Kedi sınıfı, ikinci ve üçüncü maddeler akılda bulundurularak doğrusallaştırılmalıdır. Yani, istediğimiz sıra Kedi sınıfının DörtBacaklı, Tüylü ve Hayvan'ın doğrusallaştırılması ile birleştirilmesi sonucunda bulunacaktır. DörtBacaklı'nın doğrusallaştırılması ile elde edilen sıranın öteki türlerin sıralamasındaki tüm türleri içermesi nedeniyle, sonuç Kedi, DörtBacaklı, Bacaklı, Tüylü, Hayvan, AnyRef, Any olarak ortaya çıkacaktır. Bu sıra, zincirleme super çağrılarının bulunduğu bir kodda bize denetim akışının izleyeceği yolu verir.

İlk yazı

Değinilecek farklılıklardan çoğunun kaynak kodu kısaltıp okumayı kolaylaştırdığına ve alana özel diller geliştirirken gerekli olacak akıcı arayüz yazımını olanaklı kıldığına dikkatinizi çekerim. ↑
Yazıyı okurken Scala'nın kimi özelliklerini gösterebilmek adına, kodumuzu sınıf yazma reçetesinin anlatıldığı yazıda🔎 tavsiye edilenden farklı bir biçimde oluşturduğumuzu aklınızdan çıkarmayınız. ↑
Hatırlayacak olursanız, protected niteleyicisi Java'da altsınıfların yanısıra, aynı paketteki türlere de erişim hakkı sağlar. ↑
Tanımlayıcı adının oluşturulmasında işleçler ve diğer karakterlerin birbirine karıştırılarak kullanılması mümkün değildir. ↑

Karakter Katarı Sınıfları

2011-09-25T03:16:00.004+03:00

Java; ad, adres, makale içeriği gibi metinsel bilgilerin temsil edilmesinde kullanılmak üzere iki başlık altında incelenebilecek seçenekler sunar: dizi temelli çözümler metni eleman türü char olan diziler olarak ele alırken, karakter katarı kavramını soyutlayan sınıflar—üç tane—0 veya daha fazla sayıda karakter içeren katarların kullanımını kolaylaştıran iletiler sağlar. Bizim de bu yazıda yapacağımız, ikinci grupta geçen seçeneklere bakmak olacak.

İşimize neden üç sınıf bulunduğuna açıklık getirerek başlayalım. StringBuilder sınıfının varlık nedeni, içeriği değişmeyen karakter katarlarını temsil eden String sınıfının aşağıdaki kullanımının çalışma hızına dönük yorumla açıklanabilir.

public class SBuilder {
  ...
  public static String ekle(String katar, char[] ek) {
    String sonuç = katar;
    for (int i = 0; i < ek.length; i++)
      sonuç = sonuç + ek[i];

    return sonuç;
  } // String ekle(String, char[])
  ...
} // SBuilder sınıfının sonu
...
String ktr = "Ali";
char[] dizi = {'V', 'e', 'l', 'i'};
ktr = SBuilder.ekle(ktr, dizi);

İlk argümanındaki karakter katarına ikinci argümanındaki karakter dizisinin eklenmesi ile elde edilen sonucu döndüren ekle, işaretlenmiş satırdan dolayı işini yüksek maliyetli bir biçimde yapmaktadır. Benzer bir gözlem, son satırdaki atama için de geçerlidir. Bunun sebebi, String nesnelerinin değişmez içeriğe sahip olması ve içerik değişikliği etkisinin bitiştirme işleci (+) sonucunun aynı tutacağı güncellemesi yoluyla sağlanmasında yatar. Ne kastedildiğini döngü içindeki komutun işlemesi sırasında arka planda olup bitenleri açarak anlamaya çalışalım.

sonuç tarafından gösterilen String nesnesine dizi'nin döngü değişkeni ile gösterilen indisteki elemanının eklenmesi ile elde edilen yeni bir String nesnesi yaratılır.
Yapılan atama sonrasında sonuç yeni yaratılan nesneyi göstermeye başlar. Bu işlemin bir diğer sonucu olarak, sonuç tutacağının göstermekte olduğu eski nesne erişilmez olur ve çöp haline gelir.

Yukarıdaki maddelerin döngünün her dönüşünde icra edildiği düşünüldüğünde, dizi uzunluğu sayısında yeni nesnenin yaratılıp aynı sayıda eski nesnenin çöp haline dönüşeceği görülecektir. Nesne yaratma bağlamında belleğin ayrılması ve ilkleme için gereken zaman çöpe dönüşen eski nesneler ile birlikte düşünüldüğünde, yöntemimizin hem zaman hem de bellek kullanımı açısından tatminkar olmadığı kabul edilecektir. Aradığımız şey, değişken içerikli karakter katarlarının desteklenmesidir ki, bu özellik StringBuilder sınıfı tarafından sağlanır. Yani, özetlemek gerekirse, String içeriği değişmeyen karakter katarlarını soyutlarken, StringBuilder içeriği değişen, uzayıp kısalabilen karakter katarlarını soyutlar.

Bu noktada, sadece StringBuilder sınıfı ile yetinip içeriği değişmeyen karakter katarlarının kullanıcının disiplinli programlamasına bırakılmasıyla tek bir sınıfın yetebileceğini düşünenleriniz çıkabilir. Doğru ya, neden durup dururken karakter katarlarını içeriği değişen ve değişmeyen diye ayıralım ki? Bu haklı sorunun yanıtı, sabit içeriğin çok izlekli≝li (İng., thread) programlarda sağladığı avantajda yatar. Birden çok denetim akışının aynı nesneyi kullanması durumunun ortaya çıktığı bu tür programlarda, nesne içeriğinin değişkenlik göstermesi halinde söz konusu nesneye değişik izlekler içinden eşgüdümlü ve sırasallaştırılmış bir biçimde erişilmesi gerekir. Her zaman doğru yerine getirilmeyen bu koşul, çalışma hızını olumsuz etkilediği gibi programlamayı da zorlaştırır. Sabit içerikli nesnelerde ise durum farklıdır; içeriğin güncellenmeyeceği bilindiği için, söz konusu nesne izlekler içinden herhangi bir sırada eşgüdüm kaygısı olmadan okunabilir. Dolayısıyla, hem programlama daha kolay olacaktır hem de ortaya çıkan program daha hızlı çalışacaktır. Bu nedenle, String ve StringBuilder sınıflarının her ikisine de gereksinim vardır. Peki, ya üçüncü sınıf StringBuffer? StringBuilder ile tamamıyla aynı işlevselliğe sahip olan bu sınıf, StringBuilder'ın performans kaygıları nedeniyle sağlamadığı birden çok izlek içinden güvenli kullanım garantisini ve String'in desteklemediği içerik değişkenliği özelliklerini birleştirir.

	Değişken içerik	Çok izleklilik
`String`	✘	✔
`StringBuffer`	✔	✔
`StringBuilder`	✔	✘

Not: Yazımızın devamında yukarıdaki farklılıkları dışında işlevsel olarak birbirlerinin aynısı olan StringBuilder ve StringBuffer sınıflarını ayrı ayrı incelemeyeceğiz; birisi için yapacağımız açıklamalar diğeri için de geçerli olacak.

Karakter katarlarını temsil etmek için neden üç tane sınıf sağlandığına açıklık getirdikten sonra, dışsallaştırma desteğine işaret eden java.io.Serializable arayüzüne ek olarak her üç sınıfa da ortak olan CharSequence arayüzündeki iletilerin açıklamaları ile devam edelim. Object sınıfındaki ilişkin metodun gerçekleştiren sınıflarda ezilmesini garanti etmek için toString'i içeren bu arayüz, katar içindeki karakter sayısını döndüren length ve argümanındaki indiste bulunan karakteri döndüren charAt iletilerine ilaveten hedef nesnenin argümanlarda belirtilen aralıktaki dilimini CharSequence tutacağı ile gösterilecek şekilde döndüren subSequence iletisini içerir.

Her üç karakter katarı sınıfında da bulunan diğer iletiler, hedef nesnenin içeriğini sorgulamaya yarayan iletilerdir. Bunlardan substring, hedef nesnenin belirtilen dilimi içindeki karakterlerden oluşan bir String döndürür ve iki uyarlamaya sahiptir. Uyarlamalardan ilki argümanlarda verilen sınırlar dahilindeki dilimi döndürürken, tek argümanlı olan ikinci uyarlama yegâne argümanda geçirilen indiste başlayıp katarın sonuna kadar tüm karakterleri kapsayan dilimi döndürür.

alıcı.substring(i, alıcı.length()) ≡ alıcı.substring(i)

Ortak olan bir diğer ileti grubu, karakterlerin Java temsilinde kullanılan UTF-16 kodlamasının bir özelliğini hatırlamamızı gerektiriyor: Her ne kadar modern dillere ait tüm simgeler iki sekizli genişliğindeki char değerlerle temsil ediliyorlarsa da, kimi özel ilgi gruplarının yararlandığı simgeler dört sekizliyle temsil edilir. (Ayrıntı için, buraya🔎 bakınız) Bir diğer deyişle, çoğu karakter (simge) tek bir char ile temsil edilirken kimileri ardışık iki char ile temsil edilebilir. Bu tür karakterleri içeren katarlara charAt iletisinin gönderilmesi, beklenen sonucu vermeyecektir; sorgulamanın başarıyla yapılması karaktere dair her iki char değerin birlikte okunmasıyla mümkün olur ki, incelediğimiz sınıflar bu amaçla charAt yerine kullanılmak üzere codePointAt iletisini sağlar. Argümanındaki indiste bulunan char değeri okuyan bu ileti, okuduğu değerin özel gösterimli karakterlerden birine ait olması durumunda ikinci bir char daha okur ve sonucu olarak okuduğu değeri—duruma göre bir veya iki char—bir int olarak döndürür. Benzer bir şekilde çalışan codePointBefore, kendisine geçirilen indisin öncesindeki karakteri döndürür. Bu noktada, bir hatırlatmanın yapılması yerinde olacaktır: geçirilen indisin değeri codePointAt için 0 ile katardaki char sayısının bir eksiği aralığında iken, codePointBefore için 1 ile katardaki char sayısı aralığında olmalıdır. İşini karakterlerin temsilindeki özel istisnayı göz önüne alarak gören bir diğer ileti, katar içinde kaç tane char olduğunu döndüren length yerine kullanılması gerekebilecek codePointCount iletisidir. Bu ileti, argümanlarında belirtilen indisler arasındaki karakterlerin, char değerlerin değil, sayısını döndürür. Dört sekizli ile temsil edilen karakterlerin dilimin başı ve/veya sonunda yarıda kesilmesi durumunda ise, karakter(ler)in varlığı döndürülen int değere yansıtılır. Herhangi bir indisin işaret ettiği konumdaki karakterin yarıda kesilip kesilmediği ise, offsetByCodePoints iletisi yardımıyla öğrenilebilir. Bu ileti, ilk argümanında verilen indis değerinden başlayarak ikinci argümanındaki sayı kadar sonraki karakterin hangi indiste başladığını döndürür.

indexOf ve lastIndexOf iletilerinin ilk argüman olarak String alanları da her üç sınıfa ortaktır. Bu iletilerden indexOf, ilk argümanında geçirilen String nesnenin hedef nesne içinde ilk hangi indiste geçtiğini döndürürken, lastIndexOf son geçişin indisini döndürür. Aranan katarın hedef nesnede bulunmaması durumu ise dönüş değerindeki -1 ile haber verilecektir. İstenecek olursa, her iki ileti de aramalarını aldıkları ikinci bir argümanın sonrasına/öncesine sınırlayabilir. Bu noktada, tüm iletilerin String sınıfına özel olmak üzere, String yerine char türünde ilk argüman alarak çalışan uyarlamaları da olduğu söylenmelidir.

Karakter katarı sınıflarına ait nesnelerin yaratılması için kullanabileceğimiz yapıcılara bakarak devam edelim. Her üç sınıf da varsayılan yapıcıya ek olarak argümanındaki String nesnenin kopyasını kullanarak ilkleme yapan yapıcılara sahiptir. Ancak, StringBuilder ve StringBuffer sınıflarının ortak bir özelliği, yapıcı kullanımı noktasında unutulmamalıdır: int argüman geçirilerek çağrılan yapıcı dışında, her iki sınıfta da nesnenin ilklenmesinde kullanılan karakterlerin ötesinde 16 char'lık bir bölge nesneye eklemeler yapılması durumunda kullanılmak üzere fazladan ayrılır. Bu gerçeği, aşağıdaki kod parçasının son satırındaki uzunluk ve sığayı döndüren length ve StringBuilder ile StringBuffer'a özel capacity iletilerinin ürettiği çıktıdan da gözlemleyebiliriz.

String ad = "Tevfik", soyad = new String("Aktuğlu");
String adSoyad1 = ad.concat(" " + soyad);
StringBuilder adSoyad2 = new StringBuilder(adSoyad1);
System.out.println(adsoyad2.length()); // ⇒ 14
System.out.println(adsoyad2.capacity()); // ⇒ 30

Yukarıdaki kod parçası incelendiğinde bazı noktalar dikkatinizi çekecektir. Öncelikle, String nesneleri new işleci ve sınıf adı olmaksızın, ilklemede kullanılacak katarın tırnak içinde yazılması ile de yaratılabilir. Bir diğer deyişle, String türlü tutacaklar derleyici tarafından String türlü olarak görülen karakter katarı sabitleri ile ilklenebilirler. Ancak, bunun özel bir durum olduğu ve sizi şaşırtacak sonuçlara neden olabileceği unutulmamalıdır. Ne demek istediğimizi aşağıdaki kod parçasını inceleyerek görelim: bir önceki kod parçası ile aynı biçimde yaratılan iki nesnenin eşitlik denetimleri beklediğimiz sonuçları verirken, aynılık denetimleri birbirleriyle farklı sonuçlar vermekte.

String ad2 = "Tevfik", soyad2 = new String("Aktuğlu");
System.out.println(soyad.equals(soyad2)); // ⇒ true
System.out.println(ad.equals(ad2)); // ⇒ true
System.out.println(soyad == soyad2); // ⇒ false
System.out.println(ad == ad2); // ⇒ true

Aynılık denetiminin beklenilenin aksine true döndürmesinin nedeni, karakter katarı sabitleri için yerin String sınıfının yönetimindeki bir içrek≝ bellekten ayrılmasıdır. Yer ayrımı öncesinde söz konusu sabite eşit bir değer için bu özel bölgeden daha önce yer ayrılıp ayrılmadığına bakılır ve yanıtın olumlu olması durumunda yeni yaratılacak bir String nesnenin tutacağındansa, önceden yaratılmış olan nesnenin tutacağı döndürülür. Örneğimize dönecek olursak; ad tutacağının ilklenmesi noktasında içrek belleğin "Tevfik" değerine sahip bir katar içermemesi nedeniyle [içrek bellekte] yeni bir nesne yaratılarak döndürülmüş, ad2'nin ilklenmesi noktasında ise içrek bellekte aynı değerli bir katarın varlığı saptandığı için daha önceden yaratılan bu nesne kullanılmıştır. Yerden tasarruf sağlamasının yanısıra eşitlik denetimini aynılık denetimine indirgeyen bu özellik, iki karakter katarı sabitinin eşitlik denetiminde == işlecinin kullanılmasına olanak tanıyarak hızdan da kazandıracaktır.

Karakter katarı sabitleri için geçerli olan içrekleştirme—yani, yerin içrek bellekten ayrılması—intern iletisi vasıtasıyla diğer String nesnelerine de yaygınlaştırılabilir. Bu ileti, hedef nesnenin içeriğine sahip olan fakat yeri içrek bellekten ayrılmış bulunan bir nesnenin tutacağını döndürür. Ancak; intern iletisinin tüm String nesneler için kullanılmasının yığın belleğin bir bölgesi olan içrek belleği kolayca doldurup taşırabileceği unutulmamalıdır.

String soyad3 = soyad.intern();
String soyad4 = soyad2.intern();
System.out.println(soyad3 == soyad4); // ⇒ true

Yapıcılara dair ilk örneğimizde▵ açıklama bekleyen ikinci nokta, bitiştirme işleci (+) ile benzer bir işlev gören concat iletisidir. Argümanlarından birisinin String olması halinde diğerini de String.valueOf metotlarından uyumlu türe sahip olanını çağırarak String'e dönüştürüp diğeri ile bitiştiren + işlecinin aksine, concat iletisinin yegâne argümanının String olmaması derleyici hatasına neden olur.¹ Ayrıca, concat argümanındeki karakter katarının boş olması durumunda yeni bir nesnenin tutacağı yerine ileti alıcıyı döndürür.

String sınıfının yapıcıları arasında, StringBuffer ve StringBuilder nesnelerinden String nesnelerine dönüşümü sağlayan çeviren yapıcılara ek olarak, byte, char ve int dizilerini String nesnesine dönüştürenler de vardır. Bu yapıcılar, aynı veya farklı makinelerdeki süreçler arasında akan verilerin String olarak işlenmesini sağlamak için gereklidir. Örnek olarak, yazdığınız Java programının iletişimde bulunduğu bir C programından kendisine gönderilen karakter verileri işlemek istediğini düşünün. Karakter desteğinin ASCII tablosu üzerine inşa edilmesi nedeniyle tek sekizli büyüklüğündeki bir char türüne sahip C tarafından gönderilen karakterler, Java tarafında byte dizisi olarak görülecektir. Bu dizi içindeki karakterlerin ASCII kodlamasına uygun bir şekilde Java programında kullanılabilir bir karakter katarına çevrilmesi gereklidir. Bunun için yapılması gereken aşağıdaki gibi bir yapıcının kullanılması olacaktır.² Yapıcının ilk argümanı dönüşüme kaynaklık eden diziyi sağlarken, ikinci argüman dönüşümde kullanılacak karakter kodlamasını belirtir. İstenecek olursa, dizinin tamamı yerine bir dilimi kaynaklık edebileceği gibi, kodlama bir java.nio.charset.Charset nesnesi vasıtasıyla da bildirilebilir veya sağlanmadığı durumlarda Java platformunun o anki kodlaması olarak varsayılabilir. Mesela, aşağıdaki kod parçasının son satırı, tampon'da biriktirilmiş byte'ların ilk indisten başlayarak 100 tanesini, o anki kodlamayı kullanarak String nesnesine çevirmektedir.

byte tampon[] = new byte[1024];
... // Karşı taraftan akan veriyle tampon'u doldur.
String katar = new String(tampon, "US-ASCII");
... // katar'ı kullan.
...// tampon'u yeniden doldur.
katar = new String(tampon, 0, 100);

Bu noktada, karşı taraftaki program C değil de Java programı olsaydı ve byte yerine char gönderiliyor olsaydı diye sorabilirsiniz. Hatta, ya gönderilen veri UTF-16'da iki char ile temsil edilebilen istisnai karakterleri de içeriyor olsaydı diye üsteliyebilirsiniz. Rahat olun, sorularınız yanıtlanacak ama ilk önce Java'dan C tarafına veri göndermek istediğimizde ne yapmamız gerektiğine bir göz atalım. Bu durumda, String nesnesi içindeki karakterlerin karşı taraftaki programın farkında olduğu bir kodlama ile byte dizisine dönüştüren getBytes işimizi görecektir. Hedef nesnedeki tüm karakterleri argümanındaki String veya Charset nesnesiyle belirtilen kodlamaya göre byte dizisine çeviren getBytes, argümansız kullanıldığı takdirde dönüşümü platformun o an varsayılan kodlamasını kullanarak yapar.

StringBuffer katar = new StringBuffer(...);
... // katar'ı güncelle.
String katar2 = new String(katar);
byte tampon[] = new byte[1024];
katar2.getBytes("US_ASCII")
... // katar2'nin içeriğini karşı tarafa akıt.

String nesnesinden char dizisine benzer bir dönüşüm ise, diğer karakter katarı sınıflarınca da desteklenen getChars ile yapılabilir. Hedef nesnenin ilk iki argümanında belirtilen dilimini son argümandaki indisten başlayarak üçüncü argümanda sağlanan diziye kopyalayan bu ileti, char değerlerin ve String içindeki karakterlerin aynı kodlamayı kullanması nedeniyle kodlama bilgisine gereksinim duymaz. Aynı işi çok daha basit bir imza ile halletmek isterseniz, hedef nesnenin bütün karakterlerini hedef nesnenin uzunluk özelliğine göre yeri ayrılmış bir char dizisine kopyalayan ve sonucu olarak bu diziyi döndüren toCharArray iletisini de kullanabilirsiniz.

Gelelim iki Java programı arasında gidip gelen char'ların String nesnesine dönüştürülmesi işine. Bunun için char dizisi veya dizi dilimi alan yapıcılardan biri kullanılabileceği gibi, aynı parametre listelerine sahip uyarlamaları bulunan String.copyValueOf metotları da kullanılabilir. Kimi zaman aynı iş için int dizisi veya dizi dilimi alan yapıcıların kullanılması gerekebilir. Bu gereklilik iki nedenden ötürü ortaya çıkar: i) veri kaynağında UTF-16'nın tek char'da temsil edemediği karakterlerin var olması, ii) okuduğu char değere ek olarak aykırı durumlar için de kullanılan ekstra dönüş değerlerinden dolayı int döndüren java.io.BufferedReader sınıfındaki read ve benzeri iletilerin doldurduğu dizilerin işlenmesi.

Alışageldiğimiz eşitlik denetimi (equals), hoş yazım (toString) ve kıyım fonksiyonunun (hashCode) ezilmesine ek olarak, Comparable arayüzünü gerçekleştiren String sınıfı, doğal olarak, compareTo iletisine karşılık bir metot sağlar. Ayrıca, büyük-küçük harf ayrımı gütmeksizin işini gören eşitlik denetimi (equalsIgnoreCase) ve karşılaştırma (compareToIgnoreCase) iletileri de sunulur. Bu iki iletiyi, toLowerCase iletisinden de yararlanarak şu şekilde tanımlamamız mümkündür.³

alıcı.equalsIgnoreCase(k)

≡

alıcı.toLowerCase().equals(k.toLowerCase());

alıcı.compareToIgnoreCase(k)

≡

alıcı.toLowerCase().compareTo(k.toLowerCase());

compareTo ve compareToIgnoreCase iletilerini Türkçe içerikli katarları karşılaştırmak için kullandığınızda beklemediğiniz bir sürprizle karşılaşabilirsiniz. Çünkü, bu iletilerin katarlardaki aynı indisli char'ların Unicode tablosundaki sıralarının farkını döndürerek işini gören String sınıfındaki gerçekleştirimleri, Türkçe'de olup İngilizce'de olmayan harflerin Unicode tablosunda diğerlerinden sonra gelmesi nedeniyle, aşağıdaki gibi alfabemizdekiyle çelişkili sonuçlar döndürebilir.

boolean önceMi = "a".compareTo("b") > 0; // önceMi ← true
önceMi = "ş".compareTo("t") > 0; // önceMi ← false

Bu can sıkıcı durumun giderilmesi, bir yörenin (Locale) özelliklerine bağlı kalarak karşılaştırma yapan karşılaştırıcı nesne (Collator) kullanımı ile olanaklıdır.

import java.text.Collator;
import java.util.Locale;
... 
Collator tr = Collator.getInstance(new Locale("tr"));
...
önceMi = tr.compare("ş", "t") < 0; // şÖncet ← true

Eşitlik denetimi amacıyla kullanılabilecek bir diğer ileti, StringBuffer ve CharSequence türlü iki uyarlaması bulunan tek argümanlı contentEquals iletisidir. equals iletisinin varlığında gereksiz gibi gözükebilecek bu ileti, derleyiciye sağladığı ekstra hata denetimi imkanı ve performans avantajından dolayı tercih edilmelidir. equals iletisinin Object türlü bir argümana sahip olmasının bir sonucu olarak, bu iletinin String sınıfı içindeki gerçekleştirimi olan metotta, ilk yapılan şey argümanın String türlü olup olmadığının kontroludur. contentEquals iletisinin gerçekleştirimlerinde ise, daha sıkı bir parametre türü bulunduğu için böylesine bir kontrola gerek yoktur.

Tabii, bazılarınız StringBuffer'a özel bir uyarlamanın bulunup da StringBuilder'a özel bir uyarlamanın neden bulunmadığını sorabilir. Bu haklı sorunun yanıtı, StringBuilder'ın değişken içerikli ve tek izlekli olmasında yatar. Bu sınıf, nesnelerinin aynı anda tek bir izlek içinden kullanılacağı varsayılarak gerçekleştirilmiş, çok izlekli kullanım durumlarında ise sorumluluğu programcıya bırakmıştır. Dolayısıyla, StringBuilder sınıfı çok izlekli bir programda eşitlik denetiminin başladığı noktadan bittiği noktaya kadar karşılaştırılmaya söz konusu olan nesnenin bir başka izlek içinden değiştirilmeyeceğini garanti edemez. Bu ise, sonucun döndürüldüğü noktada bile yanlış olabileceği anlamına gelir. Aşağıdaki maddeleri izleyerek böyle bir durumun nasıl ortaya çıkabileceğini görelim.

(İzlek 1) Eşitlik denetimi başlar. İki uzunluklu katarlardaki (String ve StringBuilder) ilk char'ların eşit olduğu görülür.
(İzlek 2) Argüman olarak geçirilen StringBuilder nesnesinin ilk indisindeki char değiştirilir.
(İzlek 1) İkinci ve son char'ların eşit olduğu görülerek true döndürülür. Halbuki, diğer izlek tarafından yapılmış değişiklik nedeniyle, bu sonuç o anki durumu yansıtmamaktadır.

Bu noktada, StringBuilder nesnelerinin String nesneleri ile eşitlik denetiminin equals'a mahkum edilerek bu sınıfa haksızlık edildiğini düşünüyorsanız, size bir kere daha her üç karakter katarı sınıfının da CharSequence arayüzünü gerçekleştirdiğini hatırlatayım. İstenecek olursa, contentEquals iletisinin CharSequence tutacağı bekleyen uyarlaması kullanılarak equals'a göre hızlı bir karşılaştırma yapılabilir. Ancak, bu bağlamda şu uyarının yapılması yerinde olacaktır: StringBuilder ve StringBuffer sınıfları kısa süre içinde yoğun bir şekilde değişmesi beklenen karakter katarlarını modellemek için düşünülmüştür; daha sonra yararlanılacak gerekli bilgiyi biriktirmek için tampon olarak kullanılan ve tipik olarak kısa ömürlü olan bu sınıflara ait nesnelerin eşitlik denetimi ve karşılaştırma gibi işlemlere konu olması beklenmez. Bundan dolayıdır ki, her iki sınıf da Comparable arayüzünü gerçekleştirmez, Object sınıfından kalıtladıkları equals ve hashCode metotlarını ezmez.

equals iletisinin bir diğer akrabası olan regionMatches, hedef nesnenin bir diliminin kendisine geçirilen bir diğer String nesnenin eşit uzunluklu dilimi ile eşit olup olmadığı sorusuna yanıt bulur. İstendiği takdirde, geçirilecek bir bayrak değeri ile eşitlik denetiminin büyük-küçük harf ayrımı yapıp yapmaması da kontrol edilebilir.

Eşitlik denetimini andıran matches yüklemi, hedef nesnenin argümanında sağlanan düzenli ifadenin (İng., regular expression) betimlediği karakter katarlarından biri olup olmadığına bakar. Örneğin, aşağıdaki kod parçasının son satırında "H" veya "Hayır" girilmesi durumunda programdan çıkılması isteniyor.

import java.util.Scanner;
...
System.out.println("Devam etmek istiyor musunuz? ");
String devamıMı = new Scanner(System.in).nextLine();
...
if (devamMı.matches("H(ayır)?")) System.exit(0);

Düzenli ifade kullanarak işini gören bir diğer ileti, hedef nesnenin argümandaki düzenli ifadeyle betimlenen karakter katarlarının bulunduğu konumlardan bölündüğü alt katarları String dizisi içinde döndüren split'tir. Örneğin, aşağıdaki kod parçasının son satırı, satır içinde birbirlerinden ";" veya ":" ile ayrılmış olan katarları döndürecektir. İstenecek olursa, split'e ikinci argümanında geçirilen bir int değerle parçalardan ilk kaçının kullanıcıyı ilgilendirdiği de belirtilebilir.

String satır;
... // satır'ın içine bir şeyler doldur.
String[] parçalar = satır.split(";|:");

Göz atacağımız son düzenli ifade kullanan String sınıfı iletileri, ilk argümanlarında betimlenen karakter katarlarının yerine ikinci argümanlarındaki String nesnenin içeriğini yerleştiren replaceAll ve replaceFirst iletileridir. Bunlardan ilki, istenen değişikliği tüm noktalarda uygularken, ikincisi sadece uyan ilk noktadaki parçayı değiştirir. Buna göre, aşağıdaki kod parçasının son satırı sonrasında, yeniSatır satır'ın başı ve sonu boşluklardan arındırılmış ve içindeki boşlukların "?" ile değiştirilmiş halini tutacaktır. Anlatım dilinin olası aldatıcılığını düşünerek String nesnelerinin değişmezlik özelliğini bir kez daha hatırlatmakta yarar var: hedef nesne—örneğimizde satır'ın gösterdiği nesne—kesinlikle değişmemektedir; dönüşümler döndürülen String nesneye—örneğimizde yeniSatır'ın gösterdiği nesne—yansıtılmaktadır.

String satır;
... // satır'ın içinde bir şeyler oku.
String yeniSatır = satır.trim().replaceAll(" ", "?");

İlk argümanda belirtilen değerin hedef nesne içinde geçtiği tüm konumlarda ikinci argümandaki ile değiştirildiği hedef nesne mutantını döndüren replace iletisi, char ve CharSequence argümanlı olmak üzere iki uyarlamaya sahiptir.

Biraz nefes alarak, yolumuza String nesnelerinin içerik denetiminde yararlanılabilecek yüklemlere göz atalım. Hedef nesnenin boş olup olmadığına yanıt veren isEmpty'ye ek olarak, endsWith ve startsWith, sırasıyla, hedef nesnenin argümandaki String nesne ile sonlanıp sonlanmadığı ve başlayıp başlamadığı sorusunu yanıtlarken, contains argümanındaki CharSequence kategorisindeki nesnenin hedef nesnede geçip geçmediğine yanıt verir. startsWith ile sorulan sorunun ikinci bir argüman geçirilmek suretiyle hangi indisten başlayarak geçerli olduğu da söylenebilir.

Programlamanın printf ve scanf'den ibaret olduğunu düşünen C gezegeni vatandaşları, eğer bu noktaya kadar sabredebildilerse, bayram edebilirler: String sınıfından göz atacağımız son şey, sprintf fonksiyonunun dengi olan format metodu. Bu metot, ilk argümanında sağlanan format katarının dönüştürülmesiyle elde edilen String nesnesinin tutacağını döndürür. java.util.Formatter sınıfında anlatılan kurallara göre oluşturulan format katarındaki dönüşüm, format'a geçirilen diğer argümanların format katarı içinde eşleştirildiği bildirime göre String'e dönüştürülüp format katarı içine yerleştirilmesi ile yapılır. Örneğin; aşağıdaki tanımların ardından, a'nın %d ile 10'lu tabana, b'nin %o ile 8'li tabana, a + b'nin %x ile 16'lı tabana ve %n'nin yeni satır karakterine dönüştürülerek format katarı içine yerleştirilmesiyle ktr değişkeni "a(37) + b(111) = 6e\n" ile ilklenecektir.

int a = 37, b = 73;
String ktr = String.format("a(%d) + b(%o) = %x%n", a, b, a + b);

Gelelim StringBuilder ve StringBuffer sınıflarına. Bu sınıflar, değişken içerik ve ekleme sonrasında ortaya çıkacak uzamanın maliyetini azaltmaya dönük olarak tutulan boş bölge nedeniyle, String sınıfından farklı olarak ekleme, silme ve değiştirme iletileriyle sığa işlemleme işlemlerini de destekler. Daha önce de söylendiği gibi, bu sınıfların nesnelerinin yaratılması sırasında ilklemede kullanılan katarın ihtiyacından on altı char daha geniş bir yer ayrılır. Nesnenin kullanımı esnasında, taşma olmadığı müddetçe eklemeler bu fazlalık alandan yararlanılarak yapılacak ve taşmanın söz konusu olduğu ilk noktada nesneyi tutan bellek bölgesi genişletilecektir.

İçeriği güncelleyen iletilerin değişiklikleri hedef nesnede yaptığı ve ileti alıcıyı döndürdüğünün bilinmesi zincirleme ileti gönderimini ve dolayısıyla daha akıcı okunabilen kod yazımını olanaklı kılacaktır. Örnek olarak aşağıdaki kod parçasının 7. satırını ele alalım. Bu satır, zincirleme ileti gönderme özelliği sayesinde önder.insert(); ve önder.trimToSize(); gönderilerinin arka arkaya gönderilmesiyle elde edilecek etkiyi yaratacaktır. Benzer bir durum 4. satır için de söz konusudur. Ayrıca, append ve insert iletilerinin tüm ilkel ve bileşke türlü değerleri alabilecek şekilde aşırı yüklenerek gerçekleştirildiğinin de bilinmesi gereksiz yere kullanılacak dönüşümleri ortadan kaldırmak suretiyle daha kısa kod yazılmasını olanaklı kılacaktır.

StringBuffer ad = new StringBuffer("Mustafa");
StringBuilder önder = new StringBuilder(ad);
System.out.println(önder.capacity()); // ⇒ 23
önder.append('_').append("Atatürk");
önder.setCharAt(7, ' ');
System.out.println(önder.capacity()); // ⇒ 23
önder.insert(8, "Kemal ").trimTosize();
System.out.println(önder.capacity()); // ⇒ 21
int i = önder.indexOf("Atatürk");
önder.replace(i, önder.length(), "ATATÜRK");
System.out.println(önder); // ⇒ Mustafa Kemal ATATÜRK

Yukarıdaki kod parçasında iki noktaya açıklık getirilmesinde yarar var. Öncelikle, yaratılmakta olan nesneyi argümanında geçirilen StringBuffer nesnenin içeriği ile ilkleyen ikinci satırdaki yapıcı çağrısının StringBuilder sınıfında desteklenmediğini düşünen arkadaşları yatıştıralım. StringBuilder sınıfında StringBuffer argüman alan bir yapıcının bulunmaması ile telaşlanan bu arkadaşlar her üç karakter katarı sınıfının da CharSequence arayüzünü desteklediğini ve arayüz tutacaklarının çokbiçimli kullanımını anımsarlarsa rahatlayacaklardır. Çünkü, StringBuilder—ve onun çok izlekli uyarlaması olan ikizi StringBuffer—CharSequence arayüzü türlü tutacak bekleyen bir yapıcıya sahiptir. Dolayısıyla, StringBuffer nesneler CharSequence kategorisinde oldukları için, 2. satırda CharSequence türlü tutacak bekleyen yapıcı çağrılacaktır. Açıklık getirilmesi gereken ikinci nokta, ekleme ve silme işlemlerinin etkiledikleri indis değerlerine bağlı olarak maliyetlerinin artabileceğidir. 6. satırdaki insert iletisini ele alalım. Bu gönderi, hali hazırda on beş karakter içeren bir katara 8. indisten başlayarak altı karakterli bir katar eklemektedir. Bu isteğin yerine getirilebilmesi için, sondaki yedi karakterin kaydırılarak eklenecek karakterler için yer açılması gerekir. Gönderilerin düzenlenerek

önder.append(' ').append("Kemal ").append("Atatürk")

şekline dönüştürülmesi daha iyi bir çözüm olacaktır. Çünkü, katar sonuna ekleme yaptığı için karakterlerın kaydırılmasına neden olmayan append'in maliyeti daha düşüktür. Hatta, gönderilerin birleştirilerek tek bir postada işin halledilmesi daha da iyi olacaktır. Son olarak; benzer maliyet kaygılarının argümanında sağlanan indisteki karakteri silen deleteCharAt ve argümanlarında belirlenen katar dilimini silen delete iletileri için de geçerli olduğu unutulmamalıdır.

append ve insert iletilerinin tamsayı türlü değerler geçirilerek kullanılan uyarlamalarında şu nokta unutulmamalıdır: hedef nesneye eklenen, sayının hoş yazımla elde edilen gösterimidir, karakter tablosunun sayı ile belirtilen indisindeki karakter değil. İstenenin ikinci seçenek olması durumunda int argüman alan appendCodePoint iletisinin kullanılması gerekir. Aşağıdaki kod parçasını takip ederek farkı anlamaya çalışalım. İkinci satırdaki append boş katara "65" eklerken, bir sonraki satırda gönderilen appendCodePoint iletisi katar sonuna Unicode tablosunun 65. konumundaki 'A' karakterini ekleyecektir.

StringBuilder katar = new StringBuilder("");
katar.append(65);
katar.appendCodePoint(65);
System.out.println(katar); // ⇒ 65A

capacity, ensureCapacity ve trimToSize Vector🔎 sınıfındaki adaşları ile benzer şekilde çalışırken, length iletisi katardaki char sayısını döndürür. setLength ise, geçirilen argümanın ve o anki uzunluk değerine göre katarı uzatıp kısaltabilir; argümanın o anki uzunluktan büyük olması durumunda hedef nesne uzatılarak yeni konumlar '\u0000' değeri ile doldurulurken, yeni uzunluk değerinin eskisinden küçük olması durumunda hedef nesne yeni uzunluk ile eskisi arasındaki değerlerin kırpılması ile küçültülecektir.

StringBuilder ve StringBuffer sınıflarındaki iletilerden değineceğimiz sonuncusu, hedef nesnenin içeriği yerinde tersine çeviren reverse iletisidir. Gelin bu iletiyi kullanan ufak bir örnekle yazımızı bitirelim.

import java.io.Console;
import java.util.Locale;

public class Palindromik {
  public static void main(String[] ksa) {
    System.out.print("Palindromikliği sınanacak katar: ");
    String sözcük = System.console().readLine().trim().toUpperCase(new Locale("TR"));
    String tersi = new StringBuilder(sözcük).reverse().toString();
    if (sözcük.equals(tersi)) System.out.println("palindromik");
      else System.out.println("palindromik değil");
  } // void main(String[]) sonu
} // Palindromik sınıfının sonu

Yukarıdaki kodu düzenleyerek bazı alternatif çözümler geliştirebilirsiniz. Mesela, küçük harften büyük harfe çeviren toUpperCase yerine ters yönde çeviri yapan toLowerCase iletisini kullanmanız aynı işi görecektir. Ya da, equals yerine compareTo iletisi kullanılarak dönen değerin 0 ile eşitlik denetiminin yapılması da aynı kapıya çıkacaktır. Ancak; String sınıfını işe bulaştırmadan kullanılacak bir equals Object sınıfındaki aynılık denetimi yapan aynı adlı metodu çağıracağı için beklediğinizden farklı sonuçlar verecektir. Çünkü, StringBuilder ve StringBuffer sınıfları, değişken içerikli ve genelde kısa ömürlü karakter katarı tamponlarını soyutlar; bu özellikteki nesnelerin eşitlik denetimi ve karşılaştırılmaları içeriklerinin değişkenliği nedeniyle pek anlamlı değildir. Yapılması gereken, ihtiyaç duyulan bilginin StringBuilder veya StringBuffer nesnesi içinde doldurulması sonrasında String nesnesine çevrilmesi ve yola öyle devam edilmesidir.

Karakterler: char Türü
Düzenli Deyimler

Bitiştirme esnasındaki dönüşümün nesneye toString iletisi gönderilerek yapıldığını düşünenler yanılmıyorlar; dönüştürülecek değerin bileşke türlü olması durumunda işi kotaran gerçekten de hoş yazım iletisi olarak da bilinen toString'dir. Ancak, hoş yazımı istenen değerin ilkel türden olması halinde, ileti alan tutacakları olmaması nedeniyle, iş String.valueOf metotlarından uygun olanı çağrılarak yerine getirilir. Aslına bakacak olursanız, bir nesnenin hoş yazımı için gönderilen toString iletisi, Object türlü argüman bekleyen String.valueOf metodu içinden gönderilir. ↑
Doğruyu söylemek gerekirse, böyle bir durumda byte'tan char'a dönüşümü otomatikman yapan java.io.InputStreamReader gibi bir akak sınıfının kullanılması daha yerinde olacaktır. ↑
Benzer bir denklik, toUpperCase ile de kurulabilir. ↑

Değişken Uzunluklu Diziler: java.util.Vector

2011-09-14T00:17:00.001+03:00

Dizi yapısının belki de en büyük artısı, eleman erişim ve eleman güncellemenin sabit maliyetli olmasıdır; hangi indisteki eleman söz konusu olursa olsun, doğrudan erişim sayesinde her iki işlem de sabit (ve yüksek) hızlı bir şekilde yapılabilmektedir. Ancak, bunu mümkün kılan "elemanların dizinin yaratıldığı noktada ayrılan ardışık bellek konumlarına yerleştirilmesi" özelliği, yapının statik olması sonucunu da doğurur. Yani, dizinin yaratılması sonrasında uzunluğunun değiştirilmesi olanaklı değildir. Dolayısıyla, kullanım sırasında bir taşmanın olmaması için, yer ayrımının olası en yüksek eleman sayısı düşünülerek yapılması gerekir. Bunun sonucu da kimi zaman, ayrılan yerin tümünden yararlanılmadığından, belleğin verimsiz kullanımı olacaktır.

Bu olumsuzluğu gidermek için, dizi tutacağını yeri yeni ayrılmış ve baş kısmında eski dizi nesnesinin kopyasına sahip daha büyük bir dizi nesnesini gösterecek şekilde güncellemeyi düşünebilirsiniz. Java karşılığı aşağıda sunulan bu yaklaşımın iki zaafı vardır: i) dizinin büyümesi için gerekli olan kod programcı tarafından yazılmak zorundadır ve ii) programcı dizinin ne zaman büyümesi gerektiğini bilmelidir.

int[] dizi = {0, 1, 4};
...
dizi = Arrays.copyOf(dizi, dizi.length * 2);
dizi[3] = 9;

İşte bu yazımızda, Java kitaplığı tarafından değişken uzunluklu dizileri desteklemek amacıyla sağlanan java.util.Vector sınıfına bakacağız. Vector nesnelerinin sahip olması gereken öznitelikler ile başlayalım: sığa, eleman sayısı ve sığa artımı. Sığa, bir Vector nesnesinin büyümeye gerek olmadan kaç değer tutabileceğini gösterirken; eleman sayısı, sorgulandığı anda Vector'de kaç değer tutulmakta olduğunu gösterir. Vector nesnesinin dolması sonrasında—yani eleman sayısı ile sığanın eşit olması halinde—yeni bir elemanın eklenmesi istenecek olursa, taşmayı önlemek adına Vector nesnesinin sığası, sığa artımı özelliğinde öngörüldüğü miktarda artırılarak yeni eleman için yer açılır ve ekleme yapılır.

Yapıcılar

Vector nesnelerine gönderilebilecek iletilere geçmeden önce, sağlanan yapıcılara bir göz atalım. Aşağıda verilen örneklerden de görülebileceği gibi, Vector sınıfı soysaldır; tutacaklarının tanımlandığı ve nesnelerinin yaratıldığı noktalarda ilişkin kapta tutulacak elemanların türü bilgisini tür argümanı olarak ister. Tür argümanının es geçilmesi, Vector sınıfının J2SE 5.0 öncesinde olduğu gibi tür güvenliği olmaksızın kullanılacağı anlamına gelir.

Vector<Integer> intVec1 = new Vector<Integer>(50, 10);
Vector<Integer> intVec2 = new Vector<Integer>(50);
Vector<Integer> intVec3 = new Vector<Integer>();
intVec1.add(1);
...
Vector<Integer> intVec4 = new Vector<Integer>(intVec1);
boolean aynıMı = intVec4 == intVec1; // aynıMı ← false
boolean eşitMi = intVec4.equals(intVec1); // eşitMi ← true
intVec4.set(0, 11);
eşitMi = intVec4.equals(intVec1); // eşitMi ← false

İlk yapıcı çağrısı, başlangıç sığası 50 olan ve taşma noktalarında 10 elemanlık artımla genişletilecek bir Vector nesnesi yaratır. Sığa artım argümanı olarak pozitif olmayan bir değer geçirilmesi veya ikinci satırdaki yapıcı çağrısında olduğu gibi artım değerinin sağlanmaması durumunda, Vector nesnesinin sığası her taşma noktasında ikiye katlanarak artırılacaktır. Buna göre, intVec2 tutacağı ile gösterilen nesne 51. elemanın eklenmesi istendiği noktada 100, 101. elemanın eklenmek istendiği noktada ise 200 eleman tutabilecek şekilde genişletilecektir. Benzer bir sığa artırım politikası izlenecek üçüncü satırdaki varsayılan yapıcı çağrısı, on elemanlık başlangıç sığasına sahip bir Vector nesnesi yaratacaktır. Son satırdaki çağrı ise, kopyalayan yapıcı görevini görecek ve kendisine geçirilen Collection<E> kategorisindeki bir kabın elemanlarını gezicinin≝ döndürdüğü sırada yaratılmakta olan Vector nesnesine kopyalayacaktır. Kopyalamanın sonrasında eşit fakat birbirlerinden farklı (ve bağımsız) iki Vector nesnesinin var olacağı ve bunlardan birisine yapılacak değişikliğin diğerini etkilemeyeceği unutulmamalıdır. Ayrıca, yeni yaratılan Vector nesnesinin ilk sığası diğerinin eleman sayısı ile sınırlı olacaktır.

Desteklenen Arayüzler

Vector sınıfının dokümantasyonuna baktığınızda, desteklenen iletilerin çokluğu gözünüzü korkutabilir. Ancak, bunların bir bölümünün bir diğer ileti ile eşdeğer olduğu, bir bölümünün ise bildiğiniz sınıflardan tanıdık geleceği düşünüldüğünde, işimizin o kadar da zor olmadığı görülecektir. Ne de olsa, aşağıda verilen soy ağacına sahip olan Vector sınıfı, gerçekleştirilen ortak arayüzler ve kalıtlanılan ortak üstsınıflar nedeniyle Veri Kapları Çerçevesi'ndeki diğer sınıflarla büyük benzerlikler gösterir.

Iterable arayüzü ile başlayalım. Genelde programcı tarafından doğrudan kullanılmayacak olan iterator iletisini içeren bu arayüz, derleyiciye söz konusu sınıfın gezici for döngüsü ile [baştan sona] dolaşılabileceğini garanti eder. Mesela, aşağıdaki kod parçası, hiç gezici nesne yaratıp, bu nesneye ileti göndermek zahmetine katlanmadan intVec4'in gösterdiği kaptaki tüm elemanların kareköklerini standart çıktıya basar.

for (Integer eleman : intVec4)
  System.out.println(Math.sqrt(eleman));

Gerçekleştirilen arayüzler listesindeki Cloneable, Vector nesnelerinin kopyalarının çıkarılabileceği anlamına gelir. Object sınıfındaki clone metodunun gösterge arayüz≝ olan Cloneable'ı gerçekleştiren sınıflarda özel bir biçimde ezilmesiyle yerine getirilen sözleşme sonucunda, clone iletisi Object türlü bir tutacakla dahi gönderilebilir ve yaratılan kopya Object tutacağı aracılığıyla döndürülür. Dolayısıyla, yeni kopyaya Vector sınıfına has iletiler gönderilmesi öncesinde sonucun biçimlendirilmesi gerekecektir. Ayrıca; işlem sırasında elemanları tutan kap kopyalandığı için hedef nesne ile çıkarılan kopya ayrı nesneler olacaktır. Bu, nesnelerin atıflarının (tutacak) geçirildiği Java'da, değer geçirme yönteminin benzetimi için kullanılabilir.

...
public void mtt(Vector<Integer> vec) {
  Vector<Integer> vecKopya = 
    (Vector<Integer>) vec.clone();
  // vecKopya'yı kullan.
  ...
} // void mtt(Vector<Integer>) sonu

java.util.RandomAccess de gösterge arayüz olup herhangi bir ileti içermez. İşaret görevini gören bu arayüzün varlığı, kimi zaman doğrudan erişimli kimi zamansa doğrudan erişimli olmayan kapları işleyerek işini gören soysal kod parçalarında, doğrudan erişimliliğin avantajlarından yararlanılabilecek noktalarda bu özelliğin kullanılmasıyla performansın artmasını olanaklı kılar. Bunun için, nesnenin RandomAccess arayüzünü destekleyip desteklemediğinin aşağıdaki gibi denetlenmesi yeterli olacaktır.

...
if (kap instanceof RandomAccess) {
  // Doğrudan erişimin avantajlarından yararlan.
  ...
} else { ... }
...

Desteklenen gösterge arayüzlerden bir diğeri olan java.io.Serializable, Vector nesnelerinin disk dosyası, ağ gibi çevre aygıtlara dışsallaştırılıp, aynı aygıtlardan içselleştirilebileceğini gösterir. Bu, Vector nesnelerinin java.io.ObjectOutputStream türünden akak≝lara writeObject ile yazılıp, java.io.ObjectInputStream türlü akaklardan readObject ile okunabileceği anlamını taşır.

Değineceğimiz son arayüzler, Vector nesnelerini ekleme, güncelleme, silme, sorgulama gibi işlemlerle manipüle eden java.util.Collection ve java.util.List arayüzleridir. Collection, Veri Kapları Çerçevesi'ndeki kapların pek çoğu için geçerli olan işlemlerin genel sözleşmelerini sağlar. Bu yapılırken, ne çeşit bir kabın ele alındığı konusunda—aynı değerden iki veya daha fazlası tutulabilir mi, uygulanan işlemlerin sıra ve sonucuna göre elemanların yapı içindeki sırası bilinebilir mi?—bir varsayımda bulunulmaz. Buna karşılık, List arayüzü, kaptaki değerlerin tekrarlanabileceğini ve uygulanan işlemlerin sonrasında yapı içindeki sıranın bilinebileceğini varsayar.

Desteklenen İletiler

İletilere öznitelikleri işlemlemek için yararlanabileceklerimizle başlayalım. Argümansız size ve capacity iletileri, sırasıyla, hedef nesnenin kaç eleman içerdiğini ve sığasını döndürürken, isEmpty boşluk yüklemi olarak görev görür. Hedef nesnenin içeriğini eleman sayısına eşit sığalı bir kaba koyarak bellekten tasarruf sağlayan trimToSize, eleman sayısının artmayacağından emin olduğumuz durumlarda kullanılabilir. Sığanın değiştirilmesine yarayan bir diğer ileti olan ensureCapacity, hedef nesneyi argümanda geçirilen değere eşit veya daha büyük bir sığaya sahip olacak şekilde değiştirir. Bu işlemin icra edilmesi esnasında, hedef nesne yaratılırken sağlanan/varsayılan sığa artım değerinden yararlanılacaktır. Son olarak, setSize, hedef nesnedeki eleman sayısı özniteliğini günceller. Bu iletinin kullanımında dikkat edilmesi gereken bir nokta, geçirilen argümana göre eleman sayısının artması gibi azalmasının da mümkün olduğudur: argümanın ileti gönderimi anındaki eleman sayısından büyük olması eleman sayısının null değerine sahip elemanlar eklenerek artırılmasına neden olurken, küçük olması kabın sonuna doğru bazı değerlerin kırpılmasına, yani eleman sayısının azaltılmasına neden olacaktır.

Sınıflarını yazarken titiz davrananlara tanıdık gelecek iletilerle devam edelim. equals ve toString, beklendiği gibi, sırasıyla, eşitlik denetimi ve hoş yazım işlemlerini karşılarken hashCode, hedef nesneyi kıyarak özet değeri görevini gören bir int döndürür. Bilmeyenler için, bunun kulağa geldiği kadar vahşi bir şey olmadığını, nesneyi değiştirerek zarar vermediğini söyleyelim ve ne işe yaradığını biraz açalım. Potansiyel olarak pek çok eleman içerebilecek kapların eşitlik denetimi oldukça uzun bir zaman alabilir; ilk elemandan başlayarak eşit olmayan eleman çiftine kadar kontrol edilen iki kabın aynı indislerdeki elemanları birbirleriyle karşılaştırılır. Bu, eleman sayısı ile doğru orantılı olarak artan oldukça pahalı bir işlemin söz konusu olduğu anlamına gelir. Maliyet kap içeriğinin özeti olarak bir değerin tutulması ile azaltılabilir; kap değiştikçe—bu, eleman ekleme, güncelleme ve eleman silme ile mümkün olabilir—özet değer yeniden hesaplanır. Bir diğer kap ile eşitlik denetiminin yapılması istendiği durumlarda ise, önce eleman sayıları sonra ise hashCode ile öğrenilebilecek özet değerler karşılaştırılır. Özet değerler eşit değilse, kaplar da eşit değildir; aksi takdirde, eşitsiz kapların özetlerinin eşit olması olanaklı olduğundan, yukarıda bahsettiğmiz pahalı yöntemle eşitlik denetimi yapılır.

public class Vector<E> extends AbstractList<E>
  implements List<E>, Cloneable, RandomAccess, Serializable {
  ...
  public boolean equals(Object sağ) {
    Vector<E> sağTaraf = (Vector<E>) sağ;
    if (size() != sağTaraf.size()) return false;
    if (hashCode() != sağTaraf.hashCode()) return false;
    // Kapları dolaşarak karşılıklı elemanları denetle.
    ...
  } // boolean equals(Object) sonu
  ...
} // Vector<E> sınıfının sonu

Vector sınıfı, içerik güncellenmesi ve sorgulanması için pek çok ileti sunar. Ancak, kimi iletilerin bir diğer Java sürümünde eklenen eşdeğerleri bulunduğu için, ileti listesini anlamlandırmak işinin altından kalkmak görünenden kolay olacaktır. Bu gruba giren iletilerden aşağıdaki tablonun ilk sütununda verilmiş olanları kullanmanız daha akıllıca olacaktır. Zira, Collection ve List arayüzlerinde tanımlanmış olan bu iletilerin kullanımı, Vector yerine Veri Kapları Çerçevesi'ndeki diğer sınıfların kodunuzda değişiklik yapılmadan kullanılmasını sağlayacak ve yeniden kullanımı olanaklı kılacaktır.

`Vector` sınıfındaki eşdeğer iletiler
`add(e)`	`addElement(e)`	`e`'yi kabın sonuna ekler
`add(i, e)`	`insertElementAt(e, i)`	`e`'yi `i` indisli konuma ekler
`clear()`	`removeAllElements()`	Hedef nesneyi boşaltır
`get(i)`	`elementAt(i)`	`i` indisli elemanı döndürür
`remove(e)`	`removeElement(e)`	`e` ile eşit ilk konumdaki değeri siler
`remove(i)`	`removeElementAt(i)`	`i` indisli elemanı siler
`set(i, e)`	`setElementAt(e, i)`	`i` indisli elemanı `e` ile değiştirir ve eski değeri döndürür.

İçerik sorgulama ve güncelleme iletilerinin anlatımına geçmeden önce, eleman ekleme ve silme iletilerinin kullanımı sırasında akılda tutulması yararlı olacak şu noktayı hatırlatalım: ekleme sırasında, eklemenin yapıldığı indis sonrasındaki elemanlar sona doğru, silme sırasında, silinen elemanın sonrasındaki elemanlar öne doğru kaydırılacaktır. Dolayısıyla, bu işlemlerin etkilediği indis kap önlerine yaklaştıkça maliyet artacaktır.

İki uyarlaması bulunan add, hedef nesneye yeni eleman eklemeye yarar. Bu iletilerden, tek argümanlı olanı, argümanındaki değeri Vector nesnesinin sonuna ekleyip true döndürürken, iki argümanlı olanı, ikinci argümandaki değeri ilk argümanda belirtilen indisteki konuma ekler. Eklemenin toptan yapılması istendiğinde, bir döngü veya pek çok add iletisi kullanmaktansa addAll iletisi kullanılabilir. add iletisine koşut iki uyarlaması bulunan bu ileti, kendisine geçirilen Collection arayüzünü destekleyen kabın içindeki elemanları gezicisinin döndürdüğü sırada hedef nesneye ekler.

get iletisi, yegâne argümanında belirtilen indisteki elemanı döndürür. Bu iletinin özel kullanımları için, sırasıyla ilk ve son elemanları döndüren firstElement ve lastElement iletileri tercih edilebilir. Ancak, kodun yeniden kullanım kaygıları ağır basıyorsa, List arayüzünde tanımlanmış get'i yeğlemek daha yerinde olacaktır. Bir grup ardışık elemanın döndürülmesi ise, List arayüzü türündeki tutacakla gösterilen bir Vector nesnesi döndüren subList iletisi ile olanaklıdır. Bu ileti, hedef nesnenin ilk argümandaki indisten başlayıp ikinci argümandaki indisin bir öncesinde sonlanan dilimini döndürür.

indexOf ve lastIndexOf iletileri de sorgulama amacıyla kullanılablir. get verilen bir indisteki elemanı döndürürken, indexOf ve lastIndexOf eleman türündeki bir değer alıp bu değerin hedef nesnede geçtiği indisi döndürür. İki uyarlaması var olan indexOf, tek argümanlı kullanılacak olursa argümanda geçirilen nesnenin bulunduğu ilk indisi döndürürken, iki argümanlı kullanılırsa, ilk argümanda geçirilen nesnenin ikinci argümanda belirtilen indisten sonra bulunduğu ilk yerin indisini döndürür. Benzer şekilde; lastIndexOf, tek argümanlı kullanılacak olursa argümanda geçirilen nesnenin bulunduğu son indisi döndürürken, iki argümanlı kullanılırsa, ilk argümanda geçirilen nesnenin ikinci argümanda belirtilen indisten önce bulunduğu ilk yerin indisini döndürür. Aranan nesnenin hedef nesnede bulunmaması kullanıcıya -1 döndürülerek bildirilecektir.

Sorgulama amacıyla yararlanabileceğimiz bir diğer ileti çifti, yegâne argümanlarında geçirilen nesnenin veya Collection arayüzünü destekleyen kaptaki elemanların hedef nesnede geçip geçmediğinin yanıtını veren contains ve containsAll yüklemleridir.

Hedef nesneden eleman silme işlemi, argüman olarak indis veya silinmesi istenen değere eşit bir nesne bekleyen iki remove iletisi ile karşılanır. İndis alan uyarlama istenen konumdaki elemanı silip sonucu olarak döndürürken, diğer ileti argümanındaki nesnenin hedef nesne içinde, varsa, geçtiği ilk noktadaki elemanı siler ve silmenin gerçekleşmesi durumunda true, aksi halde false döndürür.

Çoklu silme, removeAll, retainAll veya clear iletilerinden biri kullanılarak yapılabilir. removeAll, argümanındaki Collection arayüzünü destekleyen kap içindeki elemanların hedef nesnedeki bütün kopyalarını silerken, retainAll argümandaki kabın elemanlarının hedef nesnedeki tüm kopyalarının korunması ve geri kalan elemanların silinmesini sağlar. Her iki ileti de, işleyişleri sırasında hedef nesneyi değiştirecek olurlarsa true, aksi takdirde false döndürür. Son olarak, clear komutu, hedef nesnedeki tüm elemanları siler.

Eleman güncellemede kullanılan set iletisi, ilk argümanında sağlanan indisteki elemanı ikinci argümandaki değer ile değiştirir ve değişim öncesindeki eleman değerini sonucu olarak döndürür.

Değineceğimiz bir sonraki ileti grubu, gezici nesnesi döndürenler.¹ listIterator adlı bu iletiler, hedef nesneyi çift yönlü dolaşıp, güncellememizi sağlayan ListIterator türlü bir gezici nesne döndürür.² Bunlardan argümansız olanı, dolaşmaya hedef nesnemizin ilk indisinden başlarken, tek argümanlı olanı, dolaşmaya argümanda belirtilen indisten başlar. İstenen yere konuşlanılmasını takiben, gezici nesneye sonraki/önceki elemanı döndürme (next, previous), o anki konuma ekleme (add), o anki konumdaki elemanı güncelleme (set) ve silme (remove) imkanını veren iletiler gönderilebilir. Geziciye gönderilen iletiler esas etkilerini dolaşılmakta olan kap üzerinde gösterecektir. Bunu, Vector nesnesi içindeki 3 değerine sahip elemanları gezici vasıtasıyla silen aşağıdaki kod parçasından görebilirsiniz.

import java.util.ListIterator;
...
ListIterator<Integer> gezici = intVec4.listIterator();
while (gezici.hasNext())
  if (gezici.next() == 3) gezici.remove();

Göz atacağımız son ileti grubu, Vector yerine bir başka yapının gerektiği veya daha uygun olduğu zamanlarda ihtiyacını duyduğumuz dönüşümü sağlar. Öncelikle, Veri Kapları Çerçevesi'nde ArrayList, HashSet ve LinkedList'in de içinde olduğu pek çok sınıf, Collection arayüzünü gerçekleştiren bir kap bekleyen yapıcıya sahiptir. Bu yapıcılar, geçirilen kabı baştan sona dolaşarak elemanları yaratılmakta olan yeni kaba eklerler. Dolayısıyla, Vector ve diğer pek çok sınıfın Collection arayüzünü gerçekleştirdiği anımsanacak olursa, Vector nesnelerinin pek çok diğer türden kaba ve diğer türden kapların Vector nesnesine çevrilmesi kolaylıkla mümkün olacaktır.

Vector nesneleri dizi nesnelerine copyInto ve toArray iletileri kullanılarak dönüştürülebilir. copyInto hedef nesnenin içerdiği elemanları argümanında sağlanan dizinin içine doldururken dizinin yeterli uzunlukta olmamasını kullanıcıya IndexOutOfBoundsException ayrıksı durumu ile bildirir. Buna karşılık, benzer imzaya sahip toArray iletisi, argümanda geçirilen dizinin yetersiz kalması durumunda sızlanmaz ve gerekli uzunluğa sahip yeni bir dizi nesnesi yaratıp işini bu yeni dizi üstünde tamamladıktan sonra bu diziyi döndürür. toArray'in argümansız ikinci uyarlaması da, hedef nesnenin eleman sayısına sahip bir dizi döndürerek işini görür.³

Diziler
Doğrusal Veri Kapları
Hızlı Arama Zamanlı Kaplar

elements iletisi iterator ve listIterator iletilerinin eklenmesi ile kullanımdan düşmüştür. Dolayısıyla, anlatımımız bu iletiyi kapsamayacaktır. ↑
İletilerin adı olarak vectorIterator yerine listIterator (liste gezici) seçilmiş olması sizi şaşırtmasın. Ne de olsa baştan sona dolaşılmak tüm doğrusal veri yapıları için makul bir işlem ve bu yüzden bu işleme karşılık gelen iletiler List arayüzüne konulmuş. ↑
Bu iletinin Vector sınıfındaki gerçekleştirimi Arrays.asList metodu ile bir bütün olarak düşünülmelidir. ↑

Kategorize Etmenin Yararları ve Arayüzler

2011-09-08T19:11:00.000+03:00

Her ne kadar Bülent Ortaçgil, beni kategorize etme, demişse de, kategorizasyon çevremizi anlamamızı kolaylaştıran ve sıklıkla başvurduğumuz çok önemli bir keşif aracıdır. Birbirlerine benzesin ya da benzemesin, değişik türden varlıkların ortak yönlerini gruplamamızı olanaklı kılarak soyutlama yapmamızı sağlayan bu araç, keşfimizin paylaşılabilir olması durumunda, kendimizi daha kısa yoldan anlatmamızı da olanaklı kılar. Örneğin, üçüncü bir şahsın obez olduğu konusundaki gözlemimizi paylaştığımızda, karşımızdaki kişi, hangi ulustan olursa olsun, konuşmaya konu olan kişinin saçının, gözlerinin ne renk olduğunu bilemese de nasıl vücut hatlarına sahip olduğunu kafasında canlandırılabilir. Çünkü, ortak tanımı üzerinde anlaşılmış—yani, standart bir tanımı bulunan—obez olma özelliği kişilerin ait olduğu grupları aşan bir özelliktir; birbirleriyle hiç alakası bulunmayan grupların üyeleri arasında ortak payda olarak kullanılabilir. Yani, kafamızın içindeki gri materyalin tasnif etme donanımı, biz istesek de istemesek de, diğer kişileri müstahdem, öğretmen, yönetici, vb. şeklinde sınıflandırdığı gibi, obez, zeki, işbilir, vb. şeklinde de kategorize etmektedir. Yeri geldiğinde, sınıflarla kategoriler bitiştirilmekte ve obez öğretmen, işbilir yönetici gibi yeni sınıflamalar da yapılabilmektedir.¹

İşte bu yazımızda, Java programlama dilinin nesneler alemini tasnif etmekte sınıf ile birlikte kullanılabilecek ikinci üstkavramı olan arayüz kavramına değineceğiz. Ama ilk önce pedagojik senaryomuz. Yer ülkemizdeki liselerden birinin müdüriyeti ve uyuşturucunun ilk paketinin bedava olduğunu bildiği için bazı şirketlerce öğretim ordusunun üyelerine "bedava" dağıtılan programlama dillerini kullanmayı reddederek Java'yı tercih eden müdürümüz, yönetimindeki öğrenci ve öğretmenlerin performansını özetleyecek bir programı nasıl yazabileceğini düşünmekte. Müdürümüzün amacı, öğrenci ve öğretmenleri kendi aralarında uygun bir ölçüte göre sıralayıp listelemek. Çiziktirmelerle dolu sayfalara baktığımızda, müdürümüzün öğrencileri önce ortalamaları sonra—ortalamaların eşit olması durumunda—numaraları karşılaştırırak sıraya dizmeyi düşünürken, öğretmenleri önce öğrenci anketlerindeki konu yeterliliği notunun ortalamasını sonra ders yükünü karşılaştırırak sıraya dizmek istediğini görüyoruz.

Yordamsal programlama alışkanlıkları olduğu anlaşılan müdürümüz, ilk çözüm girişiminde Performans adlı bir sınıftaki dört metot ile işini halletmeye çalışmış. Buna göre, sıralama metotları kendilerine geçirilen veri kümesinin elemanlarını ilişkin karşılaştırma metodunu çağırarak sıraya dizmekte.

Performans.java

public class Performans {
  ...
  public static int karşılaştır(Öğrenci sol, Öğrenci sağ) {
    ...
  } // int karşılaştır(Öğrenci, Öğrenci)

  public static int karşılaştır(Öğretmen sol, Öğretmen sağ) {
    ...
  } // int karşılaştır(Öğretmen, Öğretmen)

  public static void sırala(Öğrenci[] veri) { ... }

  public static void sırala(Öğretmen[] veri) { ... }
  ...
} // Performans sınıfının sonu

Performans'ı Öğrenci ve Öğretmen sınıflarına bağımlı kılması—Öğrenci ve Öğretmen sınıflarının değişmesi ilişkin karşılaştırma metotlarının değişmesine neden olabilir—ve sıralama metotlarının neredeyse aynı olmasından—ne de olsa, aynı algoritma kullanılıyor—huylanan müdürümüz, static niteleyicisinin nesne paradigmasının düşmanı olduğunu anımsaması ve, düşülen nota inanırsak, İnternet'teki bir yazıyı🔎 okuması sonrasında, sınıf ve kalıtlama kavramlarının kullanıldığı bir çözümü yeğleyerek bu çözümden vazgeçmiş.

Karşılaştırılabilir.java

public abstract class Karşılaştırılabilir {
  public abstract int karşılaştır(Karşılaştırılabilir sağ);
} // Karşılaştırılabilir sınıfının sonu

Öğrenci.java

public class Öğrenci extends Karşılaştırılabilir {
  ...
  public int karşılaştır(Karşılaştırılabilir sağ) {
    Öğrenci sağTaraf = (Öğrenci) sağ;
    ... // ileti alıcı ile sağTaraf'ı karşılaştır.
  } // int karşılaştır(Karşılaştırılabilir)
  ...
} // Öğrenci sınıfının sonu

Öğretmen.java

public class Öğretmen extends Karşılaştırılabilir {
  ...
  public int karşılaştır(Karşılaştırılabilir sağ) {
    Öğretmen sağTaraf = (Öğretmen) sağ;
    ... // ileti alıcı ile sağTaraf'ı karşılaştır.
  } // int karşılaştır(Karşılaştırılabilir)
  ...
} // Öğretmen sınıfının sonu

Performans.java

public class Performans {
  ...
  public static void sırala(Karşılaştırılabilir[] veri) {
    ...
  } // void sırala(Karşılaştırılabilir[]) sonu
  ...
} // Performans sınıfının sonu

Anlaşılan, yukarıda kaba hatlarıyla verilen çözümün, Java'nın çoklu sınıf kalıtlamayı desteklememesi nedeniyle, Öğrenci ve Öğretmen'in bir diğer sınıftan daha—mesela, iki sınıfın ortak noktalarını içeren Kişi gibi—türetilmesini engellediğini gören ve karşılaştırmanın genel bir işlem olduğunu düşünen müdürümüz, Karşılaştırılabilir'in aslında gereksiz olduğuna karar vermiş ve söz konusu işleme karşılık gelen iletiyi Object sınıfının içinde aramış. Buna gerekçe olarak da, equals (eşitlik denetimi) ve toString (hoş yazım) gibi tüm nesneler için geçerli olan iletilerin tüm sınıfların ortak noktalarını barındıran Object'te yer alması gerektiğini not düşmüş. Görünen o ki, bu varsayımın arama sonucunda yanlışlanması, müdürümüzü Java programlamayı iyi bilen bir matematik hocasının kapısını çalmaya zorlamış. Derdinin çaresinin Object sınıfında değil, arayüz kavramının kullanımında yattığını söyleyen matematik hocası, küme, matris, karmaşık sayı gibi matematiksel nesnelerin aslında karşılaştırılabilir olmadığı konusunda garanti vererek müdürümüzü ikna etmiş. Gelin bundan sonrasını birlikte görelim.²

Birbirleriyle ilintili veya ilintisiz olabilecek kimi kavramların ortak özelliklerini soyutlamaya yarayan kategoriler Java'da arayüz üstkavramı ile karşılık bulurlar; bir arayüzün tanımlanması, Java sınıf kitaplığını o arayüzü gerçekleştiren ve gerçekleştirmeyen sınıflar olmak üzere iki kategoriye ayırır. Bu tanımda altı çizilmesi gereken noktalar, aynı arayüzü gerçekleştiren sınıfların birbirleriyle ilintisiz olma ve kimi sınıfların arayüzü gerçekleştirmeme olasılığıdır. Örneğin, karşılaştırılabilir sınıflar, Öğretmen ve Müstahdem gibi ortak üstsınıfları (Çalışan) yoluyla ilintilendirilebilirken, tamsayılar ve vergi mükellefleri gibi alakasız da olabilirler. Aynı şekilde, tamsayılar karşılaştırılabilirlik özelliği taşırken, disk dosyalarını soyutlayan sınıfların aynı özelliği taşıması beklenmez.³

Karşılaştırılabilir.java

public interface Karşılaştırılabilir {
  public int karşılaştır(Object);
  /* public static final */ String
    BELİRLEYİCİ_KOMİTE = "Ağır Abiler, A.Ş.";
} // Karşılaştırılabilir arayüzünün sonu

Arayüz tanımı, destekleyen sınıfların gerçekleştirmesi zorunlu olan iletilerin imzalarını ve bu sınıfların üyesi olan nesnelerin tümü için değişmeyen özellikleri içerir. Örneğin, yukarıdaki arayüz karşılaştır adlı bir iletiyi gerçekleştiren sınıflara ait nesneleri soyutlarken, bu nesnelerin ele alınması esnasında yararlanılacak bir sabit tanımlamaktadır.

Arayüz tanımının kuru kuruya kullanıcılara sağlanması pek yararlı olmayacaktır; arayüzü belirleyen geliştiricilerin, arayüzün gerçekleştirimleri arasında tutarlılığı sağlamak adına, derleyicinin kullanım doğruluğu denetimleri için gerekli olan yukarıdaki sözdizimsel tanımın yanısıra, arayüzdeki öğelerin anlamlarına dair açıklamaları da sağlaması gerekir. Örneğin, karşılaştır iletisinin imzasının sağlanması yalnız başına bir işe yaramayacaktır; iletinin ne yaptığına, parametrelerin ve döndürülen değerin ne anlama geldiğine aşağıdaki gibi açıklık getirilmelidir. Yani, arayüzün sözdizimsel tanımına ek olarak anlambilimsel açıklamasının da sağlanması gereklidir.

karşılaştır iletisi, hedef nesne ile argümanda geçirilen nesneyi karşılaştırır. Hedef nesnenin büyük olması durumu döndürülen pozitif bir int ile bildirilirken, eşitlik durumu 0 ile, küçük olma durumu ise negatif bir int ile bildirilir. Hedef nesne ile argümandaki nesnenin uyumsuz olması, kullanıcıya ClassCastException ayrıksı durumuyla bildirilmelidir. Benzer şekilde, argümanda geçirilen tutacağın null olmasının, kullanıcıya NullPointerException ayrıksı durumuyla bildirilmesi beklenir.

Arayüzün gerçekleştirimci ile kullanıcıları arasında sözleşme görevi gören bir bağlantı noktası oluşturduğu unutulmamalıdır; hem gerçekleştirimci hem kullanıcı, arayüz tanımından değişik amaçlarla da olsa yararlanacaktır. Bu, arayüz tanımındaki bir değişikliğin, birbirlerinden çok farklı yerlerde bulunan pek çok kişinin kodunu değiştirmesi gibi maliyetli bir sonuca neden olabileceği anlamına gelir. Dolayısıyla, değişme ihtimali yüksek olan altalan tanımı ve metot gövdesi gibi gerçekleştirim ayrıntılarının arayüz tanımında yer almasına izin verilmez. Altalan ve metot gerçekleştirimlerinin olması gerektiği durumlarda, arayüz yerine soyut sınıf kullanımı düşünülmelidir.

Arayüz tanımındaki tüm öğelerin public erişimli ve tüm veri öğelerinin derleme anı sabiti—yani, static final ile nitelenmiş—olduğu varsayılır. Bunun nedeni, arayüzün, önceki paragrafta değindiğimiz gibi, birbirinden bağımsız gerçekleştirimci ve kullanıcılar arasında sözleşme görevini görmesidir; arayüzde değişmesi muhtemel ve kamuya açık olmayan gerçekleştirim ayrıntıları bulunamaz. [Müzik setinizin arayüzünde kullandırılmayan bir düğmenin bulunmasını mantıklı bulur musunuz?] Bu sayede kullanıcı, arayüzü hangi sınıf gerçekleştiriyor olursa olsun, arayüz tutacağını arkasındaki nesnenin türünden bağımsız bir şekilde ele alıp kodun yeniden kullanımını sağlayabilecektir. Bunu, aşağıdaki örnek üzerinden görelim.

public class Performans {
  ...
  public static void sırala(Karşılaştırılabilir[] veri) {
    if (veri.length <= 1) return;

    boolean takasYapıldı = false;
    int geçiş = 1;
    do {
      takasYapıldı = false;
      for (int i = 0; j < veri.length - geçiş; i++)
        if (veri[i].karşılaştır(veri[i + 1]) > 0) {
          Karşılaştırılabilir geçici = veri[i];
          veri[i] = veri[i + 1];
          veri[i + 1] = geçici;
          takasYapıldı = true;
        } // if sonu
      geçiş++;
    } while(geçiş < veri.length && takasYapıldı);
  } // void sırala(Karşılaştırılabilir[]) sonu
  ...
} // Performans sınıfının sonu

Yukarıdaki koda göre, sırala metodu Karşılaştırılabilir arayüzünü gerçekleştiren herhangi bir sınıfın nesnelerini gösteren tutacaklardan oluşan bir dizi alabilir. Metot içinde, geçirilen dizinin elemanlarının Karşılaştırılabilir arayüzünde listelenen özellikleri kullanılabilecektir. sırala metodunu nesnenin diğer özelliklerinden koparan bu kısıtlama, bir nesneye hangi iletilerin gönderilebileceğinin tutacak süzgecinden geçmesi gerektiği kuralı ile de uyumludur: arayüz tutacağı ile gösterilen bir nesneye, tutacağın izin verdiği—yani, ilişkin arayüzde listelenen—iletiler gönderilebilir; iletinin gönderilmesi sonrasında nesnenin ait olduğu sınıftaki aynı imzalı metot çağrılacaktır. Örneğin, programın çalıştırılması sonrasında yukarıda işaretlenmiş olan satırdaki gönderinin sonrasında hangi metodun çağrılacağına geçirilen dizinin eleman türüne göre çalışma anında dinamik iletimle karar verilecektir. Bir diğer deyişle, bir sınıftaki iletilerin söz konusu sınıfın kalıtlama [ilişkisi] ile ilişkilendirildiği altsınıfların nesnelerine gönderilmesi durumunda olduğu gibi, bir arayüzde listelenen iletiler, söz konusu arayüzün gerçekleştirme [ilişkisi] ile ilişkilendirildiği sınıfların nesnelerine gönderilmeleri durumunda çokbiçimli olarak davranır. Dolayısıyla, sırala Karşılaştırılabilir arayüzünü gerçekleştiren tüm sınıflar için işini sınıfın özelliklerine göre yaparak çalışacak ve bu sayede kodun yeniden kullanımını sağlayacaktır.

İlgilenenlerin bir arayüzü gerçekleştirmesi, ilişkin sınıf ile arayüz arasındaki gerçekleştirme ilişkisinin sınıf başlığında belirtilmesi ve arayüzde listelenen tüm iletilere karşılık metotların sağlanması ile mümkün olur. Sınıf ve arayüz arasındaki ilişki, sınıf adından sonra implements anahtar sözcüğü yoluyla belirtilir; kalıtlama ilişkisine dair bir bilginin bulunması durumunda, gerçekleştirme ilişkisine dair bilginin bunu takip etmesi gerekir.

public class Öğrenci implements Karşılaştırılabilir {
  ...
  public int karşılaştır(Object sağ) {
    if (this == sağ) return 0;

    Öğrenci sağTaraf = (Öğrenci) sağ;

    if (_ortalama > sağTaraf._ortalama) return 1;
    else if (_ortalama < sağTaraf._ortalama) return -1;
    if (_no > sağTaraf._no) return 1;
    else if (_no < sağTaraf._no) return -1;
      else return 0;
  } // int karşılaştır(Object) sonu
  ...
  private float _ortalama;
  private long _no;
} // Öğrenci sınıfının sonu

public class Öğretmen implements Karşılaştırılabilir {
  ...
  public int karşılaştır(Object sağ) {
    if (this == sağ) return 0;

    Öğretman sağTaraf = (Öğretmen) sağ;

    if (_ankNotu > sağTaraf._ankNotu) return 1;
    else if (_ankNotu < sağTaraf._ankNotu) return -1;
    if (_dersYükü > sağTaraf._dersYükü) return 1;
    else if (_dersYükü < sağTaraf._dersYükü) return -1;
      else return 0;
  } // int karşılaştır(Object) sonu
  ...
  private float _ankNotu;
  private int _dersYükü;
} // Öğretmen sınıfının sonu

Gerektiği durumlarda, bir sınıf birden çok sayıda arayüz gerçekleştirebilir; bu, gerçekleştirilen arayüzlerin birbirlerinden ',' ile ayrıldığı arayüz listesinin implements'ten sonra belirtilmesi ile mümkün olur. Böyle bir sınıfın kullanıcıları, bu sınıfa ait bir nesneyi sınıf ve üstsınıflarının tutacaklarının yanısıra herhangi bir arayüzünün tutacağı yoluyla da kullanabilir.

Kimi zaman, yeni bir arayüz daha önceden tanımlanmış olan bir arayüzün ileti listesine ekler yapılarak tanımlanabilir. Yazılımların sürüm değişikliği ile birlikte arayüzlerin yeni uyarlamalarının tanımlanması buna tipik bir örnektir. Bu gibi bir durumda, yeni arayüz sıfırdan tanımlanabileceği gibi, eski arayüzden kalıtlayacak şekilde tanımlanabilir. Bu yolu seçmenin getirisi, derleyicinin arayüzler arasındaki kalıtlama ilişkisini sınıflar arasındaki kalıtlamaya benzer bir şekilde yorumlayacak olmasıdır: yeni arayüz (altarayüz) eski arayüz (üstarayüz) gibidir; eski arayüzdeki iletilerin tümünü içeren yeni arayüzün tutacağı, eski arayüz türündeki tutacağın kullanıldığı her yerde kullanılabilir. Ne kastettiğimizi aşağıdaki tanımlar üzerinden görelim.

public interface A1 {
  void i1();
  void i2();
} // A1 arayüzünün sonu

public interface A2 extends A1 {
  void i1(int i);
  void i3();
} // A2 arayüzünün sonu

Sağlanan tanımlara göre, A2 arayüzünü destekleyen bir sınıfın A1'dekileri de içeren dört iletinin karşılığındaki metot gerçekleştirimlerini sağlaması gerekecektir: i1(), i2(), i1(int) ve i3().⁴ Bu noktada, arayüz kalıtlamanın, sınıf kalıtlamanın aksine, çoklu olduğu unutulmamalıdır. Yani, bir arayüz birden fazla üstarayüzden kalıtlayabilir. Çoklu arayüz kalıtlamadan yararlanıldığı durumlarda, üstarayüzlerden gelen öğelerin ad çakışmalarına dikkat edilmelidir. Aynı imzaya sahip olup değişik dönüş türüne sahip iletilerin kalıtlanması derleme hatasına neden olacağı gibi, aynı ada sahip olup değişik arayüzlerde farklı türlere ait tanımlanan sabitler, kullanıldıkları noktada derleme hatasına yol açacaklardır.

Son olarak, arayüzlerin önemli bir görevine değinerek yazımızı bitirelim: yazılım bileşenleri için standart oluşturmayı mümkün kılmaları. Bileşen standartları, bir bileşenin aynı arayüzleri destekleyen bir diğeri yerine tak-çıkar mantığıyla kodun güncelllenmesini gerektirmeden değiştirilmesine olanak tanır. [Yani, eskimesi nedeniyle doğramanızı değiştirmek istediğinizde duvarın yıkılmasına gerek olmayacaktır.] Bunu aşağıda verilen zamana göre sıraya dizilmiş çizelgeyi izleyerek görelim.

Bir grup uzman, ortaya çıkan ihtiyaç üzerine A1 arayüzünü tanımlar.
Ş1 şirketi, A1'i gerçekleştiren Ş1_A1 sınıfını piyasaya sürer.
Ş2 şirketi, Ş1'den Ş1_A1'i satın alır ve kendi programlarında kullanmaya başlar.
Ş3 şirketi, A1'i gerçekleştiren Ş3_A1 sınıfını piyasaya sürer.
Ş1_A1'in performansından muzdarip Ş2 şirketi, Ş3'ten Ş3_A1'i alır ve Ş1_A1'in yerine kullanmaya başlar.

Dikkat edilecek olursa, Ş3 şirketi Ş3_A1 sınıfını Ş2 sınıfının geliştirdiği programlardan sonra geliştirmiştir. Bir diğer deyişle, Ş2 şirketinin geliştirdiği programlar, kendilerinden sonra geliştirilen bileşenleri kullanmaktadır. Zaman içinde geleceğe yapılan bu yolculuk, arayüzlerin değişmez özellikler barındırması ve sözdizimlerinin yanısıra anlamlarının da tanımlanmak suretiyle gerçekleştirimci kullanıcı arasında bir sözleşme oluşturması ile mümkün olmaktadır.

Sınıflar
Kalıtlama

Obezlik örneğini çok da ilerilere götürmeyiniz. Çünkü, obez olan birisinin zayıflayarak zaman içinde bu özelliğini yitirmesi olanak dahilindedir ki, böylesine bir özelliğin, nesne yönelimli modelleme dünyasının arayüze benzer bir üstkavramı olan rol ile karşılanması daha doğru olacaktır. Arayüzler, ilişkin nesnelerin kaybetmeyeceği özelliklerini tanımlayabilir. ↑
Sağladığımız çözümdeki türlerin soysal tanımlanarak daha güvenli bir çözümün mümkün olduğunun bilinmesinde yarar var. ↑
Aslına bakılacak olursa, karşılaştırılabilirlik kategorisi Java platformundaki Comparable arayüzü tarafından hali hazırda tanımlanmıştır. Dolayısıyla, Karşılaştırılabilir arayüzüne gerek yoktur. ↑
Yeri gelmişken tekrar hatırlatalım: dönüş türü Java'da aynı aduzayındeki iletileri (ve metotları) ayrıştırmak için kullanılmaz. Dolayısıyla, A2'ye int dönüş türlü i1() iletisinin eklenmesi, ortaya çıkan muğlaklık nedeniyle, derleme hatasına yol açacaktır. ↑

Türlerin Evrimi ya da Kalıtlama

2011-08-22T12:31:00.001+03:00

Bir şirketin rekabet gücü, hangi alanda faaliyet gösteriyor olursa olsun, şirket içinde tanımlanmış süreçlerin verimli yönetilmesiyle artar. Rekabetin üst düzeyde olduğu ve zamanın çok hızlı aktığı bir sektörde yer alan yazılım şirketleri için bu, alandaki bir problemin düşük hata oranlı, ucuz, randımanlı ve nitelikli bir programa dönüştürülmesinin daha hızlı yapılması demektir. Böylesine zorlu bir amaca erişmek ise daha önceden harcanmış çabaları yinelemekten kaçınarak olanaklı hale gelebilir. Yeniden kullanım—yani, daha önceden geliştirilmiş bileşenlerin kullanımı—aşağıdaki yazılım ölçülerini olumlu bir şekilde etkileyecektir.

Hata oranı: Önceden geliştirilmiş bileşenler daha yoğun kullanılıp sınanmış olacağından, bu bileşenleri içeren son ürün daha düşük bir hata oranına sahip olacaktır.
Maliyet: Önceden geliştirilmiş bileşenlerin yeniden geliştirilmesine kaynak harcanmayacağı, bu bileşenlerin sadece kullanımı söz konusu olacağı için üretim maliyeti düşecektir.
İşlevsel nitelik: Önceden geliştirilmiş bileşenleri yeniden geliştirmekte harcanacak zamanın bir bölümü var olan bileşenlere yeni özellikler eklemekte kullanılabileceği için son ürün daha nitelikli olacaktır.
Geliştirme zamanı:¹ Önceden geliştirilmiş bir bileşeni kullanmak aynı bileşeni ikinci bir defa geliştirmekten daha hızlı yapılacağı için son ürün daha hızlı bir şekilde üretilecektir.
Kaynak verimliliği: Önceden geliştirilmiş bileşenler daha yoğun eniyilenmiş olacakları için bu tür bileşenlerden oluşturulan son ürün daha hızlı ve/veya daha az bellek tutacak şekilde geliştirilecektir.

Dolayısıyla, yazılım geliştirme sürecinin tüm aşamalarındaki ürünlerin olabildiğince yeniden kullanılan bileşenlerle geliştirilmeye çalışılması bir gerekliliktir. Bu, yazımızın konusu olan kalıtlamanın nesne yönelimlilik bağlamında neden öne çıkarıldığının başlıca sebebidir: kalıtlama, kodun² yeniden kullanımını sağlayan araçlardan biridir. Burada, çok önemli bir noktaya vurgu yapmakta yarar var: kalıtlama bir araçtır, amaç değil; amaç kodun yeniden kullanılması yoluyla yazılımın yukarıda anılan ölçüleri olumlu etkileyecek bir biçimde geliştirilmesidir. Aklınızda olsun!

Yazımızın başlığındaki anıştırmayı açarak başlayalım. Ortaçağ'da takılmayanlarınız bilir; birey olarak sahip olduğumuz biyolojik özellikler, türümüzün kollektif DNA'sındaki genlerin milyarlarca yıldır sürdürdükleri bir ölüm kalım savaşının sonrasında ebeveynlerimizin söz konusu genleri bize aktarmasıyla ortaya çıkar. Kimi zaman, bireyin oluşması³ sürecindeki mutasyonlar, onu (ve onun gen haritasından üretilecek bireyleri) türün geri kalanından farklı kılar. Nadiren de olsa, biriken mutasyonlar, çevresel etkenlerce "ödüllendirilerek" yeni bir türün doğmasına neden olabilir. Belki de, başka bir yerde başka bir zamanda, temel türün geri kalan bireylerini etkileyen mutasyonlar da olacaktır. Artık, birbirine benzeyen iki tür vardır ve bu benzerlik türlerin tarihçelerini anlatmakta kulanılma gibi bir soyut varoluşa indirgenen temel türde gizlidir; Tabiat Ana, ekonomik davranmış ve yeni türleri oluştururken temel türü yeniden kullanmıştır.

Evrim dersimizi burada keserek, Java programlamada kalıtlama ne şekilde ifade edilebilir, ona bir bakalım. Ancak, önce anlatımımızda yararlanacağımız pedagojik senaryoyu ortaya koyalım. Mekânımız, öğrenci ve çalışanlarla dolu bir ilköğretim okulu koridoru; görevimiz, sürdürmekte olduğumuz bir bilimsel çalışma için koridordan geçmekte olan kişilere soru sorarak veri toplamak; amacımız ise, işimizi en kısa sürede bitirmek. Amacımıza doğru kişilere doğru soruları yöneltirsek daha kolay erişebiliriz. Örneğin, herkese "Adınız ne?" sorusunu yöneltmek mümkünken, görünüşü öğrenci olduğunu haykıran birine "Kaç çocuğunuz var?" sorusunu yöneltmek pek de akıl kârı olmayacaktır. Kimi zaman, farklı gruptan kişilere aynı soruyu yöneltebilmemize karşın, yanıtın elde ediliş biçimi muhatabın ait olduğu gruba göre değişebilir. Örneğin, aylık gelir sorulduğunda, yanıt müstahdem için maaş ve ekstraların toplanmasıyla bulunurken, öğretmen için verilen özel derslerin ücretinin de eklenmesi gerekecektir.

Kişi: Ad ...

Çalışan: Çocuk sayısı, maaş, ekstra gelir, toplam aylık gelir ...

Öğretmen: Verilen dersler, özel ders geliri ...
Müstahdem: Kömür yardımı, ...

Öğrenci: Sınıf ...

O zaman, gelin yukarıda verilen özeti Java'da nasıl ifade edeceğimize bakalım. Bunu yaparken de, işimize evrim saatini işletmeye başlayan ve koridordan geçen herkesin ortak noktalarını tanımlayan kişi kavramını gerçekleştirmekle girişelim.

Kişi.java

public abstract class Kişi {
  ...
  public final String ad() { return _ad; }
  protected final void adDeğiştir(String yeniAd) {
    _ad = yeniAd;
  } // void adDeğiştir(String) sonu
  ...
  private String _ad;
} // Kişi sınıfının sonu

Kişi muhatap = new Kişi(...); // Derleme hatası!

Sağlanan kod parçasına bakıldığında göze ilk çarpan, Kişi sınıfının, nesnesinin yaratılamayacağını belirtecek şekilde abstract nitelenmek suretiyle, soyut sınıf olarak tanımlanmış olmasıdır. Bu çeşit sınıflar, kendisinden kalıtlamak suretiyle türetilecek sınıfların gerçekleştirilmesi bağlamında çerçeveyi çizmek amacıyla tanımlanırlar. Örneğimizde, koridordan geçmekte olan kişinin hangi grupta olmasına bağlı olmaksızın geçerli olan ad bilgisinin sorgulanması ve güncellenmesi işlemleri gerçekleştirilmiş ve böylece söz konusu işlemin diğer sınıflarda yinelenmesinin önüne geçilmiştir. Sağlanan yeniden kullanım sayesinde, değişiklik gereksiniminin belirmesi durumunda veya ortaya çıkan bir hatanın giderilmesi istendiğinde, bakılması gerekecek yer sayısı bire indirilmiş ve böylece kodun bakımı kolaylaştırılmıştır.

Göze çarpan ikinci nokta, adDeğiştir metodunun tanımında kullanılan niteleyici: protected. Bu erişim niteleyicisi, ilişkin öğeye, ait olduğu sınıfın paketindeki ve aynı sınıfın kökü olduğu kalıtım sıradüzenindeki sınıflar tarafından erişim izni verildiğini söylüyor. Buna göre, adDeğiştir metodu Kişi ve dolaylı veya dolaysız Kişi'den kalıtlayan sınıflara ve Kişi ile aynı paketteki sınıflara public gibi gözükürken, diğer sınıflara private gibi gözükecektir.

Açıklamaya muhtaç bir diğer nokta, metotlarımızı nitelemekte kullandığımız final. İliştirildiği programlama öğesinin tanımında aldığı değerin daha sonra değişmeyeceğini ilan eden bu niteleyicinin kullanımı, söz konusu öğenin veri olması durumunda sabitliğe işaret ederken, örneğimizde olduğu gibi bir davranışsal öğeyi nitelemesi durumunda bu öğeye içinde bulunulan sınıftan türetilecek altsınıflarda ezilmek suretiyle yeni bir gerçekleştirim sağlanamayacağını belirtir.

Peki ama Java'da kalıtlama nasıl ifade edilir? Yani, bir kavramın bir diğeri gibi olduğuna dair gözlemimizi Java kaynak koduna nasıl aktarabiliriz? Yanıt oldukça basit: türetilmekte olan sınıfın tanımında sınıf adını takiben kullanılan extends ile sınıfı üstsınıfa bağlamak işimizi görür.

Öğrenci.java

public class Öğrenci extends Kişi {
  ...
  public String sınıfı() { return _sınıf; }
  ...
  private int _sınıf;
} // Öğrenci sınıfının sonu

Yukarıdaki tanıma göre, Öğrenci sınıfının Kişi'den türetildiğini gören derleyici, Öğrenci nesnelerinin Kişi nesneleri gibi olduğunu ve bunun sonucu olarak Kişi'de tanımlanan iletileri de alabileceğini bilir. Bundan dolayıdır ki, aşağıdaki çıktı komutu, gönderilen ileti Öğrenci sınıfında bulunmamasına rağmen bekleneni yapacak ve öğr ile temsil edilen öğrencinin Kişi'den kalıtladığı ad özelliğini çıktı ortamına basacaktır.

Öğrenci öğr = new Öğrenci(...);
System.out.println(öğr.ad());

Bu noktada, C++ ile nesne yönelimli programlama yapanlara iki hatırlatma yapmakta yarar var. Öncelikle, Java'da sınıf kalıtlaması teklidir; bir sınıf sadece bir sınıftan türetilebilir.⁴ Ayrıca, sınıf tanımı başlığında belirtilmemiş olsa bile, her sınıf bir diğerinden kalıtlar; üstsınıf bilgisinin eksik olduğu tanımlarda, sınıfın Object sınıfından kalıtladığı varsayılır. Dolayısıyla, şu ana kadar ki kısmi sınıf sıradüzeni şöyle oluşacaktır.

Object

Kişi

Öğrenci

Buna göre, Öğrenci nesneleri, geçişli olan gibi olmak ilişkisi nedeniyle, Öğrenci ve Kişi sınıflarındaki iletilerin yanısıra, Object sınıfındaki equals, toString gibi iletilere de yanıt verecektir.

Gelelim, koridorda rastlayacağımız çalışanların ortak yönlerini temsil etmek için sağlayacağımız sınıfa. Aşağıdaki kod parçasından da görülebileceği gibi, müstahdem ve öğretmenlerin paylaştığı fakat öğrencilerin sahip olmadıkları özellikleri soyutlayan bu sınıf, Kişi sınıfı gibi soyut tanımlanmış. Sınıfın soyut olmasına ek olarak, metotlardan biri de (sızlan) soyut ilan edilmiş. Bu, içinde bulunulan sınıfta söz konusu iletiye dair bir metot gövdesi sağlanmayacağı anlamına gelir.

Çalışan.java

public abstract class Çalışan extends Kişi {
  ...
  public int aylıkGelir() { return _ekstralar + _maaş; }
  public final int çocukSayısı() { return _çckSayısı; }
  public abstract void sızlan();
  ...
  private int _çckSayısı, _ekstralar, _maaş;
} // Çalışan sınıfının sonu

abstract ilan edilen bir metot, içinde bulunduğu sınıfı da otomatikman soyut kılar. Çünkü, metot gövdesinin bulunmaması ilişkin iletinin nesneye gönderilmesi durumunda çağrılacak bir metodun olmaması anlamına gelir ki. bu, arayüzde listelenen bir işlevin yerine getirilmediği anlamını taşır. [Müzik setinizdeki ses düğmesinin (ileti) donanımdaki devrelere (metot) bağlı olmadığı için işlev görmemesinin pek de mantıklı olmadığını takdir edersiniz.] Çözüm, bu tür aykırı durumların önüne geçmek için ortaya çıkmalarını engellemekten geçer. Dolayısıyla, sınıfın da abstract ilan edilmesi gereklidir.

Farkındayım, çok uzun oldu. Ama, işin en heyecanlı kısmına geldik. Onun için biraz daha sabredin de birlikte aşağıda verilen Öğretmen sınıfının gerçekleştirimine göz atalım. Somut—yani, nesnesi yaratılabilir— bir sınıf olarak tanımlanan Öğretmen sınıfında daha önceden görmediğimiz iki şey var: Override açımlaması≝ ve super ayrılmış sözcüğü.

Öğretmen.java

import java.util.Vector;

public class Öğretmen extends Çalışan {
  ...
  @Override
  public int aylıkGelir() {
    return super.aylıkGelir() + _özelDersGeliri;
  } // int aylıkGelir() sonu

  @Override
  public void sızlan() {
    System.out.print("Ne olacak bu memleketin hali!!!");
  } // void sızlan() sonu

  public Vector<String> dersler() {
    return _verdiğiDersler;
  } // Vector<String> dersler() sonu
  ...
  private int _özelDersGeliri;
  private Vector<String> _verdiğiDersler;
} // Öğretmen sınıfının sonu

super, içinde bulunulan sınıfın üstsınıfındaki bir özelliğin kullanılmak istendiğini belirtir. Buna göre, öğretmenlerin gelirleri, Çalışan sınıfında sağlanan toplama özel derslerden alınan ücretin eklenmesi ile hesaplanacaktır. super'in konulmaması, metodun kendisini çağırarak sonsuz döngüye girmesine neden olacaktır.

@Override açımlaması, iliştirildiği metodun kalıtlanılan aynı imzalı bir metodu ezmekte olduğunu ilan eder. Bundan hareketle derleyici, üstsınıflarda—Object, Kişi ve Çalışan— bu imzaya sahip bir metodun varlığını denetler ve sonucun olumsuz olması durumunda hata vererek derlemeyi durdurur. Zorunlu olmayan bu açımlamanın kullanılması, metot imzasının yanlış yazılması durumunda ortaya çıkabilecek sinsi mantık hatalarının önüne geçilmesine yarar. Örnek olarak, yukarıdaki kod parçasında aylıkGelir yerine yanlışlıkla aylıkgelir yazdığınızı düşünün. @Override açımlaması olmadan yazıldığı takdirde, derleyici aylıkgelir ve aylıkGelir iletilerine karşılık, biri üstsınıftan kalıtlanan diğeri sınıf tarafından sağlanan, iki metot bulunduğunu düşünecektir. @Override açımlamasının kullanılması durumunda ise, metot adlarındaki küçük farklılık görülecek ve yazım hatası mantıksal hataya dönüşmeden derleme hatası olarak yakalanacaktır.

Peki ama o zaman, Öğretmen sınıfındaki sızlan metodu @Override ile açımlanırken neden aşağıda verilen Müstahdem sınıfındaki aynı imzalı metot açımlanmamıştır? İşin sırrı, sızlan metodunun üstsınıfta soyut tanımlanmış olmasında yatmaktadır. Bu, somut bir altsınıfın anılan metoda dair bir gerçekleştirim vermeden kullanılamayacağı anlamına gelir; altsınıfta sızlan metodunun sağlanmaması, derleyici tarafından yakalanacak ve gerçekleştirim sağlanmadıkça derleme hatası ortadan kalkmayacaktır. Yani, metodun üstsınıfta soyut ilan edilmesi zaten @Override açımlamasının görevini görmektedir; söz konusu metodun ayrıca açımlanması gereksizdir.

Müstahdem.java

public class Müstahdem extends Çalışan {
  ...
  public boolean kömürYardımı { return _kömürYardımı; }

  public void sızlan() {
    System.out.print("Allah devletimize milletimize zeval vermesin!!!");
  } // void sızlan() sonu
  ...
  private boolean _kömürYardımı;
} // Müstahdem sınıfının sonu

Evet, problemimizde geçen kavramlara karşılık gelen sınıfları gerçekleştirdik. Sıra, bu sınıfları ve bu sınıfların nesnelerini nasıl kullanabileceğimizi anlamaya geldi. Aşağıdaki kod parçasını takip ederek görelim.

Çalışan birisi;
if (Math.random() > 0.5)
  birisi = new Öğretmen(...);
  else birisi = new Müstahdem(...);
System.out.print(birisi.aylıkGelir());
System.out.print(birisi.dersler()); // Derleme hatası!

Kod parçasına göre, Çalışan türünde ilan edilen birisi adlı tutacak, üretilen rastgele sayıya göre kimi zaman bir Öğretmen nesnesini gösterirken kimi zaman bir Müstahdem nesnesini göterecektir. Bu bağlamda, iki nokta sizi kod parçamızda hata olabileceği düşüncesine sevkedebilir.

Nasıl olur da, soyut tanımlanan Çalışan sınıfı birisi adlı değişkenin türünü tanımlamakta kullanılabilir? Yanıt: Bileşke türden değerlerin tutacak ve nesne olmak üzere iki kısımdan oluştuğunu unutmuşa benziyorsunuz; burada yaptığımız nesne yaratmak değil, nesne iliştirilmemiş bir tutacak tanımlamak. [Bileşke türlerin bu özelliği size yabancı geliyorsa, şu yazıyı🔎 okumanızı tavsiye ederim.]
Nasıl olur da, Çalışan türündeki bir tutacak Öğretmen veya Müstahdem türünde bir nesne gösterebilir? Yanıt: her iki sınıfın nesneleri de Çalışan merceğinden görülebilir. Ne de olsa, öğretmen veya müstahdem, her ikisi de bir çalışandır. Ancak, nesne ne türden olursa olsun, birisi tutacağı yoluyla arkadaki nesneye Çalışan sınıfının arayüzünde bulunmayan iletiler gönderilemez.

Örneğimize derleyicinin gözlerinden bakarak ikinci maddeyi açalım. Birincil görevi koddaki tanımlayıcıların ilan edildiklerine uygun bir biçimde kullanıldığını denetlemek olan derleyici, birisi adlı değişkenin doğru kullanıldığını garanti etmek isteyecektir. Bu, birisi vasıtasıyla arkadaki nesnenin doğru kullanılmasının—yani, nesneye anlayabileceği iletilerin gönderilmesinin—her koşulda sağlanması demektir. Örneğimizi, durum durum ele alarak görelim.

birisi'nin arkasındaki nesne Öğretmen türünde: Nesnemiz, Öğretmen sınıfının arayüzündeki iletilere yanıt verebilir. Bu iletiler, Object, Kişi, Çalışan ve Öğretmen sınıflarının arayüzlerindeki iletilerin bileşkesidir.
birisi'nin arkasındaki nesne Müstahdem türünde: Nesnemiz, Müstahdem sınıfının arayüzündeki iletilere yanıt verebilir. Bu iletiler, Object, Kişi, Çalışan ve Müstahdem sınıflarının arayüzlerindeki iletilerin bileşkesidir.

Aynı kodun kullanılıyor olmasına karşın, programın çalışması sırasında rastgele sayı üretecinin döndürdüğü değere göre dinamik olarak belirlenen kullanım senaryosu, doğruluk denetimi esnasında elinde kaynak kod ve kaynak kodun derlenmiş hali olan sınıf dosyalarından başka bir şey bulunmayan derleyicinin nesnenin türünden yararlanarak karar veremeyeceği anlamına gelir. Programı çalıştırarak nesnenin hangi sınıfa ait olacağını görme lüksü olmayan derleyici, görevini koddan çıkarsayabileceği bilgilerle görmek zorundadır. Aradığımız bilgi, nesnelere erişimde aracılık eden tutacaktadır: Derleyici, nesnenin doğru kullanımını denetlemek için statik tür olarak da adlandırılan tutacak türünü kullanır. Yani, bir nesneye hangi iletilerin gönderilebileceğine nesneyi gösteren tutacağın türü kullanılarak karar verilir. Bundan dolayıdır ki, derleyici birisi'nin arkasındaki nesneye dersler iletisinin gönderilmesine izin vermeyecektir. Çünkü, Çalışan türündeki bir tutacak, Çalışan'ın kökü olduğu sınıf sıradüzeni içindeki somut sınıfların türünden olan nesneleri gösterebilir ve bu nesnelerin bazıları Öğretmen'e özel dersler iletisini anlamaz.

Peki, gönderilmesine izin verilen bir ileti, hangi metodun çağrılmasına yol açar? Buna, koridorda rastladığımız çalışanlara aylık gelirlerini sorduğumuz senaryoyu düşünerek yanıt vermeye çalışalım. Çalışanın müstahdem olması durumunda yanıt, maaş ve ek gelirlerin toplanması ile verilirken, muhatabımızın öğretmen olması durumunda maaş ve ek gelirlere özel derslerden alınan ücretlerin eklenmesi gerekecektir. İşin kısası, aynı soru muhatabımızın özelliklerine bağlı olarak farklı yöntemler kullanılarak yanıtlanacaktır. Vardığımız sonucu programlama sözlükçemiz ile ifade edecek olursak, aynı gönderinin (ileti gönderme) farklı metotların çağrılmasına neden olabileceğini söyleyebiliriz. Çokbiçimlilik olarak adlandırılan bu özelliğin örneği, aylıkGelir iletisinin gönderilmesinde görülebilir: birisi'nin süzgecinden geçen aylıkGelir iletisi, rastgele sayı üreticinin döndürdüğü değere bağlı olarak yaratılan nesnenin türüne—dinamik tür olarak da adlandırılır—göre ya Öğretmen sınıfındaki ya da Müstahdem sınıfındaki aynı imzalı metodun çağrılmasına neden olacaktır. Yani, bir nesneye gönderilen ileti sonucu hangi metodun çağrılacağına nesnenin türüne bakılarak karar verilir. Bir iletinin çağrılacak metoda çalışma anında bağlanmasına ise dinamik iletim denir.

Özetleyecek olursak;

Öncelikle, derleme sırasında tutacak türü kullanılarak gönderinin doğruluk denetimi yapılır. Bu denetim sırasında, farklı imzalara sahip iletiler farklı addedilir.
Programın çalışması sırasında, nesnenin türüne bakılarak hangi metodun çağrılacağına karar verilir.

Evet, kalıtlama ile ilgili ilk yazımız için bu kadar yeter sanırım. Aklınızdan çıkmaması gereken şu sloganı yineleyerek kapatalım: kalıtlama bir araçtır, amaç değil; amaç kodun yeniden kullanılması yoluyla yazılımın yukarıda anılan ölçüleri olumlu etkileyecek bir biçimde geliştirilmesidir.

Sınıflar
Arayüzler

Altını çizmekte yarar var; en son okudukları programlama kitabı 16 ikillik mimarilerin teknoloji harikası olarak tanıtıldığı yıllarda basılmış kişilerin aksine, bir sonraki maddede atıfta bulunulan çalışma hızının artırılmasından bahsetmiyoruz. Bilgisayar donanımının görece değerinin azalıp, en değerli kaynak olarak yerini geliştiriciye bıraktığını vurgulamak için geliştirme zamanı diyoruz. Nedenimiz basit: aklı başında şirket yöneticileri, düşük maliyetli bir kaynaktan (işlemci, bellek, vb.) ziyade yüksek maliyetli kaynağın (insan) verimliliğini artırmaya öncelik verir. Ancak bu, düşük maliyetli kaynağın har vurup harman savrularak kullanılabileceği anlamına gelmemelidir. ↑
Kalıtlama, çözümleme ve tasarım aşamalarında da kullanılan bir araçtır. Ancak, yazımızda kalıtlamanın Java programı yazarken nasıl kullanılabileceğine değinmekle yetineceğiz. ↑
Aslında, yapılan araştırmalar, mutasyonların bireyin yaşamı sırasında maruz kaldığı yüksek radyasyon nedeniyle de olabileceğini gösteriyor. ↑
Eksiklik gibi gözüken bu durum, çoğu zaman sınıfların arayüz(ler) gerçekleştirmesi ile giderilebilir. ↑

Java ve J'li Harf Çorbası

2011-08-17T14:54:00.000+03:00

Java programlamaya başlayanların aklını karıştıran konuların başında, ekseriye J ile başlayan teknoloji, standart ve ürün adları gelir. Çoğu zaman arka planda ne olup bittiğinin bilinmemesinden kaynaklanan bu durum, pek çok zamansa Sun şirketinin seçtiği (ve değiştirdiği) adlandırma biçiminden kaynaklanır.

İnternet olgusunun ayırdındaki herkesin bildiği ve yazıya giriş tümcesinden de anlaşılabileceği gibi, Java gözde bir programlama dilinin adıdır. Java kullanılarak yazılan programlar, genelde derlemeli-yorumlama yöntemi ile çalıştırılır. Yani; Java kaynak kodu önce derlenerek [Bytecode adındaki] bir ara dilin komutlarını içeren sınıf dosyalarına çevrilir, sonra Java Sanal Makinesi (JSM; İng., Java Virtual Machine [JVM]) adı verilen bir diğer sistem yazılımı tarafından çalıştırılır. JSM, Bytecode komutlarından oluşan sınıf dosyalarını yorumlamanın yanısıra, sınıf yükleme ve çalıştırma sırasında güvenlik denetimleri de yapar. Örneğin, derleme ile yükleme arasında geçen zaman zarfında sınıf dosyasında oluşabilecek değişiklikler, sınıfın yüklenmesi sırasında yapılan sağlamalar ile saptanabilir. Böylece, kimi kötü niyetle yapılan değişikliklerin kullanıcıya zarar vermesinin önüne geçilmiş olur. Benzer şekilde, programı çalıştıran kullanıcının yetkisiz olduğu güvenlik zaafı yaratabilecek işlemler programın çalıştırılması sırasında yapılan denetimler ile engellenir. JSM'nin bir diğer önemli görevi, kullanılmaz hale gelmiş yığın bellek bölgelerini toplayan çöp toplayıcı bileşeni yoluyla kaynak yönetimini kolaylaştırmaktır. Bu sayede, Java programcıları kaynak yönetimine dönük daha az kod yazacaklar ve bunun sonucunda üretilen kod daha güvenilir olacaktır.

Rekabete açık bir sektör olan yazılım geliştirme işinde başarıya giden yol, olabildiğince az kaynak (geliştirici zamanı, bilgisayar zamanı ve belleği, vb.) kullanarak piyasanın rağbet edeceği nitelikli ürünleri en kısa sürede geliştirip piyasaya sürmekten geçer. Bu bağlamda uygulanan evrensel kural, aynı ürünün tekrar tekrar geliştirilmesinden kaçınarak daha önceden yapılmış eş işlevli bir ürünün kullanılmasıdır. Yeniden geliştirme için harcanacak zamanın ürünün eniyileştirilmesi ve son ürüne tümleştirilmesine ayrılması, daha güvenilir ve daha yüksek performanslı yazılım üretilmesini olanaklı kılacaktır. İşte bu noktada, Java geliştiricisinin hizmetine Java ortamı (platform) adı verilen standart kitaplıklar sunulur. Söz konusu ortam, hedeflenen kitleye bağlı olarak farklı işlevsellikler sunabilir ve buna bağlı olarak değişik şekillerde adlandırılabilir. Java SE, standart (dizüstülü/masaüstülü) geliştiriciye hitap ederken, Java EE başta İnternet olmak üzere dağıtık ortamlarda çalışacak sunucu tarafı programların geliştirilmesini kolaylaştıran yazılım çerçeveleri içerir; Java ME ise mobil aygıtlar başta olmak üzere gömük sistemler düşünülerek hazırlanmıştır.

Java platformlarının oluşturulması, Java Topluluğu'nun ortaklaşa çabasıyla ortaya çıkarılan çeşitli standartların ürün haline getirilmesiyle mümkün olur. Örneğin, programcıların sıklıkla ihtiyaç duydukları veri yapılarına dair arayüz/sınıf tanımlarının bulunduğu Java Kapları (İng., Java Collections) Java SE'nin bir parçası iken, bileşen temelli dağıtık sunucu programları geliştirmekte kullanılan Java Şirket Taneleri (İng., Enterprise Java Beans [EJB]) Java EE'nin bir parçasıdır.

Java geliştiricileri çalıştıkları platformdaki sınıf dosyası kitaplıklarına ek olarak, yazılım geliştirmenin değişik aşamalarında kullanılmak üzere, derleyici, JSM, arşivci ve dokümantasyon aracı gibi bir çok sistem programına ihtiyaç duyar. Bu araçlar ve platformun bileşkesi, Yazılım Geliştirme Kutusu (YGK; İng., Software Development Kit [SDK]) olarak adlandırılır. Söz konusu platformun Java SE olması durumunda, adlandırma Java Geliştirme Kutusu (JGK; İng., Java Development Kit [JDK]) şeklinde yapılır.

Java kaynak kodu yazmaktansa Java platformunda hazırlanmış programları kullananların geliştirme araçlarının tümüne ihtiyacı olmaz. Örneğin, bu kişiler programları çalıştırmak için JSM'ne ihtiyaç duyarken, derleyici ve arşivci gibi sistem programlarına ihtiyaç duymayacaklardır. Sadece kullanıcı olmak özelliği taşıyan bu kişiler için Java Çalıştırma Ortamı (JÇO; İng., Java Runtime Environment [JRE]) yeterli olacaktır.

Pek çok zaman, kullanılan platform hangisi olursa olsun, Java geliştiricileri ilişkin kısaltmayı da kısaltarak, Java SE/Java EE/JavaME yerine Java demek yoluna giderler. Ancak bu kullanımın programlama dili adı kullanımından ayırt edilmesi gerekir. Çünkü; en yaygın dilin Java olmasına karşın Java platformu, kaynak kodları sınıf dosyasına derlenebilen tüm dillere açıktır. Ne de olsa, programlar sınıf dosyalarının JSM üzerinde çalıştırılması ile işini görmektedir. Dolayısıyla, Python'un Java platformu uyarlaması olan Jython veya Groovy'nin platform indinde Java programlama dilinden hiçbir farkı yoktur. Ne demek istediğime aşağıdaki örnek üzerinden açıklık getireyim.

Sırasıyla, A ve B şirketleri tarafından yazılan a.groovy ve b.py dosyalarının derlenmesiyle elde edilen a.class ve b.class, iki şirketin ortak müşterilerinden birinin yazdığı Prog.java içinden kullanılmaktadır. Sınıf yolu (İng., classpath) ayarlarına uygun bir şekilde müşteri bilgisayarının erişimindeki disk konumlarına yerleştirilen bu dosyalar, Prog.java dosyasındaki ilişkin atıfların doğruluk denetimlerinin yapılması noktasında derleyici tarafından kullanılır. Derleyicinin kaynak kod yerine sınıf dosyasından yararlanabilmesini olanaklı kılan özellik, sınıf dosyası formatı ve dosyanın içeriğini oluşturan Bytecode komutlarının standardize edilmiş olmasıdır. Bir diğer deyişle, Java kaynak kodlarının taşınabilirliğine ek olarak, sınıf dosyaları da nesne kodu düzeyinde taşınabilirliğe sahiptir. Daha sonra, derleme sonucunun olumlu olması durumunda üretilen Prog.class, JSM'ne geçirilerek çalıştırılacak ve Java, Python ve Groovy dillerinin işlevsellik kattıkları program işini görecektir.

Bazı Önemli Sınıflar-java.util.Arrays

2011-08-16T15:50:00.001+03:00

Dizilere uygulanabilecek işlemlerin eleman erişim ve güncelleme ile uzunluk sorgulamaya sınırlı olması, size Java'da bir şeylerin eksik olduğunu düşündürebilir. Java platformu tasarımcıları da bu görüşü paylaşıyor olmalılar ki, java.util paketindeki Arrays sınıfı vasıtasıyla epey geniş bir işlevsellik sunmuşlar. İşte bu yazıda yapacağımız, anılan sınıf tarafından sağlanan ve değişik eleman türlerine göre ezilmiş metotlara bakmak olacak.

Kopyalama işlemi ile başlayalım. Dizileri tanıttığımız yazıdan🔎 da hatırlayacağınız gibi, dizi türlü bir değişkenin bir diğerine atanması, etkisini tutacaklar aracılığıyla göstereceği için kopyalama değil paylaşmaya neden olacaktır; kopyalama döngü içinde her elemanın teker teker kopyalanması ile mümkündür. Ancak, standart olmayan bu çözümün yerine, ilk argümanındaki dizinin başlangıcından itibaren ikinci argümandaki kadar elemanı kopyalayan ve çıkardığı kopyanın tutacağını döndüren Arrays.copyOf metodunun kullanılması yerinde olacaktır.

import java.util.Arrays;
...
Integer[] tekler = new Integer[] {1, 3, 5, 7, 9};
Integer[] tKopya = Arrays.copyOf(tekler, tekler.length);

Benzer bir işleve sahip Arrays.copyOfRange, ikinci ve üçüncü argümanlarının işaret ettiği indisler arasındaki dilimi kopyalayarak işini görür. Dolayısıyla, Arrays.copyOf ile Arrays.copyOfRange arasında şu denklik kurulabilir.

Arrays.copyOf(dz. i) ≡ Arrays.copyOf(dz, 0, i)

Bileşke türlü değerlerin Java'da tutacak ve nesne olmak üzere iki parça ile temsil edildiğini unutanları şaşırtacak bir diğer işlem eşitlik denetimidir. Ancak, == ile işin olmayacağını bilip şansını equals iletisi ile denemek isteyenler için de sonuç hayal kırıklığı olacaktır. Bu durumun nedeni dizi türlerinin Java programlama dili tarafından ele alınışında yatar: eleman sayısını dizinin türünü belirlemekte kullanmayan Java derleyicisi, her farklı eleman türü için, programcı tarafından doğrudan erişilemeyen ve Object sınıfından kalıtlayan özel bir sınıf sentezler. Bu bilgi, sentezlenen sınıflarda Object'teki equals gerçekleştiriminin ezilmediği bilgisiyle birleştirildiğinde, equals kullanımının neden derdimize çare olmadığı görülecektir: dizi nesnelerine equals iletisinin gönderilmesi Object'te sağlanan ve == ile aynı şekilde çalışan metodun işlemesine neden olacaktır. Bir diğer deyişle, dizi nesneleri için equals ile == arasında bir fark yoktur. O zaman, ne yapmamız gerek? Yanıt, Arrays sınıfındaki iki metottan birini kullanmaktan geçer. Bunlardan ilki, tek boyutlu dizilerin eşitlik denetimini yapan Arrays.equals metodudur.

boolean eşitMi = tekler == tKopya; // eşitMi ← false
eşitMi = tekler.equals(tKopya); // eşitMi ← false
eşitMi = Arrays.equals(tekler, tKopya); // eşitMi ← true

Arrays.equals metodunun neden tek boyutlu dizilere sınırlı olduğunu, çok boyutlu dizilerin Java'da nasıl temsil edildiğine bir kez daha değinerek açıklık getirelim: Java'da çok boyutlu diziler, elemanları dizi olan diziler şeklinde tutulur. Dolayısıyla, dizinin elemanlarına equals iletisini göndermek suretiyle işini gören Arrays.equals metodunun çok boyutlu diziler için iş görmesi olanaksızdır. Bunu, aşağıdaki kod parçası üzerinden görelim.

char[][] bulmaca = new char[10][12];
char[][] bulmaca2 = new char[10][12];
// Dizileri eşit içeriğe sahip olacak şekilde doldur
eşitMi = Arrays.equals(bulmaca, bulmaca2); // eşitMi ← false
eşitMi = Arrays.deepEquals(bulmaca, bulmaca2); // eşitMi ← true

Yukarıdaki dizilerin eşitlik denetimi için Arrays.equals metodunun kullanılması, dizilerin eleman türü olan ve derleyici tarafından sentezlenen char[] sınıfındaki equals metodunun kullanılması ile işini görecektir. Bu ise, söz konusu metodun == ile aynı şekilde çalışması nedeniyle, dizilerin karşılıklı elemanlarının eşitlik yerine aynılık denetimi yapılarak kontrol edilmesi anlamına gelir ve beklediğimiz sonucu vermez. Çözüm, Arrays.deepEquals metodunun kullanımından geçer.

Eşitlik denetimi için öne sürülen sebepten ötürü, hoş yazım ve kıyım işlemleri¹ de metot çiftleri ile karşılanır: Arrays.toString, Arrays.deepToString ve Arrays.hashCode, Arrays.deepHashCode.

Arrays sınıfında yer alan bir diğer metot, kendisine geçirilen dizinin elemanlarını aynı değer ile doldurmaya yarayan fill metodudur. Bu metot, dizinin tümü ve bir dilimi üzerinde etkisini gösteren iki farklı uyarlamaya sahiptir ve bu uyarlamalar aşağıdaki denklikle ilişkilendirilebilir.

Arrays.fill(dz. i) ≡ Arrays.fill(dz, 0, dz.length, i)

Değineceğimiz bir sonraki metot, belki de gezegenimizdeki kurulu bilgisayar sistemlerinin işlemcilerini en çok meşgul eden arama işleminin gerçekleştirimini sağlar. Algoritma derslerinden tanıdık ikili aramayı gerçekleştiren Arrays.binarySearch metodu, ilk argümanında sağlanan elemanları artan sırada dizilmiş dizinin içinde bir anahtar değerin geçip geçmediğine bakar. Denetim sonucunun olumlu olması durumunda, anahtarın geçtiği dizi elemanının indisi döndürülür;² aramanın başarısız olması durumunda ise, anahtarın sırayı bozmayacak şekilde diziye eklenmesi halinde eklemenin yapılacağı indisin -1 ile çarpımından 1 çıkarılması sonucu elde edilen değer döndürülür. Daha hızlı sonuç elde edilmesi amacıyla, arama dizinin belirli bir dilimine sınırlandırılabilir. Tüm dizi ve dizi dilimi üzerinde çalışan uyarlamalar arasındaki ilişki aşağıda verilmiştir.

Arrays.binarySearch(dz. anahtar)

≡

Arrays.binarySearch(dz, 0, dz.length, anahtar)

Arrays.binarySearch metodunun bileşke türlü elemanlara sahip bir dizide arama yapması öncesinde, ilişkin türe dair sınıfın gerçekleştiriminde equals metodunun uygun bir biçimde sağlanmış olmasına dikkat edilmelidir. Aksi takdirde, dizide var olan bir anahtarın bulunmadığının ilan edilmesi gibi bir hata ortaya çıkabilir. Böylesine bir durumun önüne geçmek için başvurulacak ikinci bir yol, java.util.Comparator arayüzünü gerçekleştiren karşılaştırıcı bir sınıfta equals iletisinin gerçekleştirilmesi ve bu sınıfın bir nesnesinin diğer argümanların ardından son argüman olarak Arrays.binarySearch'e geçirilmesidir.

İkili aramanın hünerini sıralı bir dizi üzerinde göstermesi, dizinin sıralı bir şekilde oluşturulması veya ikili arama öncesinde sıralanması zorunluluğunu da beraberinde getirir. Programcıya yüklenen bu sorumluluk, Arrays.sort metodu ile hafifletilebilir. İsteğe göre dizinin tümü veya belirli bir dilimini sıralayan bu metot, dizinin eleman türünün karşılaştırılabilir olmasını bekler. Bu ise, bileşke türler için ilişkin sınıfın Comparable arayüzünü gerçekleştirmesi ve/veya karşılaştırma ölçütünün java.util.Comparator arayüzünü gerçekleştiren bir sınıf vasıtasıyla söz konusu işlevselliğin sağlanması gerektiği anlamına gelir.

Arrays.sort(dz) ≡ Arrays.sort(dz, 0, dz.length)

Göz atacağımız son metot olan Arrays.asList, yegâne argümanındaki diziyi Veri Kapları Çerçevesi'nce tanımlanan java.util.List ve java.util.RandomAccess arayüzlerine sahip bir nesneye çevirir ve bu nesneyi gösteren bir java.util.List tutacağı döndürür. Nesneye gönderilen iletilerin diziyi de etkilemesi nedeniyle, bu işlem dizimizin işlevselliğinin java.util.List arayüzündeki iletilerle—java.util.RandomAccess bir gösterge arayüz≝ (İng., marker interface)³ olduğu için bu yönde bir katkı sağlamaz—genişletilmesini sağlar. Ancak, bu arayüzün veri kümesini büyütmeye yönelik iletilerinin, dizinin statik doğası nedeniyle, kullanılamayacağı unutulmamalıdır.

List<Integer> tList = Arrays.asList(tekler);
// tekler[2]'de 121 değerine sahip olacak.
tList.set(2, 121);
tList.add(123); // → UnsupportedOperationException

Diziler

Kıyım işlemi, doğrudan veya dolaylı bir biçimde dizi gibi rasgele erişimli veri yapılarının kullanıldığı arama algoritmalarında, aranan anahtar değerinin tamsayıya çevrilmesini sağlayarak rasgele erişimli veri yapılarının avantajlarından yararlanmayı olanaklı kılar. ↑
Aranmakta olan anahtar değerin dizi içinde birden çok geçmesi durumunda, hangi indisin döndürüleceği konusunda garantili bir tahmin yapılması olanaklı değildir. ↑
İleti içermeyen arayüzlere gösterge arayüz denir. ↑

Arşiv Dosyaları

2011-08-04T18:00:00.000+03:00

Java'nın kısa sürede yaygınlaşmasındaki önemli etkenlerden biri—belki de en önemlisi—Bytecode komutları içeren standardize edilmiş sınıf dosyalarının sanal makine üzerinde çalışmasıyla sağlanan makine kodu düzeyindeki taşınabilirlik özelliğidir. Java'nın doğum yeri olan Sun şirketi tarafından "Bir kez yaz, her yerde çalıştır" (İng., write once, run anywhere (WORA), write once, run everywhere (WORE)) sloganıyla tanıtılan bu özellik sayesinde, Java programlarının derlendikten sonra JSM bulunduran herhangi bir platformda çalıştırılması mümkün olmaktadır. Bunun için, gerekli sınıf dosyalarının konulduğu bir siteden indirilmek veya CD içinde verilmek suretiyle kullanıcıya sağlanması yeterli olacaktır.

[Geliştirici] Geliştirilen programı derleyerek sınıf dosyası haline çevir.
Sınıf dosyalarını kullanıcıya sağla.
[Kullanıcı] Programı çalıştır.

Yazılımın büyümesiyle birlikte yukarıdaki 2 nolu adıma konu olan dosyaların sayısı artacak ve bu da dağıtım işini zorlaştıracaktır. Ayrıca, gereksinilen disk alanı ve indirme zamanı da olumsuz etkilenecektir. Örnek olarak, 90'ların ortalarında Microsoft'un Wintel bağımlısı çözümlerine karşı alternatif olarak ortaya çıktığında büyük heyecan yaratan uygulamacıkların (İng., applet) örün tarayıcıları tarafından çalıştırılmasına göz atalım. Kendisine bağlantı veren sayfalara dinamik içerik sağlayan ve etkisini kullanıcı tarafında çalıştırılarak gösteren uygulamacıklar işlerini şöyle görür.

Kullanıcı uygulamacık bağlantısı barındıran bir sayfaya tıklar.
Sayfa ile birlikte uygulamacığı oluşturan sınıf dosyaları ve diğer kaynaklar (görüntü, ses, vb.) indirilir.
Uygulamacık, tarayıcıdaki JSM tarafından çalıştırılır.

Yukarıda kabaca anlatılan sürecin hızı, uygulamacığın gerçekleştiriminde seçilen algoritma ve veri yapıları seçimlerine ek olarak, 2. adımda indirilen dosyaların sayısı ve büyüklüğüne göre değişecektir. Dosyaların artması ve büyümesi performansı ve kullanıcı deneyimini olumsuz yönde etkileyecektir. İşte bundan dolayı—daha genel bir ifadeyle, yazılım dağıtımını daha etkin hale getirmek için—Java platformu tasarımcıları arşiv dosyalarını sağlamışlardır. Buna göre, geliştiricilerden beklenen, birlikte indirilecek/kurulacak dosya ve kaynakları sıkıştırarak bohçalayan arşiv dosyalarının kullanımıdır.

Arşiv Manipülasyonu

Arşiv dosyaları Yazılım Geliştirme Kutusu'nun parçası olan jar adlı arşivci komutu yardımı ile oluşturulabilir. Bu komut, ZIP-temelli formata sahip bir arşiv oluşturmanın yanısıra, verilen bir arşivin güncellenmesi, içeriğinin listelenmesi ve açılması için de kullanılabilir. Hangi işlemin kastedildiği komut adını takiben verilen ve aşağıdaki değerleri alabilen bir opsiyon ile belirtilir. Listelenenlere ek olarak, f opsiyonunun işlemin hedefi olan arşiv dosyasının adı için kullanıldığı bilinmelidir. Ayrıca, işlemin neler yaptığını daha ayrıntılı bir biçimde standart çıktıya basan v opsiyonu da kimi zaman yardımcı olabilir. Son olarak, girdi sağlanmasını gerektiren birden çok opsiyonun kullanılması durumunda, arşivcinin opsiyon sırası ile girdi sırasının aynı olduğunu varsaydığı unutulmamalıdır.¹

*Arşiv dosyası işlemleri*
Opsiyon	Anlamı
c	Oluşturma
u	Güncelleme
t	İçerik listeleme
x	Açma

Buna göre, aşağıdaki komut o anki çalışma dizininin içindeki a.class ve b.class dosyalarının yanısıra images dizininin içindeki dosyalardan oluşan ArşivDosyası.jar adlı bir arşiv yaratacaktır.² Dizin içindeki dosyaların ele alınması sırasında, altdizinlerin özyinelemeli bir biçimde işlendiği unutulmamalıdır. Yani, komutumuz images içindeki tüm dosyaları, altdizinler içindekiler de dahil olmak üzere, arşive katacaktır. Arşive nelerin girdiğini görmek isterseniz, v opsiyonu işinizi görecektir.

$ # Arşiv oluşturma
$ jar cf ArşivDosyası.jar a.class b.class images

İşlemin daha az zahmetli olmasını sağlamak için, dosya adı sağlama sırasında joker karakterinden yararlanılabilir. Örneğin, çalışma dizini içindeki sınıf dosyalarının a.class ve b.class'a sınırlı olması durumunda aşağıdaki komut yukarıdaki ile aynı işlevi görecektir.

$ jar cf ArşivDosyası.jar *.class images

Arşivin oluşturulması sırasında, girdi dosyalarının dizin yapısı korunur. Örneğin, yukarıdaki komutların icra edilmesi sonrasında a.class ve b.class arşivin kök dizininde yer alırken, görüntü dosyaları images altdizini içine konulmuş olacaktır. Bu davranışın değiştirilerek görüntü dosyalarının da sınıf dosyaları ile aynı dizine konulması istenecek olursa, -C opsiyonunun kullanılması gerekecektir. Bu opsiyon, geçici olarak kendisinden sonra sağlanan altdizine geçer ve dosya adını arşivleme sanki geçici altdizinde yapılıyormuş gibi arşive ekler. Buna göre, aşağıdaki komut o anki çalışma dizininde bulunan sınıf dosyaları ile images altdizinindeki tüm dosyaları arşivin kök dizinine yerleştirir.

$ jar cf ArşivDosyası.jar *.class -C images *

Kimi zaman, sıfırdan oluşturmak yerine ufak bir ekleme veya değişiklik yaparak var olan bir arşivi güncellemek isteyebiliriz. Oluşturmaya göre daha ucuz olan bu işlem u opsiyonu ile gerçekleştirilebilir. Arşiv oluşturma ile aynı argümanlara sahip bu işlem, kendisine geçirilen dosyanın arşivde var olması durumunda yeni dosyayı arşivdekinin üzerine yazar. Buna göre, aşağıdaki örnek kullanım ArşivDosyası.jar dosyasına c.class dosyasını eklerken, arşivde hali hazırda var olan a.class dosyasını yeni haliyle güncelleyecektir.

$ # Arşiv güncelleme
$ jar uf ArşivDosyası.jar a.class c.class

Daha önceden oluşturulmuş bir arşivin içeriği t opsiyonu ile listelenebilir. Standart çıktıya basılan listede arşivdeki dosya ve altdizinlerin kök dizine göre adları yer alır. Altdizinlerin / ile sonlandırıldığı bu listelemenin daha ayrıntılı yapılabilmesi için v opsiyonu kullanılabilir.

$ #Arşiv içeriği listeleme
$ jar tf bsh-2.0b4.jar
META-INF/
META-INF/MANIFEST.MF
bsh/
bsh/BSHAllocationExpressin.class
bsh/BSHAmbiguousName.class
...

Bir arşivin açılması arşivciye x opsiyonunun sağlanmasıyla mümkün olur. Arşiv içindeki dosya sıradüzenini disk üzerinde aynen oluşturan bu işlemin hali hazırda var olan dosyaların üzerine yazacağı unutulmamalıdır.

$ # Arşiv açma
$ jar xf bsh-2.0b4.jar

Arşiv Manifestosu

İçerik listeleme örneği farklı arşivler için denenecek olursa, META-INF dizini içindeki MANIFEST.MF dosyasının her zaman çıktıda yer aldığı görülecektir. Sakın, bunun arşiv yaratıcılarının sizi paranoyaya sürüklemek amacıyla sözleşerek uyguladığı bir komplo olduğunu düşünmeyin; nasıl ki, gemiler taşıdıkları kargonun ayrıntısını içeren bir manifesto bulundururlar, arşiv dosyaları da söz konusu arşivin sahip olduğu özellikleri belirtmek amacıyla META_INF/MANIFEST.mf dosyası içinde bir manifesto bulundurur.

Aksine bir yönlendirmede bulunmadığınız takdirde, arşiv oluşturma sırasında sizin için minimal içerikli bir manifesto oluşturulur.³ Manifest-Version: 1.0 satırından oluşan bu manifestoyu arşiv oluşturma veya güncelleme sırasında sağlanacak m opsiyonu ile isteğinize göre değiştirebilirsiniz. Yapılacak değişikliklerin üzerine yazma yerine kaynaştırarak işini gördüğü akıldan çıkarılmamalıdır. Ne demek istediğimizi bir örnekle görelim. Varsayalım ki, ArşivDosyası.jar işini görebilmek için YardımcıArşiv1.jar ve YardımcıArşiv2.jar arşivlerine ihtiyaç duyuyor. Bu durum, anılan bağımlılık bilgisini içeren bir dışsal manifesto dosyasının MANIFEST.MF'ye yamanması ile karşılanabilir.

EkManifesto.mf

Class-Path: YardımcıArşiv1.jar YardımcıArşiv2.jar

jar umf EkManifesto.mf ArşivDosyası.jar

EkManifesto.mf dosyasının MANIFEST.MF'ye yamandığı yukarıdaki satırın işlenmesi sonrasında MANIFEST.MF dosyası şu içeriğe sahip olacaktır.

MANIFEST.MF

Manifest-Version: 1.0
Class-Path: YardımcıArşiv1.jar YardımcıArşiv2.jar

İndeksleme

Dosya ve altdizin sayısının artmasıyla birlikte arşivdeki bir dosyanın bulunup kullanılması daha uzun bir zaman alacaktır. Böyle bir durumda, i opsiyonunun var olan bir arşiv ile birlikte arşivciye geçirilmesi aramayı hızlandıran bir indeks dosyası yaratarak maliyeti azaltabilir.

$ # Arşiv indeksleme
$ jar i ArşivDosyası.jar

META-INF altdizini içindeki INDEX.LIST dosyasına yazılan indeksleme bilgisinin, arşivin her güncellenmesi sonrasında yeniden yaratılması gerektiği unutulmamalıdır. Ayrıca, indekslemenin diğer işlemlerden ayrı yapılmasının zorunlu olduğu da akıldan çıkarılmamalıdır.

Arşiv Kullanımı

Edindiğiniz arşiv dosyalarından değişik şekillerde yararlanabilirsiniz. Öncelikle, arşiv dosyaları sınıf yolu üzerindeki bir dizine açılmak suretiyle kullanılır hale getirilebilir. Daha zahmetsiz bir diğer yöntem, arşiv dosyasını CLASSPATH ortam değişkenine eklemekten geçer. Örnek olarak, ArşivDosyası.jar'ı kullanan Prog.java adındaki bir dosyanın nasıl derleneceğine bakalım.

javac -cp ".:/home/tevfik/Java Paketleri/ArşivDosyası.jar:$CLASSPATH" Prog.java

Yukarıdaki komuta göre, Prog.java dosyasında ihtiyaç duyulan sınıf dosyaları öncelikle o anki çalışma dizininde, sonra /home/tevfik/Java Paketleri dizininde bulunan ArşivDosyası.jar arşivinde ve nihayet CLASSPATH ortam değişkenince işaret edilen yerlerde aranacaktır. Bu noktada, CLASSPATH ortam değişkeninin içerdiği arşiv dosyası atıflarının mutlak konum verilerek yapılması gerekirken, komut satırında yapılacak uygulamaya özel eklemelerin göreceli olarak da verilebileceği akılda tutulmalıdır.

Arşiv dosyaları, edimli kütüklere benzer şekilde bir komut gibi de kullanılabilir. Bunun için, öncelikle arşiv manifestosuna giriş noktasını içeren çalıştırılabilir sınıfın hangisi olduğunu gösteren Main-Class anahtarı ve ilişkin değerin eklenmesi gerekir. Yukarıda▵ gösterdiğimiz şekilde manifestoya yapılacak bir değişiklikle sağlanabilecek bu bilgi, arşivciye e opsiyonu ile de bildirilebilir.

$ # Arşiv giriş noktası
$ jar cfe ArşivDosyası.jar AnaSınıf.class

Yukarıdaki komutun işlenmesi sonrasında, arşivci tarafından oluşturulacak minimal manifesto Main-Class: AnaSınıf.class satırını da içerecektir.

Giriş noktası bilgisine sahip bir arşivin çalıştırılması oldukça basittir; yapılması gereken, JSM'ye -jar opsiyonunun geçirilmesinden ibarettir. Böylesine bir kullanım, JSM'ye argümanda sağlanan dosyanın bir arşiv olduğu ve çalışmanın çalıştırılabilir sınıf adının manifestodaki Main-Class'a dair değerden öğrenilip bulunması sonrasında başlayacağı anlamına gelir.

$ # Arşiv çalıştırma
$ java -jar ArşivDosyası.jar

Paketler ve Sınıf Yolu

Pek fazla kullanılmasa da, arşivciye sağlanan 0 opsiyonu arşivin sıkıştırma yapılmaksızın oluşturulacağı anlamına gelir. ↑
Unix temelli işletim dizgelerinden alışmış olanlara uyarı: opsiyon öncesinde - yok. ↑
İstenecek olursa, M opsiyonu ile minimal manifestonun oluşturulmasının önüne geçilebilir. ↑

Paketler ve Sınıf Yolu

2011-07-14T17:08:00.007+03:00

Okumakta olduğu üniversitenin kütüphanesinde kitap arayan hevesli bir öğrenciyi düşünün. Bu öğrenci, belli bir düzene göre düzenlenmiş kütüphaneyi bu düzene uygun biçimde dolaşarak arayışını kolaylaştırabilir. Örneğin, kitapların fakülte, dal ve konu sıradüzenine (hiyerarşi) göre gruplanması durumunda, programlama dersine dair bir kitabı arayan öğrenci, arayışını önce mühendislik kitaplarına, sonra mühendislik kitapları içindeki bilgisayar mühendisliği kitaplarına ve nihayet bilgisayar mühendisliği kitapları içindeki programlama kitaplarına kısıtlayacaktır. Son adımda ise, konuya dair kitaplar içinde yapılan aramayı takiben, istenen kitap ya bulunacak ya da bulunamayacaktır. Kütüphanedeki kitap sayısı düşünüldüğünde, bu yöntemin kütüphanedeki tüm kitapları baştan sona sırasal bir biçimde tarayarak aramaktan çok daha verimli olacağı kesindir.

Java platformundaki türler de (sınıf ve arayüzler) kütüphanedeki kitapları andıran bir sıradüzenine konulur. Aynı konudaki kitapların kütüphanede aynı bölgeye yerleştirilmesinde olduğu gibi, ilişkili türler aynı paket içine konulur. Gerektiği takdirde, birbirine yakın kavramların gruplandığı paketler bir üstpaket içine yerleştirilebilir. Paket içine paketlerin ve/veya türlerin konulması ile oluşturulan bu sıradüzeninin amacı, platformdaki türlerin algılanmasını ve ilişkin sınıf dosyalarının ihtiyaç duyan paydaşlarca bulunmasını kolaylaştırmaktır.

Paket oluşturmanın bir diğer sebebi, farklı kişiler tarafından hazırlanmış türlerin ad çakışması olmadan kullanılmasını olanaklı kılmaktır. Ne kastettiğimizi, bir sergideki tabloların envanterini tutmak için yazılmış olan (Prog.java dosyasındaki) Java programının resmedildiği aşağıdaki şekil üzerinden görelim.¹

abc şirketi tarafından hazırlanan ve nesne kabı olarak hizmet veren Tablo sınıfı ile, def şirketince gerçekleştirilen ve sanat eseri olan tablo kavramını soyutlayan aynı adlı sınıftan yararlanılan Prog.java içindeki tür tanımlarının başarılı bir biçimde derlenebilmesi için aynı ada sahip her iki sınıfın birbirinden ayırt edilmesini mümkün kılacak bilginin sağlanması veya sınıf adlarından birisinin ya da her ikisinin de değiştirilmesi gerekir. Kaynak kodun elimizde olmayabileceğini düşünürsek, ad değiştirmenin çoğu zaman pek de uygulanabilir bir seçenek olmadığı görülecektir. Yapılması gereken, her iki şirketin de olası kullanım senaryolarını göz önünde bulundurarak tür tanımlarını diğer şirketlerinki ile çakışma ihtimali olmayan bir paketin içine koymasıdır. Bu bağlamda önerilen yöntem, şirketin İnternet üzerindeki varlığını temsil eden ve diğer şirketlerinki ile çakışması olanaksız olan alan adının kullanılmasıdır. Ek olarak, şirket içindeki yazılım envanterini tutmayı kolaylaştırmak adına, bazı ek bilgiler kullanılabilir. Buna göre, abc şirketinin ürettiği Tablo.java dosyasındaki Tablo sınıfının aşağıdaki gibi yazıldığı düşünülebilir: Türkiye'deki bir ticari şirket olan abc'nin yazılım mimarlarınca belirlenen kurallara bağlı olarak, Tablo sınıfı bakımını kolaylaştırmak adına diğer veri yapıları ile birlikte bulunabileceği vy paketine koyulmakta.

Tablo.java

package tr.com.abc.vy;

...

public class Tablo {
  ...
} // Tablo sınıfının sonu

Bu noktada, hemen ilk uyarımızı yapalım: dosya içinde tanımlanan türlerin ait olduğu paketi ilan eden package bildirimi, kaynak kodun yorum satırları dışındaki ilk öğesi olmalıdır. Ayrıca, aynı dosyada sadece bir paket bildirimi bulunabilir.

Yapılan tanımların paketlere yerleştirilmesi, söz konusu türlerin kullanımı aşamasında bazı şeylere dikkat edilmesini gerektirir. Öncelikle, atıfta bulunurken artık türün yerleştirildiği paket de hesaba katılmalıdır; türün adı kaynak dosyada sağlanan ilişkin tanımdaki ile aynı değildir. Örneğin, tr.com.abc.vy paketindeki Tablo sınıfı, tr.com.abc.vy.Tablo adına sahiptir, Tablo değil. Dolayısıyla, bu sınıfın nesnesi aşağıdaki gibi yaratılmalıdır.

...

tr.com.abc.vy.Tablo tablo =
  new tr.com.abc.vy.Tablo(...);

Yukarıdaki gibi uzun adların kullanılmasının doğuracağı olası yazım hataları iki şekilde azaltılabilir. Öncelikle, programlama dilinden bağımsız bir şekilde kullanılan geliştirme ortamlarındaki ad tamamlama özelliğinden yararlanılabilir. Java programcısı olarak bizi ilgilendiren ikinci seçenek ise, package bildiriminin kullanıcı tarafındaki tamamlayıcısı olarak görülebilecek import bildirimidir. Buna göre, Tablo sınıfı aşağıdaki gibi de kullanılabilir.

...
import tr.com.abc.vy.Tablo;
...
Tablo tablo = new Tablo(...);

import bildirim(ler)inin package bildiriminin ardından gelmesi gerektiği unutulmamalıdır. Ayrıca, java.lang paketinin içindeki türlerin özel bir şekilde ele alındığı ve Java derleyicisi tarafından otomatikman program içine getirildiği hatırda tutulmalıdır.

Program içinde yararlanılan tür sayısının artmasıyla birlikte import bildiriminin jokerli uyarlamasının kullanımı düşünülebilir. Bu bildirim, söz konusu paket içindeki tüm türlere kısa adlarıyla atıfta bulunmayı olanaklı kılar.

...
import tr.com.abc.vy.*;
...
Tablo tablo = new Tablo(...);

Bu noktada bir uyarının daha yapılması yerinde olacaktır: bir paketin jokerli import bildirimi ile görünür kılınması, paketin "içindeki" diğer paketlerin görünürlüğünü etkilemez; tüm paketlerin ayrı ayrı görünür kılınması gerekir. Çünkü, paketler sadece türler için aduzayı görevi görürler, diğer paketler için değil. Mesela, java.util paketinin görünür kılınması java.util.regex paketinin içindeki sınıfları görünür hale getirmeyecektir.

Değinilmesi gereken bir diğer bildirim, J2SE 5 ile birlikte Java'ya eklenen static import bildirimidir. Bu bildirim, bir sınıfın—paketin değil!—static bir öğesinin (veya tüm static öğelerinin) sınıf adı ile nitelenmeksizin kullanılabilmesini sağlar. Buna göre, aşağıdaki kodda java.lang.System sınıfının tüm static öğeleri sınıf adıyla nitelenmeksizin kullanılabilirken, java.lang.Math sınıfının yalnızca PI adlı özelliği benzer biçimde kullanılabilecektir.

...
import static java.lang.Math.PI;
import static java.lang.System.*;
...
double alan = PI * Math.pow(yarıçap, 2);
out.println("Alan: " + alan);

Gerçekleştirimci tür tanımını package bildirimi ile bir pakete koyar, kullanıcı söz konusu türü kısa adı ile kullanmak isteyecek olursa import bildiriminden yararlanır demekle işimizin bittiğini zannediyorsanız, üzülerek yanıldığınızı söylemeyelim. Kullanıcı, program içinde yararlanılan türlere ait gerçekleştirimleri içeren sınıf dosyalarının nerede aranması gerektiğine dair bilgiyi derleyiciye sağlamalıdır. Kütüphanede bıraktığımız hevesli öğrenciye dönecek olursak, öğrencimizin bir şekilde kütüphanenin bulunduğu yeri bilmesi gerekir. Aslına bakılırsa, öğrencimizin biraz daha azimli davranıp, aranan kitabın bulunmaması halinde aramaya devam edeceği diğer kütüphanelerin adresini öğrenmesinde yarar olacaktır. Buna göre, kitap arama aşağıdaki adımlar izlenerek yapılır diyebiliriz.

Adres listesinden bir sonraki kütüphanenin adresini bul. Böyle bir adresin olmaması durumunda, boynunu bükerek evine dön.
Adreste belirtilen kütüphanede aramaya başla.
Aramanın başarıyla sona ermesi durumunda kitabı çantaya koy. Aksi takdirde, 1. adıma git.
Kitabın gerekli bölümlerini oku.

Algoritmamızı Java derleyicisinin² sınıf dosyası arama algoritmasına uyarlayacak olursak...

Sınıf yolu listesinden bir sonraki sınıf yolu dizininin konumunu bul. Böyle bir konumun olmaması durumunda, kullanılmak istenen türe dair tanımın bulunmadığını ilan et ve derlemeyi başarısızlıkla bitir.
Sınıf dosyasını sınıf yolu dizininden başlayarak ara. Bunun için, türün uzun adındaki '.' karakterlerini yol ayırıcı karakteri—Unix temelli sistemlerde '/', MS Windows temelli sistemlerde '\'—ile değiştir. Buna göre, tr.com.abc.vy.Tablo sınıfı sınıf yolu dizininin içindeki tr/com/abc/vy altdizininde aranacaktır.
Aramanın başarıyla sona ermesi durumunda sınıf dosyasını belleğe yükle.. Aksi takdirde—yani, Tablo.class dosyasının bulunmaması durumunda— 1. adıma git.
Türün kullanımı noktasında, kullanımın doğruluğunun denetimi için belleğe yüklenen dosyadaki bilgilere başvur.

Benzetmeyi tamamlamak için yapmamız gereken, sınıf yolu listesini Java derleyicisine aktarmak. Bu, sınıf dosyalarının aranmaya başlanacağı dizinlerin konumlarını tutan CLASSPATH ortam değişkenine PATH ortam değişkenine benzer bir şekilde değer sağlanması yoluyla olur. Bir diğer yöntem, Java derleyicisine -cp opsiyonu ile uygulama bazında bu bilginin verilmesini içerir. Aşağıda her iki yöntemin birlikte kullanımına dair bir örnek verilmektedir.³

javac -cp ".:/Java Paketleri/sergi:$CLASSPATH" Prog.java

Prog.java dosyasındaki Java programlama dili tanım(lar)ını derleyen bu komut, kullanım doğruluğunu denetlemek için ihtiyaç duyulan türlerin karşılığındaki sınıf dosyalarını önce derlenmekte olan kaynak dosya ile aynı dizinde, sonra /Java Paketleri/sergi ve nihayetinde CLASSPATH ortam değişkeni ile belirtilen dizinler içinde arayacaktır. Arama sırasında sınıf dosyasından daha sonra güncellenmiş aynı adlı bir .java dosyasına rastlanması durumunda, arama başarıyla bitmiş kabul edilecek, derleyici kaynak dosyayı derleyerek denetimlerinde bu derlenmiş dosyadan yararlanacaktır.

Son olarak, bu günceyi daha önce ziyaret edip de kod örneklerine göz atmış olanlardan bazılarınızın, package bildirimi olmaksızın yazılan türlere ne olduğunu sorduklarını duyar gibiyim. Bu haklı sorunun yanıtını vererek yazımızı bitirelim: söz konusu türler, varsayılan paket dediğimiz ve kaynak kodun bulunduğu dizinle ilişkilendirilen paketin içinde konuluyordu.

Arşiv Dosyaları

Şekli bir yerden hatırladıklarını düşünenler belleklerinin oynadığı bir oyuna kurban edilmiyorlar; benzer bir şekil, Java adıyla birlikte anılan kavram ve kısaltmalara değindiğimiz yazıda🔎 da vardı. Dolayısıyla, bu yazıda değindiğimiz kavramların diğer JSM dillerinden yararlanılarak üretilmiş sınıf dosyaları için de geçerli olduğu unutulmamalı. ↑
Sınıf dosyası arama Java derleyicisine sınırlı bir işlem değil. Sınıf dosyaları ile işi olan tüm sistem yazılımlarının bu algoritmayı kullanması söz konusu olacaktır ki, buna en güzel örnek sınıf dosyalarını işleten JSM'dir. ↑
MS Windows temelli işletim dizgelerinde çalışanların ':' yerine ';', $CLASSPATH yerine %CLASSPATH% kullanmaları gerekecektir. ↑

Sınama Aracı Olarak BeanShell

2011-06-03T00:48:00.003+03:00

Herhangi bir mühendislik ürününün en önemli özelliği, ister oturduğunuz ev olsun isterse kullanmakta olduğunuz yazılım, işlevini spesifikasyonlarına uygun bir şekilde görmesidir. Doğruluk olarak adlandırılan bu özellik, ürünün inşa edilmesi sırasında yapılan tetkikler ile denetlenebileceği gibi kullanım esnasında ortaya çıkan aykırı davranışların yönlendirmesi sonrasında yapılan bakım çalışmaları ile de sağlanabilir.¹ İşte bu yazımızda, Java programlama dili kullanılarak yazılan sınıfların nasıl sınanabileceğine dair bir seçenek sunan BeanShell'e göz atacağız. Bir diğer deyişle, Java kaynak kodunun doğruluğunun nasıl temin edilebileceğine değineceğiz.

Temel BeanShell
BeanShell kaynak dosyaları
Kod örtüsü ve nesneler
BeanShell ile birim sınama

Temel BeanShell

BeanShell yorumlayıcısı, gerçekleştirimi barındıran arşiv dosyasının http://beanshell.org/ adresindeki Download sekmesinden indirilip sınıf yolu üzerindeki bir yere konulmasından² sonra ilişkin sınıfın JSM'ye yüklenmesi ile başlatılır. Kimi ortamlarda, komut satırından bsh girilmesi de yeterli olacaktır.³ Yorumlayıcıdan çıkış ise BeanShell komut kabuğunda girilecek exit ile sağlanabilir.

Aşağıdaki kod parçasından da görülebileceği gibi, dinamik türlemeli olan BeanShell'de bir tanımlayıcının ait olduğu türün belirtilmesi gerekmez; aynı tanımlayıcının farklı zamanlarda farklı türlerden değerlere sahip olması da mümkündür. Ancak bu, söz konusu tanımlayıcının kısıtsız bir biçimde kullanılabileceği anlamına gelmez; tanımlayıcıya atfın yapıldığı andaki türle uyumsuz bir kullanım hataya neden olacaktır.

$ # Bazı ortamlarda bsh komutu da aynı görevi görür.
$ java bsh.Interpreter

BeanShell 2.0b4 - by Pat Niemeyer (pat@pat.net)
bsh % // Tanımlayıcı türlerinin ilan edilmesi gerekmez.
ad = 2;
bsh % ad = ad + ".Mehmet";
bsh % print("Ad: " + ad);
Ad: 2.Mehmet
bsh % exit();
$

Standart çıktıya değer göndermek için print'e ek olarak show komutu da kullanılabilir. Her kullanımında bir bayrak değişkeninin o anki durumunu değilleyerek aç-kapa düğmesi gibi işini gören bu komut, işlem gören deyimlerin sonucunun standart çıktıya basılıp basılmayacağını belirler.

bsh % ad = "Ahmet Adnan";
bsh % soyad = "Saygun";
bsh % ad + " " + soyad;
bsh % /* Sonuçlar basılacak */ show();
bsh % ad + " " + soyad.toUpperCase();
<Ahmet Adnan SAYGUN>
bsh % show();
bsh % ad;
bsh %

Bilinmesinde yarar bulunan diğer BeanShell komutlarından getClassPath, kullanıldığı andaki sınıf yolu ortam değişkeninin (CLASSPATH) hangi dizin ve arşiv dosyalarını içerdiğini döndürürken, addClassPath sınıf yoluna yeni bir dizin veya arşiv dosyası ekler; setClassPath ise, CLASSPATH değişkenini argümanındaki java.net.URL dizisinin elemanlarına sahip olacak şekilde günceller.

bsh % print(getClassPath());
java.net.URL []: {
file:/home/tevfik/,
...
file:/usr/lib/jvm/java-6-openjdk/jre/lib/rt.jar,
}
bsh % pwd();
/home/tevfik
bsh % addClassPath("a/b/c");
bsh % print(getClassPath());
java.net.URL []: {
file:/home/tevfik/,
...
file:/usr/lib/jvm/java-6-openjdk/jre/lib/rt.jar,
file:/home/tevfik/a/b/c,
}

Dikkat edilirse, sınıf yoluna eklenen dizin o anki çalışma dizinine eklenerek oluşturulmuş bir mutlak yol ile belirleniyor; pwd ile sorgulanabilen bu yol cd komutu ile değiştirilebilir. Dosya/dizin işlemeye dönük diğer komutlar aşağıda verilmiştir:

dir: - Argümansız kullanıldığında o anki çalışma dizininin içeriğini listeleyen bu komut, karakter katarı argümanla çağrıldığında listelemeyi söz konusu konumun göreceli olduğunu kabul ederek yapar.
cat: - Argümanındaki metin dosyasının içeriğini basar.
cp: - İlk argümanındaki dosya veya dizini ikinci argümanındaki konuma kopyalar.
mv: - İlk argümanındaki dosya veya dizini ikinci argümanındaki konuma taşır.
rm: - Argümanındaki dosya veya dizini siler.

Yukarıda verilen Unix temelli işletim dizgelerindeki adaşları ile aynı işlevli komutlara ek olarak, exec komutunu kullanarak herhangi bir komutu BeanShell komut satırından çalıştırabiliriz. Örneğin, aşağıdaki komut çalışma dizininin ayrıntılı bir listesini basacaktır.

bsh % exec("ls -la");

Dışsal bir uygulamanın çalıştırılması için kullanılan exec'e benzer bir komut, Lisp temelli dillerden birini bilenlere tanıdık gelecek olan eval'dir. Bu komut, argümanında geçirilen karakter katarını BeanShell komutları olarak algılar ve sanki komut kabuğundan girilmişçesine yorumlar. Dolayısıyla, yorumlama esnasında yaratılan olası yan etkiler komut sonrasında da geçerli olacaktır.

bsh % a = 5;
bsh % b = 10;
bsh % eval("c = a * b;");
bsh % print(c);
50

BeanShell Kaynak Dosyaları

Diğer komut kabuğu dillerinde olduğu gibi, BeanShell de komutların toptan okunup işlenmesi için araçlar sunar. Bunun için kullanılabilecek komutlardan source, Bash'in . komutuna benzer bir şekilde, argümanında verilen ada sahip dosyayı işleyerek yorumlayıcının aduzayını günceller. Örneğin, aşağıda verilen içeriğe sahip Kapasite.bsh dosyasının içselleştirilmesi sonrasında yorumlayıcının aduzayı söz konusu dosyada tanımlanmış olan kapasiteTest metodu ile zenginleştirilmiş olacaktır.

Kapasite.bsh

kapasiteTest(ilkKap, sonKap) {
  vec = new Vector(ilkKap);
  kap = vec.capacity();
  print("İlk kapasite: " + kap);
  for (i = 1; i < sonKap; i++) {
    vec.add(i);
    if (vec.capacity() != kap) {
      kap = vec.capacity();
      print("Yeni kapasite: " + kap);
    }
  }
} // kapasiteTest(ilkKap, sonKap) sonu

bsh % source("Kapasite.bsh");
bsh % kapasiteTest(0, 10);
İlk kapasite: 0
Yeni kapasite: 1
Yeni kapasite: 2
Yeni kapasite: 4
Yeni kapasite: 8
Yeni kapasite: 16
bsh %

Benzer bir etkiye sahip olan run, içselleştirdiği dosyanın içindeki tanımları komutla birlikte yaratılan yeni bir yorumlayıcı aduzayı içine yerleştirir. Yani, run komutunun işlemesi öncesi ve sonrasındaki aduzayları arasında fark olmayacaktır.

Kod Örtüsü ve Nesneler

Fonksiyonel programlama dillerine aşina olanlar bilir, nesne kod örtüsünden (İng., closure) evrilmiş bir kavramdır. Özetleyecek olursak, bir ya da birden çok fonksiyonda serbest tanımlayıcı olarak var olan ve bu fonksiyonlar tarafından "yakalanmak" suretiyle örtülen verilerin bileşkesine nesne denir. Söz konusu nesne, fonksiyonların çağrılması sırasında varsayılan argüman olarak manipüle edilir.

BeanShell, önceki paragrafta ne kastettiğimizi açmak için güzel bir araç sunar: içiçe metotlar. Gelin bunu aşağıdaki sayaç nesnesi gerçekleştiriminden anlamaya çalışalım.

Sayaç.bsh

yeniSayaç(ilkDeğer) {
  print("Hoşgeldiniz...");
  s = ilkDeğer;
  sayaç() { return s; }
  artır() { s = s + 1; }
  print("Gene bekleriz.");
  
  return this;
} // yeniSayaç(ilkDeğer) sonu

Sayaç nesneleri için yapıcı metot görevini gören yeniSayaç, standart çıktıya bilgilendirme mesajları basmaya ek olarak, gövdesinde tanımlanan her iki metotta da serbest değişken olarak geçen s'yi yapıcının çağrıldığı noktada geçirilen argümanın değerine sahip yerel değişken ile bağlamaktadır. Nesne paradigmasından alıştığımız biçimde ifade edecek olursak, yaratılacak sayaç nesnelerinin ilk değeri yapıcıya geçirilen değer olan s adlı bir alt alanı olacak ve bu nesneler artır ve sayaç adlı metotlar ile işlenecektir. Ancak, altalanın dışarıdan müdaheleye karşı korunmadığı dikkatli olanlarınızın gözünden kaçmamıştır.⁴

bsh % m = yeniSayaç(0);
Hoşgeldiniz...
Gene bekleriz.
bsh % m.artır();
bsh % m.artır();
bsh % n = yeniSayaç(10);
Hoşgeldiniz...
Gene bekleriz.
bsh % print(n.sayaç());
2
bsh % print(m.s);
10

BeanShell İle Birim Sınama

Bir betik dili olan BeanShell'in yorumlayıcısı, BeanShell'in yanısıra Java programlama dili sözdiziminin büyük kısmını desteklemesi nedeniyle, Java'nın komut kabuğu olarak da görülebilir. Yani, Java komutlarını BeanShell yorumlayıcısının komut satırından etkileşimli bir biçimde girebiliriz. Girilen komutun sonucuna göre bir sonraki komutu seçebileceğimiz ve ortaya çıkacak olası hataları anında görebileceğimiz anlamına gelen bu özellik, BeanShell yorumlayıcısının aynı zamanda Java için verimli bir sınama ortamı oluşturması demektir.

BeanShell'den Java kodu sınamak amacıyla yararlanmak için yorumlayıcı ortamını Java'nın kurallarına daha sıkı uyulan sıkı denetleme kipine geçirmemiz gerekir. Bu, setStrictJava komutunun true argümanı geçirilerek kullanılmasıyla sağlanır.

bsh % ad = "Ahmet Adnan";
bsh % setStrictJava(true);
bsh % soyad = "Saygun";
// Error: EvalError: (Strict Java mode) Assignment to undeclared variable: soyad 
: at line: 3 : in file: <unknown file> : soyad = "Saygun"
bsh % String soyad = "Saygun";

Sıkı denetim kipine geçildikten sonra yapılması gereken şey, birim sınamasını yapmak istediğimiz sınıfı import bildirimi ile görünür hale getirmek ve gerek source (ve run) ile okuyarak gerekse komut satırından girerek sağlanan Java kodu ile sınıfımızın işlevselliğini sınamaktır. Bu noktada, BeanShell yorumlayıcısının JSM'ye yüklenmesi sırasında java.lang paketinin yanısıra java.awt, java.awt.net, java.io, java.net, java.util, javax.swing, javax.swing.event paketlerinin de otomatikman görünür hale getirildiği bilinmelidir. Dolayısıyla, listelenen paketlerin import ile ithal edilmesine gerek yoktur.

bsh % import a.b.c.XYZ;
bsh % XYZ x = new XYZ(), y = new XYZ(10);
bsh % // XYZ nesnelerinin davranışını sına.
bsh % ...
bsh % reloadClasses();
bsh % // Sınamaya yeniden başla.
bsh % ...

Sınanmakta olan sınıfta hata saptanması durumunda ilişkin kod parçası gözden geçirilmeli ve değişiklik yapıldıktan sonra sınıfımızın yeni halinin BeanShell yorumlayıcısına görünür kılınması gereklidir ki, bu reloadClasses komutu ile sağlanır. Argümansız kullanıldığında sınıf yolu üzerindeki sınıflar arasından değişmiş olanların tümünü yeniden JSM'ya yükleyen bu komut, istenecek olursa bir paketteki tüm sınıflara veya tek bir sınıfa yönelik olarak da icra edilebilir. Ancak, arşiv dosyaları içindeki sınıfların yeniden yüklenemeyeceği bilinmelidir.

BeanShell yorumlayıcısına sağlanan Java kodunda kimi kısıtlamaların olduğu unutulmamalıdır. Bunlardan en önemlisi, soysal türlerin tür argüman(lar)ı olmaksızın kullanılması zorunluluğudur. Başta büyük bir gaf gibi gözükebilecek bu eksiklik Java kodunun BeanShell tarafında nasıl ele alındığı öğrenildiğinde mazur görülecektir: yorumlayıcıya görünür kılınan Java sınıfları, kaynak kod düzeyinde ele alınmaz, derleme sonucunda oluşturulan sınıf dosyalarının yüklenmesi yoluyla kullanılır. Bu da, derleme sırasında yer alan tür silme işlemi nedeniyle soysallık bilgilerinin sınıf dosyasına yansıtılmayacağı ve dolayısıyla BeanShell yorumlayıcısının dikkatine sunulan dosyalarda soysallık kavramının aslında hiç olmayacağı anlamına gelir.

Birim sınama bağlamında değineceğimiz son nokta, muhtemelen, tümleşik geliştirme ortamlarına alışık arkadaşların haklı bir beklentisini karşılayacaktır: BeanShell'in tipik kullanımı, yazımızda önerildiği gibi komut satırından çalıştırılan yorumlayıcıya başka bir ortamda geliştirilerek elde edilen sınıf dosyalarının sağlanması ve bu sınıfların sınanması değildir. Normalde, Eclipse, Emacs veya jEdit gibi geliştirme ortamlarında BeanShell yorumlayıcısı, Java düzenleyici penceresine özel bir konsol penceresi olarak eklemlenir ve programcı eşgüdümlü bir biçimde yönetilen iki pencere arasında gidip gelerek sınama işini hızlı bir şekilde yapar.

İnşa edilen ürünün yazılım olması durumunda, yapılan tetkike sınama bakım çalışmalarına ise hatadan arındırma denilir. ↑
Bu işlem, indirilen arşiv dosyasının diskte uygun bir konuma yerleştirilmesi sonrasında mutlak konum adı kullanılarak CLASSPATH ortam değişkenine eklenmesi kadar basittir. ↑
Aslında seçeneklerimiz bunlarla sınırlı değil. Görsel arayüz sevdalıları, java bsh.Console ve xbsh komutlarından biri ile emellerine ulaşabilirler. ↑
Verdiğimiz örnek, tüm altalanların tüm metotlarca kullanılacağını düşündürmesin; kimi metotlar kimi altalanları kullanmadan da işini görebilir. ↑

Her Sınıfa Lazım Metotlar

2011-05-24T11:12:00.002+03:00

Sınıflarınızı Bileşke Türler-Sınıflar adlı yazıda🔎 önerilen veya diğer kaynaklarda okuduğunuz reçetelere uyarak gerçekleştirdikten sonra bile, programlarınızın sıklıkla beklentileriniz dışında davranış sergilediğini gözlemleyebilirsiniz. Bu hayal kırıklığı kimi zaman yaptığınız bir dikkatsizlikten, kimi zamansa öngöremediğiniz bir işlevselliğin yokluğundan veya eksik gerçekleştirilmiş olmasından kaynaklanır. İşte bu yazıda, tüm sınıflarda özel olarak ele alınıp gerçekleştirilmeleri konusunda karar verilmesi gereken bazı özel metotlara değineceğiz ve Kuantum Tanrısı'nın JSM'nin içine kötü niyetli cinler yerleştirdiği kuruntusundan kurtulmaya çalışacağız.

Hoş yazım
Eşitlik denetimi
Kopyalama
Varsayılan yapıcı
Karşılaştırma

Hoş Yazım

Hatadan arındırma amacıyla başvurduğunuz çıktı komutlarınızın neden anlaşılmaz şeyler yazdığını açıklamakla başlayalım. Aşağıda verilen [oldukça yetersiz] Öğrenci sınıfını kullanarak ne yapmamız gerektiğine bir bakalım.

Öğrenci.java

import static java.lang.System.*;

public class Öğrenci {
  public static void main(String[] ksa) {
    Öğrenci öğr1 = new Öğrenci(123, "Ayşe", "Öztürk", 3.5F);

    out.println(öğr1);
    // metodun devamı...    
  } // void main(String[]) sonu

  public Öğrenci(long no, String ad, String soyad, float ort) {
    _ad = ad;
    _no = no;
    _ortalama = ort;
    _soyad = soyad;
  } // yapıcı(long, String, String, float) sonu

  public String ad() { return _ad; }
  public long no() { return _no; }
  public float ortalama() { return _ortalama; }
  public String soyad() { return _soyad; }

  private String _ad, _soyad;
  private long _no;
  private float _ortalama;
} // Öğrenci sınıfının sonu

$ javac -encoding UTF-8 Öğrenci.java
$ java Öğrenci
Öğrenci@6e1408
...

İşaretli satır tarafından basılanın bir Öğrenci nesnesi olmakla birlikte, haklı olarak, çıktıda nesne içeriğine dair bilgilendirici bir şey olmadığını düşünebilirsiniz. println (ve print) metotlarının işleyişine bakarak bunun neden tam olarak doğruyu yansıtmadığını anlamaya çalışalım. Söz konusu metotlar herhangi bir türden—ister ilkel tür olsun isterse bileşke tür—argüman alacak şekilde aşırı yüklenmiştir. Bu metotlardan char, char[] ve String argüman bekleyenlerin dışındakiler, aldıkları argümanı önce bir String nesnesi haline dönüştürür, ardından bu katar içindeki karakterleri basarak işini görür. Bileşke türlü değerlerden karakter katarına dönüşüm, aşağıdaki denkliklerden de görülebileceği gibi, önce String sınıfındaki valueOf metodunu çağırarak daha sonra ise bu metottan dönüşümü yapılmak istenen nesneye toString iletisi gönderilerek yapılır.

out.println(2 + öğr1);

≡

out.println(String.valueOf(2) + String.valueOf(öğr1));

≡

out.println(String.valueOf(2) + öğr1.toString()));

Dolayısıyla, sorumlunun öğr1'e toString iletisinin gönderilmesi sonucunda çağrılan aynı adlı metot olduğunu söyleyebiliriz. Ancak, öğr1'in üyesi olduğu Öğrenci sınıfına bakıldığında bu ada sahip bir metodun bulunmadığı görülür. O zaman, olmayan bir metodun çağrılmasıyla hata verilmesi gerekirken neden yukarıdaki çıktı üretilmektedir? Yanıt, söz konusu metodun bir diğer sınıftan kalıtlanmış olmasında yatar. Hoş yazım gibi tüm sınıflarda bulunması beklenen bir işlevsellik çok genel bir şekilde tüm sınıfların ortak atası olan Object sınıfındaki toString metodunun gerçekleştirimi ile sağlanmış ve Öğrenci sınıfının kendi özelliklerini yansıtan bir gerçekleştirim sağlamaması sonrasında derleyici tarafından bu metot kullanılmıştır. Tüm sınıfların ortak paydasından yararlanarak içi doldurulan bu metot ise nesnenin ait olduğu sınıfın adı, '@' ve nesnenin kıyım değerini birleştirerek işini görmektedir.¹ Nesnelerimizin çıktı ortamına basıldığında sonucun anlaşılır olmasını istiyorsak, toString adlı bu metodu nesnelerimizin özelliklerini düşünerek gerçekleştirmemiz gerekir. Öğrenci sınıfı için uygun bir gerçekleştirim aşağıda verilmiştir.

...
public class Öğrenci {
  ...
  public String toString() {
    return _no + " " + _ad " " + 
           _soyad + " " + _ortalama;
  } // String toString() sonu
  ...
} // Öğrenci sınıfının sonu

Eşitlik Denetimi

Hangi sınıfa ait olursa olsun tüm nesnelere gönderilmesi söz konusu olabilecek bir diğer ileti, hedef nesneye kendisini aynı türden bir diğer nesne ile eşit olup olmadığını denetlemesini söyleyen equals iletisidir. Başta işin, ilkel türlü değerlerde olduğu gibi, == ile halledilebileceğini, aslında equals iletisine ihtiyaç bile duyulmaması gerektiğini düşünenleriniz olabilir. Bu arkadaşlara, diziler konusunu işlediğimiz yazının🔎 aşağıya kopyaladığımız örneğiyle bunun olanaksız olduğunu hatırlatalım. Çünkü == tutacakların eşitliğini denetler. Bu da, eşitlik denetiminin true sonuç üretmesinin ancak aynı nesneyi gösteren iki tutacakla mümkün olacağı anlamına gelir. Bir diğer deyişle, == nesnelerin aynılık denetimini yapar, eşitlik denetimini değil.

String ad1 = new String("Tevfik");
String ad2 = new String("Tevfik");
System.out.println(ad1 == ad2); // => false

O zaman, Object sınıfında sağlanan equals metodu da eşitlik denetimini yapsaymış keşke diyebilirsiniz. Biraz düşündüğünüzde, farklı yapıya sahip belirsiz sayıda sınıfta eşitlik kavramının birbirlerinden çok farklı olacağını anlarsınız ve bunun da toString'de olduğu gibi sınıf gerçekleştirimcisinin müdahelesini gerektirdiğini görürsünüz. Zira, equals iletisinin tüm sınıflar için ortak payda olarak sunulan Object sınıfındaki metot gerçekleştirimi, == gibi davranır ve aynılık denetimi yapar. Yüksek performanslı bu çözümün isteklerinizi karşılamaması durumunda, aşağıdaki gibi amaçlarınıza uygun bir metodu sağlamanız yerinde olacaktır.

...
public class Öğrenci {
  ...
  public boolean equals(Object diğerNesne) {
    Öğrenci diğerÖğr = (Öğrenci) diğerNesne;

    return _no == diğerÖğr._no;
  } // boolean equals(Object) sonu
  ...
} // Öğrenci sınıfının sonu

Dikkat edecek olursanız, metot gövdesinin ilk satırında parametrede geçirilen Object türlü tutacağı biçimlendirmek suretiyle arkadaki nesneyi bir Öğrenci nesnesi gibi kullanmak isteğimizi bildiriyoruz.² Böylece, biçimlendirmenin sonucu olarak döndürülen Öğrenci türlü tutacak değerini atadığımız diğerÖğr adlı yerel değişkeni, kaplamının (İng., scope) sonuna kadar Öğrenci sınıfının özelliklerini yansıtacak şekilde kullanma hakkını kazanıyoruz. Bunun sebebi, Object sınıfının tüm Java sınıflarının ortak özelliklerini tutuyor olması ve _no altalanının bu ortak özellikler arasında bulunmaması.

equals metodunun ezilmesi yönünde bir karar verilmesi durumunda, hashCode iletisinin de gözden geçirilmesi gerekecektir. Hedef nesnenin Hashtable, HashMap ve HashSet gibi kapların altyapısında yararlanılan doğrudan erişimli veri yapılarında tutulabilmesi için kıyımdan geçirilerek tamsayı karşılığını döndüren bu iletinin Object sınıfındaki sözleşme tanımına bakılacak olursa, eşit olan nesnelerin aynı kıyım değerine sahip olması gerektiği görülür. Dolayısıyla, aynı öğrenciyi temsil eden farklı nesnelerin eşit ilan edildiği Öğrenci sınıfında, hashCode metodunun da bu eşitliğin altını çizen bir biçimde ezilmesi gerekecektir. Buna göre, aynı öğrenci numarasına sahip tüm Öğrenci nesnelerini eşit ilan eden yukarıdaki equals metoduna koşut hashCode gerçekleştirimi aşağıda verilmiştir.

...
public class Öğrenci {
  ...
  public int hashCode() { return (int) _no; }
  ...
} // Öğrenci sınıfının sonu

Dikkat edecek olursanız, long olan numaranın int olarak biçimlendirilmesi sonucu veri kaybı yaşanmış ve farklı iki öğrenciyi temsil eden Öğrenci nesnelerinin aynı kıyım değerine sahip olma olasılığı belirmiştir. long türünün int türünden daha büyük bir değer uzayına sahip olmasından kaynaklanan bu durum, hashCode sözleşmesini ihlal etmemektedir; istenen aynı öğrenciyi temsil eden nesnelerin eşit kıyım değerlerine sahip olmasını garanti etmektir, ayrı öğrencilerin aynı kıyım değerine sahip olmasını engellemek değil.

hashCode iletisinin kullanımı, nesnelerin kıyım tablosu temelli kaplarda tutulmasına sınırlı değildir. Eşitlik denetiminin uzun zaman alan bir işlem olması durumunda, hashCode olumsuz yanıtın hızlı verilmesini olanaklı kılar. Örnek olarak, binlerce elemana sahip ve ön tarafları birbirleriyle aynı olan eşit uzunluklu iki liste düşünün. Listeleri dolaşıp elemanları karşılıklı olarak eşitlik denetimine tabi tutmaktansa, listelerin öncelikle kıyım değerleri karşılaştırılır. Karşılaştırmanın olumsuz sonuç vermesi, listelerin eşit olmaması anlamına geldiği için hızlı bir biçimde yanıtı bulmamızı sağlayacaktır.³ Dolayısıyla, hashCode metodu da equals ile birlikte ele alınmalıdır.

Kopyalama

Programlamaya yeni başlayıp eşitlik denetiminde tatsız bir sürpriz yaşayanların çoğu, nesne kopyalama işleminde de benzer bir sıkıntı yaşarlar. Bunun sebebi, kopyalama amacıyla ilkleme veya atamadan yararlanmaları ve bu işlemlerin nesne yerine tutacağı kopyalamasıdır. Dolayısıyla, nesneler kopyalanmayacak, paylaşılacaktır. İhtiyacını duyduğumuz şey kopyalayan yapıcı gerçekleştirimidir. Kopyalanmak istenen nesnenin türünden bir parametresi bulunan bu metot, nesne kopyalamaktan ne anlaşıldığını gerçekleştiren bir gövdeye sahip olmalıdır. Öğrenci nesnelerinin kopyalanması için kullanılabilecek bir kopyalayan yapıcı gerçekleştirimi aşağıda verilmiştir.

...
public class Öğrenci {
  ...
  public Öğrenci(Öğrenci diğerÖğr) {
    _no = diğerÖğr._no;
    _ad = new String(diğerÖğr._ad);
    _soyad = new String(diğerÖğr._soyad);
    _ortalama = diğerÖğr._ortalama;
  } // kopyalayan yapıcı sonu
  ...
} // Öğrenci sınıfının sonu

Dikkat edersiniz, _ad ve _soyad altalanları için String sınıfının kopyalayan yapıcısı kullanılıyor. Bu durumda, String nesnelerinin değişmez içerikli karakter katarları tuttuğunu bilenler, haklı olarak, kopyalayan yapıcı yerine ilklemenin daha akılcı olacağını söyleyeceklerdir. Ne de olsa, değişmeyen bir şeyin kopyalanması ile paylaşılması arasında bir fark yoktur; paylaşılan nesnenin değişmesi söz konusu olmayacağı için bir tutacak yoluyla yapılan değişikliğin bir diğer tutacak yoluyla görülmesi gibi bir durum asla ortaya çıkmayacaktır. Dolayısıyla, Öğrenci sınıfı için aşağıda verilen daha verimli gerçekleştirim de işimizi görecektir.

...
public class Öğrenci {
  ...
  public Öğrenci(Öğrenci diğerÖğr) {
    _no = diğerÖğr._no;
    _ad = diğerÖğr._ad;
    _soyad = diğerÖğr._soyad;
    _ortalama = diğerÖğr._ortalama;
  } // kopyalayan yapıcı sonu
  ...
} // Öğrenci sınıfının sonu

Varsayılan Yapıcı

Sizi gafil avlayabilecek bir diğer metot, nesnelerin ilklenmesi esnasında derleyicinin sentezlediği kod tarafından arka planda usulca çağrılabilecek olan argümansız yapıcıdır. Programcının talebi ile çağrılmayıp derleyicinin araya girerek yapıcı metot çağrılması gerekliliğine hükmettiği durumlarda çağrıldığı için varsayılan yapıcı olarak adlandırılan bu yapıcı da sınıf gerçekleştirimi sırasında göz önünde bulundurulmalıdır. Mesela, geliştirmekte olduğunuz sınıftan kalıtlayan bir sınıfın nesnesinin yaratılması sırasında sizden habersiz bir şekilde sınıfınızın varsayılan yapıcısı çağrılacaktır. Dolayısıyla, böylesine bir senaryoyu öngörmeniz durumunda varsayılan yapıcıyı sağlamanız yerinde bir hamle olacaktır.

...
public class Öğrenci {
  ...
  public Öğrenci() { }
  ...
} // Öğrenci sınıfının sonu

Bu noktada, derleyicinin varsayılan yapıcı sentezleme noktasındaki yardımını bir kez daha hatırlatarak, bu desteğin programcı tarafından herhangi bir yapıcının sağlanması durumunda geçerli olmadığını yineleyelim. Bundan dolayı, yukarıdaki işlevsiz gibi gözüken yapıcı gerçekleştirimi zorunludur.

Karşılaştırma

Sınıf gerçekleştirimi sırasında gerekliliğine karar vermemiz icap eden bir diğer işlem, sınıfımızın bir nesnesini aynı türden bir diğeri ile karşılaştırma işlemidir. Biraz kolaycı olanlarınız, toString ve equals'da olduğu gibi, aynı türe ait nesnelerin öncelik-sonralık sıralamasını saptayan bu işleme karşılık da Object sınıfında bir metot bulunduğunu ve yapılması gerekenin sınıfımızın ihtiyaçlarına göre bu metodun ezilmesi olduğunu düşünebilirler. Ancak, karşıt bir örnek kolay varılan bu yargının tüm sınıflar için doğru olmadığını gösterir. Örneğin, matemetikteki küme kavramını gerçekleştirmekte olduğumuzu düşünün; kümelerin sıraya dizilmesinin, iki kümeden hangisinin daha önce/sonra geldiği sorusunun pek de mantıklı olmadığı görülecektir. Dolayısıyla, karşılaştırma işlemi hoş yazım ve eşitlik denetimi işlemlerinden farklı ele alınmalıdır.

Derdimizin çaresi, Java alemindeki sınıfları karşılaştırılabilir olanlar ve olmayanlar şeklinde ikiye ayırmaktır. Aradığımız bu çözüm bize arayüz üstkavramınca sağlanan tasnifin ta kendisidir. Birbirleriyle ne kadar alakasız olurlarsa olsunlar, aynı arayüzü gerçekleştiren iki (veya daha fazla sayıda) sınıf, arayüz tutacağı vasıtasıyla görüldükleri takdirde aynı kullanılabilirliğe sahip olacaklardır; söz konusu sınıfların nesneleri kendi türlerinden bir diğer nesne ile karşılaştırılabilecek ve bu işlemin sonucunda sıraya dizilebileceklerdir. Dolayısıyla, yapmamız gereken Java platformundaki nesneler için karşılaştırılabilirlik kategorisini tanımlayan Comparable arayüzünü sınıfımızda gerçekleştirmektir. Bunun örneği aşağıda verilmiştir.

...
public class Öğrenci implements Comparable<Öğrenci> {
  ...
  public int compareTo(Öğrenci diğerÖğr) {
    if (_ortalama > diğerÖğr._ortalama)
      return 1;
    else if (_ortalama < diğerÖğr._ortalama)
      return -1;
    else if (_no > diğerÖğr._no)
      return 1;
    else return -1;
  } // int compareTo(Öğrenci) sonu
  ...
} // Öğrenci sınıfının sonu

Comparable arayüzü, içerdiği yegâne ileti olan compareTo'nun Java dokümantasyonunda ifade edilen anlamına uygun bir biçimde gerçekleştirimini zorunlu koşar. Bu, dönüş değeri olarak hedef nesnenin diğer nesneden "önce" gelmesi durumda artı, "sonra" gelmesi durumunda eksi, aksi takdirde 0 döndürüleceği anlamına gelir.

Sınıf Tanımlama Reçetesi
Nesne İlkleme

Bir nesnenin kıyım değeri—yani, nesnenin altalanlarının özeti—nesneye hashCode iletisinin gönderilmesi ile elde edilir. ↑
Burada herhangi bir şekilde nesnenin kopyalanması gibi bir durum olmayacaktır. Aynı nesne değişik türlü iki tutacak vasıtasıyla, diğerNesne ve diğerÖğr, iki farklı arayüze sahipmiş gibi kullanılacaktır. ↑
Anlatılanın geçerli olması için, kap içeriğini değiştirmeye dönük herhangi bir işlemin başarıyla sonuçlanması sonrasında kaba dair kıyım değerinin güncellenmesi gerekir. Bu ise, içerik güncelleme işlemlerinin maliyetini olumsuz bir biçimde etkileyecektir. Dolayısıyla, önerilen yöntem daha ziyade değişmez içerikli kaplara sınırlıdır. ↑

Nesnelerin İlklenmesi

2011-05-18T15:35:00.003+03:00

İki önceki yazımızda🔎 programcının yeni bir sınıf tanımlamak yoluyla Java platformunu nasıl geliştirebileceğine ve sınıfların nesnelerinin nasıl yaratılıp kullanılabileceğine değinmiştik. Bu yazımızda da, nesnelerin yaratılmaları esnasında ne şekilde ilkleneceğine göz atacağız.

Java'da, diğer nesne paradigmasını destekleyen dillerde olduğu gibi, nesnenin yaratılması iki aşamada tamamlanır: i) nesne için yığın bellekten (İng., heap memory) yerin ayrılması, ii) ayrılan belleğin tutarlı değerlerle ilklenmesi ve yığın bellek dışındaki kaynakların elde edilmesi. Nesnenin yaşam döngüsünü başlatan bu iki adımın atomik olarak icra edildiği ve iki adımdan birinin başarısızlığa uğraması durumunda nesne yaratmanın mümkün olmayacağı unutulmamalıdır. Örneğin, sınırlı bir kaynak olan yığın belleğin tükenmesi olasılığına karşılık programcı, OutOfMemoryError hatasının oluşabileceğinin farkında olmalıdır. Benzer şekilde, ikinci aşamada elde edilmek istenen bir dış kaynağın elde edilememesi de ilkleme esnasında durumu özetleyen bir ayrıksı durumun atılmasına neden olabilir.

Yığın belleğin JSM'nin parçası olan bir bileşen tarafından ayrılması nedeniyle, nesne yaratmak isteyen programcının ilk aşamanın yerine getirilmesi için new işlecini kullanmak dışında bir şey yapması gerekmez. Buna karşılık, ilkleme ve dış kaynak elde edilmesinin söz konusu olduğu ikinci aşama sınıf gerçekleştirimcisinin sağladığı yapıcı metotlardan birinin çağrılması ile tamamlanır. İki aşama arasındaki bağlantı ise derleyicinin new işleci ve uygun bir yapıcıyı ilişkilendirilmesi ile sağlanır. Aşağıdaki örnekler üzerinden anlamaya çalışalım.

char[] karakterDizisi = new char[]{'D', 'i', 'z', 'i'};
String katar1 = new String(karakterDizisi);
String katar2 = new String(karakterDizisi, 0, 3);

İlk satırda oluşturulan dört karakterli dizi kullanılarak yaratılan her iki nesne de yerlerinin ayrılmasının ardından new işleci sonrasında sağlanan sınıftaki (String) yapıcılardan biri kullanılarak ilkleniyor. Buna göre, katar1 tutacağı tarafından temsil edilen nesne, char[] bekleyen yapıcıda dizi içindeki tüm elemanlar kullanılarak ilklenirken, katar2'nin gösterdiği nesne, ilk argümanında geçirilen karakter dizisinin ikinci argümanda verilen konumdan başlayarak üçüncü argümanda sağlanan sayıda karakteri kullanılarak bir başka yapıcıda ilkleniyor.

Genel çerçeveyi çizdikten sonra, nesne ilkleme bağlamında bilinmesi gereken diğer noktalara değinelim. Nesnenin kimi altalanlarına ilk değer sağlanmaması durumu ile başlayalım. İlişkin altalana ait belleğin o anki rasgele içeriğini ilk değer olarak kabul eden C++ dilinin aksine, Java'da ilklenmeyen altalanlar aşağıdaki tabloda verilen değerlere sahip olacak şekilde ilklenir.

*Altalanların varsayılan ilk değerleri*
Tür	İlk değer
Tamsayı türler	0
Kayan noktalı türler	0.0
`char`	'\u0000'
`boolean`	`false`
Bileşke türler	`null`

Buna göre, aşağıdaki sınıfın nesnesinin yaratılması durumunda _yaşadığıÜlke adlı altalan null değerine sahip olacaktır.

public class Vatandaş {
  public Vatandaş(String ad, String anneAdı, String babaAdı) {
    _ad = ad;
    _anneAdı = anneAdı;
    _babaAdı = babaAdı;
  } // yapıcı(String, String, String)
  ...
  private String _ad, _anneAdı, _babaAdı;
  private String _yaşadığıÜlke;
} // Vatandaş sınıfının sonu

Altalanların hiçbirine değer sağlanmaması halinde, gerçekleştirimci tarafından yapıcı metot yazılması pek anlamlı olmaz. Boş bir gövdeye sahip boş parametre listeli bir yapıcı ile kendini gösteren böylesine bir durumda derleyici araya girer ve gerçekleştirimciyi yapıcı metot yazma yükümlülüğünden kurtararak tüm altalanları varsayılan değerler ile ilkleyen bir yapıcı sentezler. Ancak, bu dost eli sadece yapıcı sağlanmadığı takdirde uzanacaktır; gerçekleştirimcinin sınıf tanımında bir veya daha fazla sayıda yapıcıya yer vermesi derleyicinin yapıcı sentezlemesinin önüne geçecektir.

İlkleme bağlamında bilinmesi yararlı olacak bir diğer konu, ilkleme bloklarının kullanımıdır. Yukarıdaki örneği ele alarak anlamaya çalışalım. Vatandaş sınıfının Türkiye'de kullanılacak olduğunu düşündüğümüzde, yaratılacak nesnelerdeki _yaşadığıÜlke adlı altalanın çoğunlukla "Türkiye" olacağı öngörülebilir. Dolayısıyla, derleyicinin bileşke türler için kullandığı null yerine "Türkiye" değerli bir karakter katarının varsayılan ilk değer olması daha yerinde olacaktır. İşte bu gözlemimizi, derleyicinin kullanacağı varsayılan ilk değerlerin değiştirilmesi için her nesne yaratılması noktasında, nesnenin ilklenmesi öncesinde işlenen bir nesne ilkleme bloğu içinde belirtmemiz gerekir. Aşağıdaki değiştirilmiş sınıf tanımı bunun nasıl yapılabileceğini gösteriyor.

public class Vatandaş {
  // Nesne ilkleme bloğu.
  { 
    System.out.println("Nesne yaratılıyor...");
    _yaşadığıÜlke = "Türkiye";
  }
  public Vatandaş(String ad, String anneAdı) {
    _ad = ad;
    _anneAdı = anneAdı;
  } // yapıcı(String, String)

  public Vatandaş(String ad, String anneAdı, String babaAdı) {
    _ad = ad;
    _anneAdı = anneAdı;
    _babaAdı = babaAdı;
  } // yapıcı(String, String, String)

  public Vatandaş(String ad, String anneAdı, String babaAdı, String ülke) {
    _ad = ad;
    _anneAdı = anneAdı;
    _babaAdı = babaAdı;
    _yaşadığıÜlke = ülke;
  } // yapıcı(String, String, String, String)
  ...
  // Nesne ilkleme bloğu.
  { _babaAdı = "Mehmet"; }
  private String _ad, _anneAdı, _babaAdı;
  private String _yaşadığıÜlke;
} // Vatandaş sınıfının sonu

Dikkat ederseniz, metot gövdeleri dışında bulunan kıvrımlı ayraç çifti arasındaki komutlardan oluşan nesne ilkleme blokları, sınıfın herhangi bir yerine konulabileceği gibi tanım içinde birden çok kez de geçebiliyor. Ortaya çıkacak toplam etki, sınıfın başından sonuna doğru tüm blokların geçiş sırasına göre işlenmesi ile elde edilir. Dolayısıyla, yukarıdaki sınıfta geçen nesne ilkleme bloklarının etkisi aşağıdaki blokla da elde edilebilir.

{
  System.out.println("Nesne yaratılıyor...");
  _yaşadığıÜlke = "Türkiye";
  _babaAdı = "Mehmet";
}

İlkleme amacıyla kullanılabilecek bir diğer programlama aracı, söz konusu sınıfın ilk kullanılışı öncesinde bir kereliğine işlenen sınıf ilkleme bloğudur. Örneğin, aşağıdaki tanıma göre, Vatandaş sınıfının ilk nesnesinin yaratıldığı veya nesne yaratılmadan kullanılabilecek static öğelerinden birinin kullanıldığı nokta öncesinde standart çıktıya "Vatandaş'ın ilk kullanımı..." ve "Lütfen Vatandaş'ı özenle kullanınız..." mesajları basılacak, [daha sonra yaratılacak] nesnelerin paylaşacağı ortak bir özellik olan _vatandaşSayısı 1 ile ilklenecektir. Aynı sınıfın nesnesinin yaratıldığı her noktada işlenen nesne ilkleme bloğu sayesinde ise, çağrılan yapıcı metodun başlaması öncesinde, ilklenmekte olan nesnenin sabit değerli _vatNo altalanı _vatandaşSayısı'nın o anki değeri ile ilklenecektir.

public class Vatandaş {
  // Sınıf ilkleme bloğu.
  static {
    System.out.println("Vatandaş'ın ilk kullanımı...");
    System.out.println("Lütfen Vatandaş'ı özenle kullanınız...");
  }
  // Nesne ilkleme bloğu.
  { _vatNo = _vatandaşSayısı++; }
  ...
  public static long vatandaşSayısı() {
    return _vatandaşSayısı - 1;
  } // long vatandaşSayısı() sonu
  ...
  static { _vatandaşSayısı = 1; }
  private String _ad, _anneAdı, _babaAdı;
  private String _yaşadığıÜlke;
  private final long _vatNo;
  private static long _vatandaşSayısı;
} // Vatandaş sınıfının sonu

Sınıf Tanımlama Reçetesi
Bazı Önemli Metotlar

Java Platformunun Dikkate Değer Bir Dili: Scala-1

2011-05-06T16:41:00.000+03:00

Başlık yazının konusunu ele veriyor: sınıf dosyasına derlenmek suretiyle JSM tarafından çalıştırılabilir programlar üretmekte kullanılabilecek Scala dili. .NET'in CIL komutları içeren DLL formatına da derlenebilen, fonksiyonel programlama kavramlarını destekleyen bu nesne yönelimli dil, Java'ya eklenmesi düşünülen pek çok kavram için bir laboratuar ve esin kaynağı olma özelliği taşıyor. Scala programlama diline dair dizimizin ilk bölümü olan bu yazıda da bu dili Java bilenlere tanıtmaya çalışacağız.

Basit bir Scala programı
Java programlama dili sınıflarının kullanımı
Diziler soysal bir türün örneğidir
İkinci yazı: Scala'da sınıf tanımı🔎

Basit Bir Scala Programı

Java'da olduğu gibi, Scala'da da her şey bir sınıf içine yazılmak zorundadır. Aslına bakılırsa, ilkel türleri de sınıflarla temsil eden Scala bu konuda Java'dan daha katıdır diyebiliriz. Bir diğer farklılık, ';' karakterinin pek çok C-temelli dil tarafından kabul edilen komut sonlandırıcılık görevindeki değişikliktir. Satır sonlarının komut sonlandırma noktası olarak algılanması nedeniyle, birden fazla komutun aynı satıra konulmaları durumunda kullanılması dışında, Scala'da komut sonlarına ';' yerleştirilmesine gerek yoktur.

SelamMillet.scala

object SelamMillet {
  def main(args: Array[String]) =
    println("Selam millet!")
} // SelamMillet sınıfının sonu

Yukarıda verilen kaynak kodda main metodunun dönüş türünün eksik olduğunu düşünüyorsanız, Scala'nın bir diğer özelliğini söyleyerek yanıt verelim: Scala, ML ve Haskell programlama dillerinde olduğu gibi, program metninin sağladığı bilgilerden yararlanarak programlama öğelerinin türlerini çıkarsamaya çalışır. Bundan dolayı, Scala programcılarının derleyicinin çıkarsayamadığı yerler dışında hiçbir yere tür bilgisi koymasına gerek yoktur. Derleyici tarafından kabul görmekle birlikte, main metodunun imzasının aşağıdaki şekilde yazılması gerekmez.

def main(args: Array[String]): Unit =

Örneğimizde sınıf kavramının izlerini arayanlar, kendilerini ikna etmekte zorlanabilirler. Zira, sınıf sözcüğü (class) yerini nesne sözcüğüne (object) bırakmıştır. Sınıfın bir şablon, nesnenin ise söz konusu sınıfın bir örneği olduğunu bilenleriniz bilgilerinden kuşku duymaya başladıysalar üzülmesinler, her şey eskiden olduğu gibi. Beklenen class sözcüğü yerine object sözcüğünün olması, tanımlanmakta olan sınıfın bir özelliğini yansıtmaktadır: Java terminolojisi ile açıklayacak olursak, SelamMillet sınıfının yegâne metodu olan main static'tir. Bir diğer deyişle, main metodu, SelamMillet sınıfının nesnesi yaratılmadan kullanılabilir. Nesne paradigması ile bağdaşmayan bu durum—problem çözümünde merkezi rol oynayan nesnenin bırakın kullanılmasını, yaratılması bile söz konusu değil—kimi zaman çalıştırılabilir sınıfın tek bir nesnesinin yaratılıp bu nesneye ileti gönderilmesi yoluyla aşılır. İşte, tasarım desenleri dünyasında tek örnek[li sınıf] (İng., singleton [class]) deseni olarak adlandırılan bu kullanım, Scala'da object anahtar sözcüğünün kullanımı ile belirtilir. Bu şekilde tanımlanmış sınıfların, tüm öğelerinin static olduğu varsayılır. Bundan dolayıdır ki, Scala'da static anahtar sözcüğüne yer yoktur, programcı bu tür özellikleri tek örnekli sınıflar içinde toplayarak bir object olarak tanımlamalıdır.

Kaynak kodun yazılması sonrasında yapılacaklar Java'daki ile aynıdır: ilk adımda sınıf dosyasına çevrilerek derlenen kod, JSM tarafından çalıştırılmalıdır.

# Derleme aşaması
$ scalac -encoding utf-8 SelamMillet.scala
$ ls SelamMillet*
SelamMillet.class   SelamMillet$.class   SelamMillet.scala
# Yorumlama aşaması
$ scala SelamMillet
Selam millet!

Yukarıdaki listelemenin iki noktası dikkatinizi çekmiştir. Öncelikle, Scala programlama dilinin derleyicisi olan scalac komutunun ürettiği iki tane sınıf dosyası vardır. Bunlardan, SelamMillet.class uygulama dosyası iken, SelamMillet$.class tek örnekli sınıf deseninin gerçekleştirildiği kodu içerir. İkinci nokta ise, JSM'nin java yerine scala komutuyla çağrılmasıdır. Bu, her programlama dili için JSM'nin ayrı ayrı gerçekleştirilmesi gerektiği yanılgısına neden olmamalıdır. Çünkü, scala komutu java komutunun Scala'ya has sınıf dosyalarını yükleyerek işini gören uyarlaması olarak düşünülebilir. Dolayısıyla, yorumlama aşması aşağıdaki şekilde de yapılabilir.

# Yorumlama aşaması
$ java -cp .:/usr/share/java/scala-library.jar SelamMillet
Selam millet!

Bunun güzel bir sonucu, çöp toplama, güvenlik denetimleri, anında derleme gibi JSM tarafından sağlanan pek çok hizmetin Scala programları için de otomatikman sağlanmasıdır; Scala dilinin (ve diğer JSM üzerinde çalışan dillerin) geliştiricilerinin bu hizmetleri ayrıca gerçekleştirmelerine gerek yoktur.

Java Programlama Dili Sınıflarının Kullanımı

JSM dili olmaları nedeniyle, gerek Java gerekse Scala, kurulumunuzun sınıf yolu üzerindeki tüm sınıf dosyalarını, kaynak kodları hangi dilde yazılmış olursa olsun, kullanabilir. Scala programcısı açısından bakıldığında bu, Scala kaynak kodu içinden Java platformunun bildik tüm işlevselliğinden sanki Scala'da yazılmış gibi yararlanılabileceği anlamına gelir. Bu, aşağıdaki örnekte verildiği gibi işlevselliği kullanmak şeklinde olabileceği gibi, platformdaki bir sınıftan kalıtlama veya bir arayüzü gerçekleştirme şeklinde de olabilir. Ancak, Java'dan gelip Scala kaynak kodu üretenlerin yararlanılacak işlevi Scala sözdizimi ile kullanmaları gerektiğini akılda tutmaları gerekir. Aşağıdaki örnek üzerinden görelim.¹

Açıklamalara Scala'nın Java ile farklılık gösteren bir özelliğine dikkat çekerek başlayalım: dosya içinde dosya ile aynı ada sahip bir sınıfın bulunması gerekmez; Scala'da böyle bir zorunluluk yok. Ancak, daha sonraki derleme/çalıştırma komutlarında örneği verildiği gibi, derleyiciye geçirilenin dosya adı iken yorumlayıcıya geçirilenin sınıf dosyasının adı olduğu unutulmamalıdır.

Örneğimizin Scala'ya yeni gelenler için dikkat çeken bir yönü, import bildiriminin ilk satırdaki seçimli kullanımı.² Tekli ve jokerli³ kullanımlara sahip bu bildirim, örneğimizde de olduğu gibi, bir veya daha fazla sayıda türün görünür kılınmasında da kullanılabilir. Dikkat çekecek bir diğer anahtar sözcük ise, simgesel sabit tanımlamak için kullanılan val.⁴

Örnek2.scala

import java.util.{Scanner, Vector}

object ScaladanJava {
  val grdKnl = new Scanner(System.in);
  println("İkinci Scala örneğine hoş geldiniz...")

  def main(args: Array[String]) = {
    val tekSayılar = new Vector[Int]()
    print("Artı bir tamsayı giriniz: ")
    val j = grdKnl.nextInt()
    for(i <- 1 to j by 2) tekSayılar.add(i)
    println("1 ile" + j + " arasındaki tek sayılar: " + tekSayılar)
  }

  println("Bu örnek Scala kodundan Java'da yazılmış işlevselliği kullanmaya dönük")
} // ScaladanJava sınıfının sonu

Metot gövdeleri dışındaki komutların varlığı da sizi telaşa sürüklemesin; bu komutların sınıf içindeki sıraları korunacak şekilde sınıf ve/veya nesne ilkleme bloğu içine konulduğunu düşünmeniz işinizi kolaylaştıracaktır. Tek örnekli bir sınıf olması nedeniyle tüm öğeleri static varsayılan sınıfımızda, metot tanımları dışındaki her şey sınıf ilkleme bloğuna konulup uygulamanın çalıştırılması sonrasında ilk iş olarak işlenirken, new işleci ile nesnesi yaratılabilen çok örnekli sınıflarda bu tür öğeler nesne ilkleme bloğuna konulacak ve sentezlenen bu nesne ilkleme bloğu her nesne yaratılışı noktasında yapıcı çağrısı öncesinde işlenecektir.

$ scalac -encoding utf-8 Örnek2.scala
$ scala ScaladanJava
İkinci Scala örneğine hoşgeldiniz...
Bu örnek Scala kodundan Java'da yazılmış işlevselliği kullanmaya dönük
Artı bir tamsayı giriniz: 16
1 ile 16 arasındaki tek sayılar: [1, 3, 5, 7, 9, 11, 13, 15]

Diziler Soysal Bir Türün Örneğidir

Verdiğimiz örneklerde komut satırından geçirilen argümanları tutmak için kullanılan dizi ve ikinci örneğimizdeki Vector nesnesinden de görülebileceği gibi, Scala'da soysallık tür parametrelerine karşılık gelen tür argümanlarının köşeli ayraç çifti arasında geçirilmesiyle sağlanır. Buna göre Vector[Int], Int türlü elemanlara sahip bir kabın kullanılacağını gösterir. Bu tanım sonrasında, söz konusu kap parametrik türün (java.util.Vector) sağladığı tüm işlevsellikten yararlanarak manipüle edilebilir. Bu, soysal Array türünün örneği olan diziler için de geçerlidir. Tanımlanan bir dizi, Array sınıfınca sunulan tüm işlevsellikten yararlanabilecektir.

Scala'da Sınıf Tanımı

Gözünüzden kaçmış olabilir, işaret etmekte yarar var: ilk örneğimizin aksine ikinci örneğimizin metot gövdesi kıvrımlı ayraç çifti arasına yazılmıştır. Bunun sebebi, tek komuttan oluşması durumunda Scala'daki metot gövdelerinin, tıpkı Java'daki if, while yapılarının gövdeleri gibi, kıvrımlı ayraç çifti arasına yazılmalarının zorunlu olmamasıdır. ↑
java.lang paketindeki türler, herhangi bir bildirime gerek olmadan Scala derleyicisi tarafından görünür hale getirilirler. ↑
Söz konusu paketin tümünü görünür kılan jokerli kullanım, Java'da "*" ile belirtilirken Scala'da '_' ile belirtilir. ↑
Tanımlayıcının güncellenebilir bir içerik tutabilmesi için val yerine var ile nitelenmesi gerekir. ↑

Bileşke Türler-Sınıflar

2011-05-02T19:09:00.006+03:00

Bir önceki yazımızda🔎 programlama dilinin sunduğu kavram dağarcığının çözülmekte olan probleminki ile örtüşmesi durumunda çözümün daha kolay olacağına değinmiş ve Java gibi genel amaçlı dillerde problem ve çözüm uzayları arasındaki kusursuz bir uyum beklentisinin genel olma iddiasıyla çelişeceğini söyleyerek, gerçek çözümün programcıya yeni bileşke tür tanımlama olanağı sağlamaktan geçtiğini ifade etmiştik. Bu yönde sunduğumuz ilk araç ise türdeş verilerin gruplanmasına yarayan diziler olmuştu. İkinci yazımızın konusu ise, türdeş olsun ya da olmasın, birbirleriyle ilişkili verilerin gruplanması ve bu veri öbeği üzerindeki makul işlemlerin tutarlı bir biçimde uygulanmasını sağlamak için soyut veri türleri tanımlamayı olanaklı kılan sınıf kavramı olacak.¹ Daha fazla uzatmadan başlayalım.

Matris.java

...

public class Matris {
  ...
} // Matris sınıfının sonu

Problem tanımında geçen ve Java platformunca doğrudan desteklenmeyen bir kavramın Java koduna aktarılması, söz konusu kavramın bizi ilgilendiren özelliklerini içeren bir sınıfın tanımlanması ile olur. Bu ise yukarıdaki gibi bir kod iskeletinin uygun tanımlarla doldurulması yoluyla sağlanır. Tanımların sağlanması sırasında, tanımları sağlayacak gerçekleştirimci(ler) ile sınıftan yararlanacak kullanıcıların farklı kitleler olduğu unutulmamalıdır; gerçekleştirimcilerin aksine kullanıcılar ayrıntılarla ilgilenmeyecek, sunulan işlevselliğin nasıl realize edildiğine değil, ne olduğuna bakacaktır.

Ne demek istediğimizi, Matris sınıfının içini matematikteki matris kavramının özellikleriyle doldurarak gösterelim. Ama ilk önce, nereden başlamamız gerektiği konusunda bir uzlaşıya varalım. Bu noktada, acemi arkadaşlar ve C/C++ gibi dillerden gelip bellek serilimleri ile oynamaya alışmış ustalara bir uyarı: soyut veri türü tanımlamaya türün yapısını belirleyen bellek seriliminden başlamak doğru olmaz! Mesela, aceleyle atılıp matris elemanlarını tutmak için iki boyutlu bir dizi tanımlamaya soyunmak yerinde bir hamle olmayacaktır. Zira, matris elemanlarını tutmak için iki boyutlu dizinin yanısıra, Vector içeren Vector veya sıra no-sütun no çifti anahtarıyla erişilen kıyım tablosu da kullanılabilir. Matris içeriğinin özelliklerine göre bir seçim bazen iyiyken bazen kötü olabilir.² Ayrıca, bu konudaki bir karar değişikliği gerçekleştirimimizdeki pek çok şeyin değişmesini gerektirecektir ki, kodumuzun güvenilirlik düzeyine olumsuz etkide bulunan bu tür şeylerden kaçınılmalıdır. Bunun yerine, işimize Java karşılığını ifade etmeye çalıştığımız kavramın değişmeyen yönlerini, özniteliklerini, belirleyerek başlamalıyız.

Biraz programlama yapmış olanlarınız, koda dökülmekte olan kavrama ait varlıkların belirleyici özellikleri olan özniteliklerin, aslında altalanlara verilen yeni bir ad olduğunu düşünebilir. Bu yanılgıyı, altalanların sınıf şablonu kullanılarak yaratılacak nesnelerin özel belleğini oluştururken, özniteliklerin diğer özniteliklerdan yararlanarak hesaplanmak suretiyle de temsil edilebileceğini vurgulayarak ortadan kaldıralım. Örnek olarak, bir üçgenin özniteliklerini düşünün. Kenar uzunlukları ve kenarlar arasındaki açılar, değil mi? Peki ama, bu altı özniteliğin altısı da üçgen kavramının karşılığındaki sınıfta altalan olarak karşılık bulmalı mı? Tabii ki hayır! İstenecek olursa, Sinüs kuralından yararlanarak işimizi dört altalanla da görebiliriz. Dolayısıyla, yapacağımız şey, her bir öznitelik için altalan tanımlamak değil, altalanların tanımını sonraya bırakarak öznitelik değerlerini döndüren/güncelleyen erişici/değiştirici metotları sağlamak olmalıdır.

public class Matris {
  public int sıraSayısı() { ??? }
  public int sütunSayısı() { ??? }
  public double eleman(int sıra, int sütun) { ??? }
  public void elemanGüncelle(int sıra, int sütun, double yeniDeğer) { ??? }
  ...
} // Matris sınıfının sonu

Kıs kıs güldüğünüzü görür gibi oluyorum. Ne de olsa, yukarıdaki metotların gövdesini sağlayabilmemiz için ne çeşit bir kap kullanacağımıza ve altalanlarımızın hangi öznitelikler olacağına karar vermemiz gerekiyor. Doğru ama, ben biraz sorumsuzluk göstererek bu itirazınızı umursamayacağım ve sanki çok güvendiğim birileri metot gövdelerini sağlamış gibi davranacağım. Bazen, hayal görmek de işe yarayabilir. Kabul ettiyseniz bir sonraki adıma geçelim: matrisler üzerinde uygulanabilecek işlemleri tanımlamaya. Ancak, ilk önce metot imzalarının yanlış olduğunu düşünenlerin kafalarındaki soruya yanıt verelim: Hayır, imzaların parametrelerinden biri eksik değil. Tanımlanan tüm işlemler bir matris nesnesi üzerinde etki yapacağı için, bu ortak nesnenin tüm metotlara saklı argüman olarak geçirildiği varsayılıyor. Yani, tüm metotlar işlerini ileti alıcı veya hedef nesne olarak da adlandırılan özel bir matris nesnesi bağlamında yapıyor.

public class Matris {
  ...
  public Matris çarp(Matris sağMatris) { ... }
  public Matris çarp(double skalar) { ... }
  public Matris çıkar(Matris sağMatris) { ... }
  public Matris ters() { ... }
  public Matris topla(Matris sağMatris) { ... }
  // diğer işlemler
  ...
} // Matris sınıfının sonu

Dikkatinizi çekmiştir, sınıf tanımımız çarp adında iki metot içeriyor ve metot adları matematikten alışageldiğimiz +, - ve * gibi evrensel işleçler arasından seçilmemiş. Bu, Java'nın metot aşırı yüklemeyi desteklerken işleç aşırı yüklemeyi desteklemediği anlamına gelir. Metot aşırı yükleme bağlamında, farklı imzalara sahip iki veya daha fazla sayıdaki metot aynı aduzayında yer alabilir. Dolayısıyla, metot adı ve parametre listesinden birisinin farklı olması metotların birlikte tanımlanmasına olanak tanıyacaktır. Parametre sayısının veya karşılıklı parametre türlerinin farklı olması, metot imzalarının farklı olması anlamına geleceği için, örneğimizdeki aynı adlı iki metodun aynı sınıfta tanımlanmaları bir sakınca doğurmayacaktır.³

Her şey yolunda gidip de sınıfımızı tamamladıktan sonra, böylesine bir sınıfın kullanımı aşağıda verilen örnekteki gibi olacaktır. main metodunun gövdesinde new işleci kullanılarak yaratılan 3x5'lik iki matrisin toplamı, m1'e, kendisini m2 ile toplamasını sağlayan topla iletisinin gönderilmesiyle elde ediliyor. İleti alıcı rolünü oynayan m1, iletinin gönderilmesi sonrasında çağrılan Matris sınıfındaki aynı adlı metodun çağrılması sırasında saklı argüman olarak geçirilirken m2 sıradan bir argüman olarak geçiriliyor.

...

public class MatrisKullanıcı {
  public static void main(String[] ksa) {
    Matris m1 = new Matris(3, 5);
    Matris m2 = new Matris(3, 5);
    // matrisleri doldur...
    Matris m3 = m1.topla(m2);
    ...
  } // void main(String[]) sonu
} // MatrisKullanıcı sınıfının sonu

Gelelim eksiklerimizi tamamlamaya. Son adımda listelediğimiz işlemlere karşılık gelen metotlar ile başlayalım. Nasıl ilerlememiz gerektiğine topla adlı metodun gerçekleştirimini vererek açıklık getirelim. Bu amaçla sağladığımız aşağıdaki koda dikkat edecek olursanız, metot gövdesinde altalan ve matris içeriğini tutan kaba herhangi bir atıf yok. Her şey, gerçekleştirim ayrıntılarını saklayan erişici/değiştirici metotlar vasıtasıyla yapılıyor. Dolayısıyla, erişici/değiştirici metotların gövdesini sağladığımız an bu metot gerçekleştirimi de işlevsellik kazanmış olacak. Böylesine bir yaklaşımın artısı, gerçekleştirdiğimiz algoritmayı soyut bir biçimde ifade etmemizi olanaklı kılması ve kodun doğruluğu hakkında daha kolay ikna olmamızı sağlamasıdır.

Kodda yabancı gelebilecek bir diğer öğe, this anahtar sözcüğünün kullanılışı. Özel bir tutacak adı olan this, metoda saklı argüman olarak geçirilen hedef nesneye atıfta bulunmak için kullanılır. Mesela, m1.topla(m2) şeklinde ifade edilen gönderi, ileti alıcı konumundaki m1'in this ile eşleştirilmesine neden olacaktır.

Hatalı gibi gözükebilecek bir diğer nokta, ileti alıcının metot gövdesinde kullanılmasının, ad çakışması sonucu derleme hatasının ortaya çıkacağı durumlar dışında, seçimlik olmasıdır. Yani, istenecek olursa this anahtar sözcüğünün kullanımı es geçilebilir. Bundan dolayıdır ki, m adlı yerel değişkenin ilklenmesinde kullanılan ifade hatalı değildir ve this.sütunSayısı() ile eşdeğerdir.

public class Matris {
  ...
  public Matris topla(Matris sağM) {
    int n = this.sıraSayısı(), m = sütunSayısı()
    if (n != sağM.sıraSayısı() ||
        m != sağM.sütunSayısı()) return null;

    Matris sonuç = new Matris(n, m);
    for (int i = 1; i <= n; i++)
      for (int j = 1; j <= m; j++)
        sonuç.elemanGüncelle(i, j, eleman(i, j) + sağM.eleman(i, j));

    return sonuç;
  } // Matris topla(Matris) sonu
  ...
} // Matris sınıfının sonu

Her şey bitti gibi. Ama durun daha nesnemizin yapısına, yani altalanların ne olacağına karar vermedik. İş böyle olunca, nesnelerimizi yaratırken nesne içeriklerinin ilklenmesi için çağrılacak olan yapıcı metotları da yazamadık. O zaman gelin, düşündük taşındık, iki boyutlu bir dizide karar kıldık diyelim ve bu eksikliği de tamamlayalım.

public class Matris {
  public Matris(int sıraSayısı, int sütunSayısı) {
    _kap = new double[sıraSayısı][sütunSayısı];
  } // yapıcı(int, int)

  public Matris(int sıraSayısı, int sütunSayısı, double ilkDeğer) {
    this(sıraSayısı, sütunSayısı);
    for (int i = 0; i <= sıraSayısı; i++)
      java.util.Arrays.fill(_kap[i], ilkDeğer]);
  } // yapıcı(int, int, double)

  public int satırSayısı() { return _kap.length; }
  public int sütunSayısı() { return _kap[0].length; }
  public double eleman(int i, int j) {
    return _kap[i - 1][j - 1];
  } // double eleman(int, int)
  public double elemanGüncelle(int i, int j, double yeniDeğer) {
    _kap[i - 1][j - 1] = yeniDeğer;
  } // double eleman(int, int)
  ...
  private double[][] _kap;
} // Matris sınıfının sonu

Kod parçasına açıklık getirmeye, hatalı gibi gözükebilecek yapıcı metotlar ile başlayalım. Nesne yaratılması noktasında, yerin ayrılmasını takiben nesnenin tutarlı bir ilk duruma getirilmesini sağlamak görevini gören ve sınıf ile aynı ada sahip yapıcıların dönüş türünün belirtilmesine gerek yoktur.^4,⁵ new işlecinin kullanılması bağlamında arka planda çağrılan yapıcılar, programcı tarafından doğrudan çağrılmaz. Dikkat çekici ikinci nokta, üç argümanlı yapıcımızın ilk satırı. İleti adı içermeyen bu kullanım, bir yapıcı içinden aynı sınıfın bir diğer yapıcısını çağırmak için kullanılır ve içinde bulunduğu yapıcının birinci komutu olmak zorundadır. Aksi bir durum, derleyici tarafından hata olarak görülecektir. Değinilmesi gereken bir diğer nokta, altalanımızın erişim niteleyicisinin private olması. Bu, altalanın sınıfa özel olduğu ve sadece içinde bulunduğu sınıfın diğer öğeleri tarafından kullanılabileceği anlamını taşır. Nesne yapısını dişarıdan soyutlayan böylesine bir kısıtlamanın sebebini anlamak için altalanın public varsayıldığı aşağıdaki örneği ele alalım.

...

public class MatrisKullanıcı {
  public static void main(String[] ksa) {
    Matris m1 = new Matris(3, 5);
    // matrisi doldur...
    Matris m2 = new Matris(3, 5);
    for (int i = 0; i <= m1.length; i++)
      for (int j = 0; j <= m1[0].length; j++)
        m2[i][j] = m1[i][j] * 7;
    ...
  } // void main(String[]) sonu
} // MatrisKullanıcı sınıfının sonu

Matrisi temsil etmek için iki boyutlu bir dizinin kullanıldığını kabul eden kod parçası, m1 matrisini 7 ile çarpmak için bu ön kabulü kullanmaktadır. Ancak, belki de marjinal bir hız artışı saplantısıyla yazılan bu kod, gerçekleştirimci ile kullanıcı arasında bir bağımlılık oluşturarak aslında zarar vermektedir. Zira, gerçekleştirimcinin matris temsilini daha önceden bahsettiğimiz alternatiflerden birine değiştirmesi, kullanıcı kodunun da—tek gerçekleştirimci kodu varken binlerce kullanıcı kodu olabileceğini unutmayın—değişmesi zorunluluğunu doğuracaktır. Bir başka deyişle, işlevsellik değişmediği halde gerçekleştirimcinin yaptığı bir değişiklik pek çok kullanıcıyı etkileyecektir. Önlenmesi gereken bu felaket senaryosu, kullanıcıya ne sorusunun yanıtını veren ve nadiren değişen öğelerin sunulması, değişme ihtimali bulunan ve nasıl sorusunun yanıtını veren altalanlar ve yardımcı metotlara erişimin kısıtlanması ile mümkün olur.⁶

Diziler
Nesne İlkleme
Bazı Önemli Metotlar
Paketler ve Sınıf Yolu
Kalıtlama

Yazımızın sınıf kavramını tanıtmaya yönelik olduğu ve anlamayı kolaylaştırmak adına paketler, ayrıksı durumlar gibi daha sonraki yazılarda anlatılacak bazı şeyleri es geçtiği söylenmeli. ↑
Örneğin, genelde küçük matrislerle uğraşacaksak, yerden maliyetli fakat hızlı işlemi olanaklı kılan bir veri yapısı seçilebilir. Ya da, 0 değerinin çok geçtiği seyrek matrislerde 0 değerlerini doğrudan tutmaktansa dolaylı yollardan belirtmeyi tercih edebiliriz.... ↑
Dönüş türü bilgisi aşırı yüklemenin geçerliliğinin denetiminde kullanılmaz. Buna göre, sınıfımıza double argüman alıp double döndüren çarp adlı bir metodun eklenmesi hataya neden olacaktır. Böylesine bir kuralın var oluş sebebi, metot dönüş değerinin göz ardı edilmesi opsiyonundan kaynaklanır. Dönüş değerinin göz ardı edilmesi durumunda hangi dönüş türlü metodun kastedildiği bilinemeyeceği için, derleyici ortaya çıkan muallak durumu hata olarak bildirecektir. ↑
Tüm altalanların ilklenmesine gerek yoktur. Bazılarının ilklenmemesi durumunda, Java derleyicisi söz konusu altalanların varsayılan bir ilkdeğere sahip olmasını garanti edecektir. Tamsayılar için 0, kayan noktalı sayılar için 0.0 ve mantıksal değerler için false olan varsayılan ilkdeğer, bileşke türler için tutacağın bir nesneyi göstermediğini belirten null olacaktır. ↑
Bir sınıftaki yapıcı sayısı ihtiyaca göre değişebilir. Gerekli gördüğü takdirde, programcı yapıcı yazmamayı da tercih edebilir. Bu durumda, Java derleyicisi tüm altalanlara uygun ilkdeğerler sağlayan bir argümansız yapıcı sentezleyecektir. Ancak, yapıcı sentezlemenin programcı tarafından sağlanan yapıcıların varlığında söz konusu olmayacağı akılda tutulmalıdır. ↑
Sınıf gerçekleştiriminin bitmesi, her şeyin bittiği anlamına gelmez. Kodun kullanıcılarla buluşması öncesinde, son bir aşama olarak, performansı düşüren noktalarda eniyilemeler (İng., optimization) yapılması düşünülebilir. ↑

Bileşke Türler-Diziler

2011-04-20T18:11:00.009+03:00

Bir problemin çözümü, problem tanımında geçen varlıkların çözüm ortamındaki araçlar tarafından doğrudan temsil edilmesi durumunda kolaylaşır. Mesela; bir çizimin çizgi, Bézier eğrisi, üçgen, kare gibi çeşitli geometrik nesneleri destekleyen ve bu nesnelere ilişkin çizme, döndürme, öteleme gibi uzmanlaşmış işlemleri sağlayan bir dil kullanılarak oluşturulması daha kolay olacaktır. Matris, denklem gibi matematiksel nesneleri ve ilişkin işlemleri doğrudan destekleyen Maxima ve Matlab gibi dillerin cebir problemleri çözmek için daha uygun olmasının sebebi de aynıdır. Her iki durumda da problem uzayındaki nesneler ile uygulanabilir işlemler ve bu öğelerin soyutlanmasıyla oluşturulan kavramlar ile çözümde kullanılan araçlar arasında eşleme çok basittir. Dolayısıyla, problem uzayını iyi bilen bir programcının üretken olması çok hızlı bir şekilde mümkün olabilmektedir.

Özel amaçlı diller için geçerli olan bu gözlem, Java gibi genel amaçlı olma iddiasındaki diller için geçerli değildir. Böylesine bir yaklaşım, söz konusu dili değişik ilgi gruplarının kavramlarıyla hantallaştıracak ve diğer ilgi gruplarına kullanılmaz hale getirecektir. Bunun yerine programlama dili, ilkel türler🔎 üzerine inşa edilen bir yeni tür tanımlama olanağı sağlar. İşte, yavaş yavaş Java'yı Java yapan bölgeye giriş yapacağımız bu yazıda, Fortran'ın ilk uyarlamalarından bu yana bizimle olan en eski [ve eskimeyen] tür işleciyle (İng., type operator) oluşturulan bileşke türlere, dizilere göz atacağız.¹ Ancak, kısaca türdeş verilerin gruplanmasıyla oluşturulan bileşke türler olarak tanımlanabilecek dizilere girmeden önce, diğer bileşke türlerde de sıklıkla kullanacağımız terminolojiyi oluşturacağız.

TutacakVeNesne.java

public class TutacakVeNesne {
  public static void main(String[] ksa) {
    String ad1 = new String("Tevfik");
    String ad2 = new String("Tevfik");
    String ad3 = ad1;
    System.out.println(ad1 == ad2);
  } // void main(String[]) sonu
} // TutacakVeNesne sınıfının sonu

$ javac -encoding utf-8 TutacakVeNesne.java
$ java TutacakVeNesne
false

Yukarıdaki programın çalıştırılması sonrasında 6. satırda yapılan eşitlik denetimi, kimilerinizin beklentilerine aykırı olarak, standart çıktıya—değiştirilmediği müddetçe ekran—false yazacaktır. Bunun sebebi 6.satıra gelinmesiyle oluşan bellek seriliminin aşağıdaki temsili resmi ile açıklanabilir. Görüleceği gibi, 3. ve 4. satırda yaratılan iki nesneye üç değişken kullanılarak atıfta bulunulmaktadır.

Nesne yaratmak için kullanılan new işleci, belleğin yığın bölgesinde yeri ayrılan nesnenin işlenebilmesi için bir tutacak² döndürmekte ve nesne döndürülen bu tutacağın değerine sahip tanımlayıcılar yoluyla dolaylı bir biçimde kullanılmaktadır. Buna göre, örneğimizde iki nesne yaratılmakta ve söz konusu nesnelerin tutacakları ad1 ve ad2 değişkenlerini ilklemek için kullanılmaktayken, ad1'in ad3'ü ilklemekte kullanılmasıyla iki tutacak³ da aynı nesneyi gösterir hale getirilmektedir. Bunun doğal bir sonucu olarak, tutacakları karşılaştırarak işini gören 6. satırdaki eşitlik denetimi de false döndürmektedir. Çünkü, temsil ettikleri nesnelerin içeriği aynı olmakla birlikte iki tutacak da farklı nesneleri göstermektedir. Eşitlik denetiminin nesne içeriği göz önüne alınarak yapılması isteniyorsa, ad1 tutacağına temsil ettiği nesneyi ad2 tutacağının temsil ettiği nesne ile karşılaştırmasını söyleyen equals iletisinin gönderilmesi gerekir. Aşağıdaki gibi yapılacak ileti gönderiminin sonrasında, ad1'in arkasındaki nesnenin türü olan String sınıfındaki equals metodu çağrılacak ve işlem tamamlanacaktır.

System.out.println(ad1.equals(ad2));

Programcının, yapısı hakkında tahminde bulunup nesneyi tutarsızlığa yol açabilecek binbir yoldan denetimsiz bir şekilde kullanımının önüne geçen bu özellik—tutacak nesne ayrımı—Java'nın programcının bilerek veya bilmeyerek kod güvenliğini tehlikeye atmasına izin vermeyeceğini gösterir. Her şey, nesnenin yaratılması sonrasında döndürülen tutacak aracılığıyla gönderilecek iletilerin çağrılmasına neden olacağı metotlar vasıtasıyla yapılır.⁴ Tutacak türü ile uyumlu olmayan ileti gönderimleri derleyici tarafından reddedilecektir.

Gelelim dizilere. Derleyici tarafından özel bir biçimde ele alınan sınıflar olan dizi türlerine ait nesneler, diğer bileşke türlü değerler gibi, yaratılır, kullanılır, ihtiyaç duyulmadıkları ilk noktada çöpe dönüşür ve gerekli olursa kapladıkları bellek alanı tekrar kullanılmak üzere çöp toplayıcı tarafından geri döndürülür. Ayrıca, bir dizi nesnesinin kullanımı sırasında eleman sayısının gereksinime göre artmayacağı, bu özelliğin nesnenin yaratılması noktasında sabitlendiği akıldan çıkarılmamalıdır. Aşağıdaki örnek üzerinden görelim.

Diziler.java

import java.util.Scanner;
import static java.lang.System.out;

public class Diziler {
  public static void main(String[] ksa) {
    Scanner grdKnl = new Scanner(System.in);
    int[] notlar = new int[3];
    for (int i = 1; i <= 3; i++) {
      out.print(i + ". notu giriniz: ");
      notlar[i - 1] = grdKnl.nextInt();
    }
    out.println("İkinci dizinin eleman sayısı: ");
    int[] yeniNotlar = new int[grdKnl.nextInt()];
    yeniNotlar = notlar;
    yeniNotlar[1] = notlar[1] + 5;
  } // void main(String[]) sonu
} // Diziler sınıfının sonu

Dizi nesnelerimizin yaratıldığı satırları ele alalım. 7 nolu satırdaki ilkleme komutunda dizi tutacağının adı olan notlar, int[] türüne sahip tanımlanıyor ve her üç elemanı da 0 ilk değerine sahip bir dizi nesnesini gösterecek şekilde ilkleniyor. 13. satırda, benzer bir işlem standart girdiden sağlanacak sayıda elemana sahip bir başka dizi için tekrarlanıyor. Dikkatinizden kaçmamıştır, her iki tutacak da int[] türlü ilan ediliyor; her iki durumda da eleman sayısına dair bilgi tanımda yer almıyor. Diğer bir deyişle, notlar ve yeniNotlar tutacaklarının ikisi de aynı türe sahip olacak şekilde tanımlanıyor.

Dizilere uygulanabilecek işlemler, eleman değerlerinin sorgulanması ve güncellenmesine sınırlıdır. Her iki işlem de, hedef elemanın sırasını belirleyen aritmetiksel deyimin arasına yerleştirildiği köşeli ayraç çiftini ([ ve ]) kullanır. İki işlemden hangisinin istendiği ayraç çiftinin kullanım yerinden anlaşılır. Örneğin, 15. satırdaki atama komutunun sol tarafındaki kullanım söz konusu diziye güncelleme yapıldığını gösterirken, sağ taraftaki kullanım sorgulama yapıldığına işaret eder. İşleme konu elemanın sırasını tayin eden ve indis olarak da adlandırılan aritmetik deyimin 0-başlangıçlı bir değer döndürmesi gerektiği unutulmamalıdır. Buna bağlı olarak, notlar dizisinin son elemanına aşağıdaki ifadeler ile erişilebilir. Opsiyonları anlamaya çalışırken, her dizi nesnesinde bulunan length adlı altalanın dizinin eleman sayısını tuttuğunu unutmayın.

notlar[2] = 333; // notlar[3] değil!!!
notlar[notlar.length - 1] = 333; // Daha iyi bir seçenek.

Belirlendikten sonra değişmeyen eleman sayısı, yenitNotlar dizisinde olduğu gibi çalışma anında belirlenebileceği için yukarıdaki kullanımlardan ikincinin seçilmesi yerinde olacaktır. Aksine bir tercih, her eleman sayısı değişiminde kodun ilişkin yerlerinde değişiklik yapma ihtiyacını doğurur.

Değineceğimiz bir diğer husus, eleman değerlerinin dizi nesnesinin yaratıldığı noktada sağlanması durumunda kullanılabilecek ve kaynak kodu anlamak açısından olumlu bir katkıda bulunan toptan ilkleme komutudur. Aşağıda örnekleri verilen bu komut sayesinde, dizi elemanlarına tanım noktasından farklı bir yerde atama yapılarak kodun uzamasına gerek kalmaz. Dikkat edecek olursanız, toptan ilklemenin kullanıldığı new işlecine dizimizin eleman sayısının verilmesi söz konusu değildir; programcının hatalı bir biçimde belirleme ihtimali bulunan bu değeri derleyici kendisi belirler.

int[] notlar = new int[]{60, 70, 80};
int[] yeniNotlar =
        new int[]{grdKnl.nextInt(), grdKnl.nextInt()};

Daha sonraki kimi yazılarımızda dönme şansını bulacağımız diziler konusunu, şu uyarıyı yineleyerek kapatalım: dizi türleri, derleyici tarafından özel bir biçimde ele alınan sınıflardır. Buna göre, örneğimizdeki notlar tutacağının yeniNotlar'a atanması, yeniNotlar'ın eskiden gösterdiği dizi nesnesini çöpe dönüştürür ve her iki tutacağın da aynı dizi nesnesini paylaşmasına neden olur. Dolayısıyla, bir dizi tutacağı yoluyla yapılacak güncelleme diğeri aracılığyla da görülecektir. Aşağıdaki temsili bellek seriliminden bunun nedenini daha kolay görebilirsiniz.

yeniNotlar = notlar;
yeniNotlar[1] = notlar[1] + 5;

İlkel Türler

Dizi Metotları

Sınıf Tanımlama Reçetesi

Değişken Uzunluklu Diziler

Dizilerin ilk olma şerefi, çalışmakta olan programın karalama defteri olarak düşünülebilecek birincil belleğin, genelde "kutucuklar" dizisi olarak kavramsallaştırılmasına dayanır. Dolayısıyla, sakın ola ki, bileşke türler içinde ilk olması nedeniyle dizilerin yararsız olduğunu düşünmeyin. Daha sonraki yazılarda değineceğimiz kimi olumsuz yönlerine rağmen, veri yapısı olarak dizilerin de kullanımının uygun olduğu pek çok durum olacaktır. ↑
Diğer dillerden aşırma sözcükleri kullanmayı profesyonelliğin belirleyici özelliği zannedenler, ki bu arkadaşlar genelde bir şey anlatmak için değil anlatmamak için konuşurlar, hendıl (İng., handle) demeyi yeğleyebilirler. Ancak, sözcük tercihimdeki mantığı açıklarsam bu arkadaşları da sanırım tarafımıza kazanabiliriz. Bunun için, bir tavayı yemek pişirmekte nasıl kullandığınızı düşünün. Tavanın tutacağı olan sapıyla değil mi? Dolayısıyla, nasıl ki, aklı başında insanlar tavayı sapı yardımıyla kullanırlar, nesneye aracısız erişim imkanının olmadığı Java'da nesneler tutacakları aracılığıyla kullanılırlar.

Bu noktada, nadiren de olsa tutacak yerine tutamak sözcüğünü önerenlere de ufak bir tavsiyem var. Bir şeye tutunmakta kullanılan gövde üzerindeki oyuk veya çıkıntıların adı olan tutamak, maalesef, doğru bir seçim değil. Çünkü, adını koymaya çalıştığımız kavram nesnenin gövdesinde bulunmuyor ve yapılan atamalarla değişik zamanlarda değişik nesneleri temsil edebiliyor. ↑
Bundan sonraki anlatımımızda, "... nesnesinin tutacağına sahip tanımlayıcı" demektense, tutacak demeyi tercih edeceğiz. ↑
Nesne paradigmasına sadık kalınarak yapılan bu anlatım her zaman geçerli olmayacaktır. static olarak nitelenen metotlar, sadece tüm sınıf üyelerinin paylaştığı ortak özellikleri kullanarak işini görür ve ileti gönderilmeden doğrudan çağrılırlar. ↑

boolean Türü ve İlkel Türler Arasında Tür Uyumluluğu

2011-04-15T11:31:00.003+03:00

İlkel türleri tanıtmaya devam ettiğimiz bu yazıda, çalışmakta olan programda bir koşulun oluşup oluşmadığını denetlemek amacıyla kullanılan boolean türüne baktıktan sonra ilkel türden değerlerin birbirleri yerine kullanılabilme özelliklerine göz atacağız.

`boolean` Türü

Koşullu ve yinelemeli komut işlemenin temeli olan doğruluk denetimi, boolean türlü sabitler olan true veya false değerlerinden birini üreten ilişkisel işleçlerin¹ kullanılmasıyla yapılır. Denetlenmesi istenen koşulun karmaşıklaşması durumunda ilişkisel işleçli ifadeler mantıksal işleçler² kullanılarak birleştirilebilir.³ Bir örnekle görelim.

Faktöryel.java

import java.util.Scanner;

public class Faktöryel {
  public static void main(String[] ksa) {
    Scanner grdKnl = new Scanner(System.in);
    System.out.print("Faktöryeli bulunacak sayı: ");
    int n = grdKnl.nextInt();
    System.out.println(n + "!: " + fakt(n));
  } // void main(String[]) sonu

  public static long fakt(int n) {
    if (n == 1 || n == 0)
      return 1;
      else return n * fakt(n-1);
  } // long fakt(int) sonu
} // Faktöryel sınıfının sonu

Programımız, standart girdi dosyasından—değiştirilmediği müddetçe klavye—girilen karakterleri tarayarak istenen türden veriler haline dönüştüren Scanner türündeki grdKnl kullanılarak alınan tamsayı değerin faktöryelini hesaplıyor. Bu amaçla yazılmış olan özyinelemeli fakt metodunun sonsuz döngüye girmesini engellemekte kullanılan koşul deyimi, eşitlik denetleme işleci (==) ile oluşturulan iki altdeyimin veya bağlacı (||) ile birleştirilmesiyle oluşturuluyor. Buna göre, metottan parametre değerinin 0 veya 1'e eşit olması durumunda 1, aksi takdirde parametrenin 1 küçük değerin faktöryeli ile çarpımı döndürülüyor.

Mantıksal türün sonradan eklendiği C'nin yerleştirdiği alışkanlıklar sonucu, C/C++'da bir koşulun oluşmama durumu sıfır-benzeri bir değerle (NULL, 0,0, 0, vd.) temsil edilebilirken, oluşma durumu sıfır-benzeri olmayan herhangi bir değerle temsil edilebilir. Tür güvenliğine önem veren Java'da bu alışkanlığın unutulması gerekecektir. Dolayısıyla, aşağıdaki kod parçası Java derleyicisi tarafından kabul edilmez.

if (n % 2)
  System.out.println(n + " çift değil");
  else System.out.println(n + " çift");

İlkel Türler Arasında Tür Uyumluluğu

C/C++ dünyasından aşina son satırların Java derleyicisi tarafından kabul görmemesi, tamsayıların boolean değerler ile tür uyumlu olmadığı şeklinde ifade edilir. C/C++ dilinin "Programcı hata yapmaz, hata gibi gözüken şey muhtemelen yaratıcı bir kestirmedir" anlayışına karşılık, "Programcı da bir insandır ve hata yapabilir" felsefesinden hareket eden Java, belirtiyi ciddiye alır ve olası hatanın başkalaşmasına izin vermeden programcıya en erken aşamada (derleme) durumu bildirmeyi tercih eder.

Tamsayıların mantıksal değerlerin yerine kullanılamamasına benzer bir şekilde, byte türlü bir tanımlayıcıya int türlü bir değer sağlanması da hata olarak görülecektir. Bunun sebebi, int türünün temsil aralığının byte türünün temsil aralığında bulunmayan değerler içermesidir. Mesela, yukarıda verilen Faktöryel.fakt metodunun parametre türü byte olacak biçimde değiştirilmesi hataya neden olacaktır. Çünkü, söz konusu metodun çağrıldığı satırda geçirilen argüman int türlüdür ve -2³¹ ile 2³¹-1 arasındaki herhangi bir değere sahip olabilir; buna karşılık, argümanın değeriyle ilklenecek parametre byte türlüdür ve -128 ile 127 arasındaki değerleri temsil edebilir. İşte bu yüzdendir ki, parametre türünün byte olarak değiştirilmesi durumunda geçirilen argüman değerinin aşağıdaki kod parçasında olduğu gibi biçimlendirilmesi gerekir.

import java.util.Scanner;

public class Faktöryel {
  public static void main(String[] ksa) {
    ...
    System.out.println(n + "!: " + fakt((byte) n));
  } // void main(String[]) sonu

  public static long fakt(byte n) { ... } // long fakt(int) sonu
} // Faktöryel sınıfının sonu

Pek çok—kesin olmak gerekirse, sekiz—ilkel türün varlığı, tür uyumluluğu konusunda karar verme işini zorlaştırabilir. Bu noktada, türlerin kayan noktalı ve tamsayı türler şeklinde dizilmesi imdadınıza yetişecektir.

double ⊃ float ⊃ long ⊃ int ⊃ short ⊃ byte
int ⊃ char
double ∩ boolean = ∅

Yukarıdaki geçişken üstküme-altküme ilişkisi ile resmedilen dizilim, en baştaki türün en kapsayıcı en sondakinin ise en az kapsayıcı olduğu şeklinde yorumlanmalıdır.⁴ Buna göre, double değerin beklendiği yerlerde diğer tüm sayısal türlerden değerler kullanılabilir. Buna karşılık, short değerin beklendiği yerlerde sadece byte türlü değerler kulanılabilirken, diğer tüm sayısal değerler ancak biçimlendirme yapılmak suretiyle kullanılabilecektir.

Dizilimde char türü için ayrı bir kapsama ilişkisinin tanımlanması, bu türün tamsayı türü olarak ele alınması durumunda eksi sayıları temsil edemeyecek olmasından kaynaklanır. Aynı büyüklükte bir alan kaplayan short -32768 ile 32767 aralığındaki değerleri temsil edebilirken, char 0 ile 65536 arasındaki değerleri temsil edebilir. Bir diğer deyişle, short'un char, char'ın short yerine konulması kimi zaman değer kaybına sebep olacaktır.

İlkel Tamsayı Türleri
Karakterler
Kayan Noktalı Sayılar

Yararlanılabilecek ilişkisel işleçler ve varlığı denetlenen ilişki çeşidi şunlardır: == (eşitlik), != (eşitsizlik), > (büyüklük), < (küçüklük), >= (büyük veya eşitlik), < (küçük veya eşitlik). ↑
Mantıksal değerleri birleştirmede kullanılabilecek bağlaçlar ve anlamları şunlardır: ! (değilleme), && (ve), || (veya). ↑
Gerekli görüldüğü takdirde, denetleme işinin tümü veya bir bölümü, yüklem olarak da adlandırılan boolean dönüş türlü bir metodun çağrılması ile yapılabilir. ↑
Aslına bakacak olursanız, tür uyumluluğu için üstküme-altküme ilişkisinin kullanılması yanıltıcı bir uygulama. Çünkü, long ile temsil edilen kimi değerler ne double ne de float ile temsil edilebilirken, int ile temsil edilen kimi değerler float ile temsil edilemez. Ancak, anılan türler arasında dizilimin önerdiği cinsten bir tür uyumluluğundan bahsetmek her zaman doğrudur. ↑

Java SE 7 İle Gelen Yenilikler

2011-04-13T19:43:00.002+03:00

Bu yazıda, pek yakında piyasaya çıkacak olan Java SE 7'nin Java programlama diline getirdiği yeniliklere göz atacağız. Yeni uyarlamanın tartışmalarını J2SE 5.0 ile eklenen yeniliklerin—soysallık🔎 (İng., generics), açımlamalar (İng., annotations), sabit listeleri (İng., enum types), vd.—getirdiği zorlu öğrenme eğrisini hatırlayıp içi ürpererek izleyenlere müjdeyi vererek başlayalım: daha önceleri eklenmesi düşünülen birim (İng. module) ve kod örtüsü (İng. closure) kavramlarının bir sonraki uyarlamaya bırakılması nedeniyle, yeni uyarlamanın J2SE 5.0'de olduğu gibi zorlayıcı olması söz konusu değil. Ama, siz yine de yerlerinizde rahat oturmayın; çünkü, bu sadece bir erteleme, her iki kavram da eninde sonunda Java dilinin üstkavram dağarcığına—yani, problem uzayındaki kavramları koda dökerken kullanılan kavramlar listesine—eklenecek.¹

Yeniliklerin içeriğine girmeden önce, okumakta olduğunuz yazının günlükteki diğer yazılardan belirgin bir farklılık gösterdiğini söylemekte yarar var. Daha öncekiler tek bir konuya odaklı ve basit içerikli iken, bu yazı Java altyapınızın sağlam olduğunu varsayıyor ve farklı konulara atıfta bulunuyor. Bir diğer uyarı da yenilikleri deneyip kullanmak isteyeceklere yönelik: söz konusu yeniliklerin hiçbiri yeni bir Bytecode komutu kullanılması sonucunu doğurmadığı için, Java SE 7 uyumlu bir derleyici ile üretilen sınıf dosyaları daha önceki uyarlamaların JSM'leri tarafından çalıştırılabilecektir.²

switch-case Komutlarında String Türlü Seçici İfade
İkili Taban Gösterimi ve Rakamların Gruplanması
Kaynak Yönetimli try Bloğu
Kotarıcı Paylaşımı ve Yeniden Fırlatmanın Yeni Anlamı
Sınırlı Tür Çıkarsama: Elmas İşleci
SafeVarargs Açımlaması

`switch-case` Komutlarında String Türlü Seçici İfade

switch-case komutlarındaki seçici ifadenin türü hakkındaki kısıtlamanın String türünü kapsayacak şekilde gevşetilmesi ile başlayalım. Buna göre, eskiden seçici ifadenin tamsayı türleri ve char'a kısıtlı olması nedeniyle geçerli olmayan aşağıdaki kod parçası, Java SE 7 ile birlikte Java derleyicileri tarafından kabul görecektir.

import java.util.Locale;
import static java.lang.System;
...
devamMı:
do {
  switch (seçim.toUpperCase(new Locale("tr"))) {
    case "EVET": case "YES": ...; break devamMı;
    case "HAYIR": case "NO": ...; break devamMı;
    default: out.println("Evet veya Hayır giriniz!!!");
  }
} while(true);
...

İkili Taban Gösterimi ve Rakamların Gruplanması

Bir diğer küçük yenilik, tamsayı sabitlerin artık 8'li, 10'lu ve 16'lı tabanın yanısıra 2'li tabanda da yazılabilecek olması. Ayrıca, sayısal sabitlerin, ister tamsayı türlü olsun isterse kayan noktalı, doğru ve çabuk algılanmasını sağlamak için altçizgi karakteri ('_') kullanılarak dilendiği gibi gruplanması da mümkün.

double bütçeAçığı = 8_000_000_000_000_000;
double piSayısı = 3.1415_92_6535_897_93;
short bayrakYazmacı = 0b0000_010010_000100;
...

Bir sonraki yeniliğe geçmeden bir uyarıda bulunalım: gruplama karakteri sayıyı oluşturan bileşenlerin (tamsayı kısmı, kesir kısmı, üs kısmı) başında veya sonunda kullanılamaz. Buna göre, aşağıdaki örneklerin hiçbiri Java derleyicisinin kabulünü görmeyecektir.

double bütçeAçığı = _8000_000_000_000_000;
double piSayısı = 3_.1415_92_6535_897_93;
short bayrakYazmacı = 0b0000_010010_000100_;
double büyükSayı = 0x1.2345p_123;
double küçükSayı = 0x1.2345p-123_;
...

Kaynak Yönetimli `try` Bloğu

Java'yı C/C++ dilinden ayıran temel özelliklerden birisi, geliştiricinin insan olduğu ve hata yapabileceği varsayımına binaen bazı sorumlulukları geliştiriciden derleyici ve sanal makine gibi sistem yazılımlarına aktarmasıdır. Bunun en bilinen örneği, çöp toplayıcı yardımıyla yığın bellek yönetimini yazılım geliştirme aşaması etkinliği olmaktan çıkarmasıdır.³ Ancak, çöp toplama desteği kaynak yönetme kaygılarının tamamen ortadan kalktığı anlamına gelmez; geliştiriciler yığın bellek dışındaki dosya, ağ bağlantısı, veri tabanı bağlantısı gibi kaynakları yönetmek zorundadırlar. Örnek olarak, bir veri tabanı tablosunun yazma kilidini düşünün. Kilidin sahibi olan program işini bitirip tabloyu serbest bırakmadıkça bir diğer programın aynı tabloda değişiklik yapması mümkün olmayacaktır; işin bitirilip ne zaman dönüleceğini ise ancak programı yazan geliştirici(ler) bilebilir. Dolayısıyla, bu tür kaynakların mümkün olan en erken noktada geliştirici tarafından döndürülmesi gerekir. Aksi bir durum, aynı kaynağın diğer kullanıcılarının boş yere beklemesi anlamını taşır. İşte bu yüzden, yeni uyarlama ile birlikte Java, try bloğu içinde yararlanılan kaynakların otomatik olarak döndürülmesini garanti ederek olası programcı hatasının önüne geçen kaynak yönetimli try bloğunu sunmaktadır.

Ne denmek istendiğini aşağıdaki kod şablonundan izleyerek görelim. İlk satırda, try'ı takip eden ayraç çifti arasındaki ilkleme komutu, Java derleyicisine program içinde d tanımlayıcısı yoluyla temsil edilen disk dosyasının otomatik olarak yönetilmesi istendiğini belirtiyor. Bu istemin yerine getirilmesi, işlenmesi ne şekilde sona ererse ersin, try bloğu sonunda söz konusu kaynağın geri döndürüleceği anlamına gelir.

try (FileInputStream d = new FileInputStream("Veri.dat")) {
  // d'yi kullan.
} catch (IOException e) { ... }

Örneğimiz otomatik olarak yönetilmesi istenen kaynağın Java SE 7 ile birlikte eklenen java.lang.AutoCloseable arayüzünü gerçekleştirmesiyle geçerlilik kazanır. Bu, java.lang.Closeable arayüzünün bu arayüzden kalıtlayacak şekilde tanımının değiştirilmesi nedeniyle, G/Ç sınıflarınca temsil edilen tüm kaynakların kaynak yönetimli try bloğuyla otomatik olarak yönetilebileceği anlamına gelir.

finally kotarıcısını (İng., handler) bilenleriniz—sabırsızlıklarını görür gibiyim—kaynak yönetimli try komutunun aslında pek de bir şey getirmediğini düşünebilir. Ne de olsa, yukarıda anlatılan işlev kaynak döndürme komutunu finally bloğu içine yazarak da sağlanabilir. Bir diğer deyişle, aşağıdaki kod şablonu da işimizi görecektir.

try {
  // d'yi kullan.
} catch (IOException e ) { ... }
  finally { d.close(); }

Bu itirazı seslendiren arkadaşlar bir yere kadar haklı. Ne var ki, şu iki nokta onları da ikna edecektir.

try ve catch bloklarının işlemesi sırasında JSM sonlan(dırıl)acak olursa veya söz konusu işletilen bloğun izleği (İng., thread) durdurulur veya sonlandırılacak olursa, finally bloğunun işletileceği garantisi verilemez.
Kaynak yönetimli try komutunun varlığı, programcıya hatırlatıcı olmasının yanısıra belgeleme yönüyle de katkıda bulunur.

Kotarıcı Paylaşımı ve Yeniden Fırlatmanın Yeni Anlamı

Kimi zaman, birden çok ayrıksı durum kotarıcısının aynı gövdeye sahip olması durumuyla karşılaşabiliriz. Aynı kodun tüm kotarıcılara tekrar tekrar yazılması, kod şişmesinin yanında gerekebilecek bir değişikliğin birden çok yerde yapılması sonucunu doğurur. İşte bu noktada, Java'nın yeni uyarlaması programcıya kotarıcı paylaşımı şansını verir. Buna göre, aşağıda verilen try bloğu içindeki komutların icra edilmesi sırasında AyrıksıDurumA veya AyrıksıDurumB türlü bir ayrıksı durum ortaya çıkacak olursa, aynı kotarıcı soruna çözüm bulmaya çalışacaktır.

...
try {
  // AyrıksıDurumA, AyrıksıDurumB veya AyrıksıDurumC türünde
  // ayrıksı durumların ortaya çıkabileceği bir şeyler yap.
} catch (AyrıksıDurumA | AyrıksıDurumB e} { ... }
  catch (AyrıksıDurumC e) { ... }
  finally { ... }
...

Kotarıcı paylaşımında şu nokta unutulmamalıdır: ayrıksı durum nesnesi kullanılarak kotarıcı içinde yapılacak şeyler kotarıcı parametresinin türlerinin ortak paydasına sınırlı kalacaktır. Dolayısıyla, yukarıda sağlanan paylaşım örneğinde e'nin kullanımı AyrıksıDurumA ve AyrıksıDurumB türlerinin ortak atasına gönderilebilecek iletilere sınırlı olacaktır. Bunun doğal bir sonucu olarak, parametrenin türleri arasında biri diğerinin atası olan sınıfların bulunması bir hata olarak görülecek ve söz konusu kod derleyici tarafından kabul edilmeyecektir.⁴

Hata kotarımını ilgilendiren ikinci yenilik, yeniden atılan ayrıksı durum nesnelerinin ele alınışına yönelik. Java SE 7 öncesinde hata verecek aşağıdaki kod parçasından izleyelim.

public void birMetot() throws AyrıksıDurumA, AyrıksıDurumB {
  ...
  try {
    birŞeylerYap(...); // AyrıksıDurumA fırlatabilir.
    başkaBirŞeylerYap(...); // AyrıksıDurumB fırlatabilir.
  } catch (Exception e} {
      ... // Bir şeyler yap.
      throw e;
    }
  ...
} // void birMetot() sonu

İşlerin yolunda gitmemesi halinde, birMetot metodundaki try bloğu, AyrıksıDurumA veya AyrıksıDurumB türlü bir ayrıksı durumla sonlanabilir. Ayrıksı durum nesnesinin fırlatılması sonrasında, Exception türlü parametreye sahip kotarıcı devreye girecek ve ortalığa çeki düzen verdikten sonra parametreyi yeniden fırlatarak topu metodun çağrıcısına atacaktır. İşte bu noktada, Java SE 7'nin farkı ortaya çıkıyor: derleyicinin try bloğu içinden çağrılan metotların imzalarını incelemesi sonucunda kotarıcıda yeniden fırlatılan nesnenin Exception değil de AyrıksıDurumA veya AyrıksıDurumB türünde olabileceği bilgisi korunuyor. Bu nedenledir ki, önceki uyarlamalarda Exception fırlatabileceği ilan edilmek zorunda kalınan birMetot, artık AyrıksıDurumA ve AyrıksıDurumB fırlatabileceğini ilan eden bir imza ile tanımlanabiliyor.

Bu bölümü küçük bir uyarı ile kapatalım: Değindiğimiz her iki yeniliğin kullanımında da kotarıcı parametresinin final olduğu varsayılır. Bir başka deyişle, söz konusu parametre yeni bir ayrıksı durum nesnesini gösterecek şekilde değiştirilemez; parametrenin değiştirilmesi anlatılan yeniliklerin kullanılmasını engeller.

Sınırlı Tür Çıkarsama: Elmas İşleci

Şapkadan çıkaracağımız bir sonraki yenilik de kendini derleyicinin yaptığı ek mesainin programcıya sağladığı kolaylıkla gösteriyor: tür çıkarsama. Ancak, Haskell veya ML bilenleriniz beklentilerini yüksek tutmasın. Çünkü, Java derleyicilerinin yeni uyarlamayla birlikte—soysallığın eklenmesi sonrasında sağlananın üstüne—sağlayacağı tür çıkarsama özelliği soysal türlerin nesnelerinin yaratıldığı kullanımlara kısıtlı. Derleyicinin tür çıkarsama için işaret olarak algıladığı <> karakterlerinin görünüşünden dolayı elmas işleci olarak da adlandırılan bu yenilik aşağıdaki gibi kullanılabilir.

import java.util.*;
...
Map<String, Vector<String>> sözlük =
  new HashMap<String, Vector<String>>();

Map<String, Vector<String>> yeniSözlük = new HashMap<>();

`SafeVarargs` Açımlaması

Göz atacağımız son yenilik olan SafeVarargs açımlaması, sınıf kitaplıkları yazanlarınız dışındakileri doğrudan etkilemiyor. Ancak, kitaplık kullanıcıları da kimi zaman anlamakta zorlandıkları derleyici uyarılarının azalması nedeniyle epey mutlu olacaklar. Ne kastettiğimizin anlaşılması için önce bu yeni açımlamanın ne zaman gerekeceğinin bir örneğini verelim.

SVÖrneği.java

import java.util.*;

public class SVÖrneği {
  public static void main(String[] args) {
    List<Integer> tl1 = Arrays.asList(1, 2, 3);
    List<Integer> tl2 = Arrays.asList(4, 5);

    List<List<Integer>> tll = Arrays.asList(tl1, tl2);
  } // void main(String[]) sonu
} // SVÖrneği sınıfının sonu

$ javac -encoding utf-8 -Xlint:unchecked SVÖrneği.java
SVÖrneği.java:8: warning: [unchecked] unchecked generic array creation of type java.util.List<java.lang.Integer>[] for varargs parameter
    List<List<Integer>> tll = Arrays.asList(tl1, tl2);
                                           ^
1 warning

asList metodunun işini nasıl yaptığını öngörebilen birisi olarak, aynı metodun çağrıldığı 5 ve 6. satırlar onaylanırken 8. satırın uyarı üretmesi, bazılarınıza garip gelebilir. Sanırım soysallıkla ilgili kısa bir açıklama bu arkadaşları ikna edecektir.

J2SE 5.0 sürümünde eklenen soysallığı kullanan kod ile J2SE 5.0 öncesindeki kodun bir arada kullanılabilmesi için derleme sırasında tür silme adı verilen bir dönüşüme başvurulur. Bu, soysal türlere dair tür argümanlarının korunmayacağı anlamını taşır. Mesela, örneğimizin 8. satırında argüman olarak geçirilen ve [statik] türleri List<Integer> olan tl1 ve tl2 değişkenlerinin türü List'e dönüştürülecektir. Dolayısıyla, çağırılan metot, argümanları değişik ve birbirinden bağımsız türlerden değerler içerebilecek List nesneleri olarak görecektir. Bu ise, çağrılan metodun bilerek ya da bilmeyerek Integer nesneler tutması beklenen liste(ler)i herhangi bir türden nesne tutacak hale döndürmesinin mümkün olduğu anlamına gelir. Buna karşın, derleyicinin böylesine bir kodu reddetmesi de, J2SE 5.0 öncesi ve sonrasında üretilmiş kodların bir arada çalışamayacağı anlamına geleceğinden, kabul edilebilir bir seçenek değildir. Çözüm, olası hataya dikkat çekmek için programcıya verilen bir uyarı ile sağlanır.

Örneğimizdeki uyarının ortadan kaldırılması 8. satır öncesine @SuppressWarnings("unchecked") açımlamasının konulması ile sağlanabilir. Java SE 7 öncesinde geçerli olan bu çözümün doğurduğu bir sorun, çok sayıda kullanıcısı bulunan metotlarda her kullanıcının söz konusu uyarı ile uğraşmak zorunda kalmasıdır. Bunun yerine, derleyicinin istediği garantinin metot gerçekleştirimcisi tarafından verilmesi daha yerinde olacaktır. İşte, SafeVarargs açımlamasının sağladığı budur. Örneğimize uyarlayacak olursak, Arrays sınıfının gerçekleştirimcilerinin kaynak kodu aşağıdaki gibi yazıp derlemesi tüm kullanıcıların yükünü omuzlarından alacaktır.

package java.util;
...
public class Arrays {
  ...
  @SafeVarargs
  public static <T> List<T> asList(T... değerler) { ... }
  ...
} // java.util.Arrays sınıfının sonu

Arrays.asList metoduna benzer şekilde SafeVarargs açımlamasıyla bezenen diğer Java platformu metotları aşağıda verilmiştir.

public static <T> boolean
  java.util.Collections.addAll(
    Collection<? super T> c, T... elemanlar)

public static <E extends Enum<E>>
  java.util.EnumSet<E> EnumSet.of(E ilk, E... gerisi)

protected final void
  javax.swing.SwingWorker.publish(V... parçalar)

Listedeki metotlardan da görülebileceği gibi, SafeVarargs açımlaması ile bezenmesi düşünülen metotların bazı özellikleri olması gerekir.

Yapıcılara ek olarak, ancak static veya final metotlara SafeVarargs açımlaması iliştirilebilir.
Yapıcı veya metodun değişken sayıda argüman alıyor olması gerekir.

Bu özellikleri taşımayan metotların SafeVarargs açımlamasıyla ilan edilmesi, derlenmekte olan sınıfın reddedilmesine neden olacaktır, haberiniz ola!

Adı geçen üstkavramlar hakkında bilgi edinmek için, şu videoları izlemek isteyebilirsiniz: Java birimleri, kod örtüleri. Bu videolar, bir sonraki uyarlama ile Java'ya giriş yapacak bu programlama kavramları ile ilgili gerekli bilgileri sağlayacaktır. ↑
Aslına bakarsanız, Java platformunun JRuby ve Jython gibi dinamik türlemeli dilleri kullanılarak yazılan programların daha hızlı çalışmasını sağlayacak bir yenilik, Java SE 7 ile birlikte gelen JSM'nin yeni bir Bytecode komutunu (invokedynamic) desteklemesi durumunu ortaya çıkardı. Dolayısıyla, bu diller kullanılarak yazılacak yeni programların derlenmesi sonucu oluşturulacak sınıf dosyalarının önceki uyarlamaların JSM'leri tarafından çalıştırılmaları mümkün olmayacaktır. Ancak, statik türlemeli olan Java kullanılarak yazılan programlarda böylesine bir durumun söz konusu olmaması nedeniyle bu bizi ilgilendirmiyor. ↑
Bu noktada, olası bir yanılgıyı düzeltip Sezar'ın hakkını Sezar'a vermemiz gerekli. Her ne kadar Java yaygın kullanımlı diller içinde çöp toplayıcı desteğini getirerek öncü rolünü oynamış olsa da, bu aslında Lisp-temelli dillerde 1960 yılından bu yana bulunan bir özellik. ↑
Biraz düşünüldüğünde bunun sebebi daha iyi anlaşılacaktır. Böylesine iki sınıfın ortak atası sınıflardan daha genel olanıdır ve kotarıcı parametresine gönderilecek iletiler bu sınıfın desteklediği iletilere sınırlı olacaktır. Yani, kalıtlayan sınıfın gönderilebilecek iletilerin belirlenmesinde—akılları karıştırmak dışında—hiçbir etkisi olmayacaktır. ↑

İlkel Türler-Kayan Noktalı Sayılar

2011-04-06T11:25:00.526+03:00

İlkel türler hakkındaki dizimizin üçüncü yazısında, matematikteki gerçel sayıların temsil edilmesinde kullanılan kayan noktalı sayı türlerine göz atacağız. Tamsayı türlerinin anlatıldığı yazıdan🔎 da tanıdık gelecek çoğul eki bu amaçla kullanılabilecek iki türe işaret ediyor: float ve double.

float ve double türlü değerlerin bellek gösterimi, gerçel sayıların temsili için tanımlanan ve pratikte tüm donanımlar (ve programlama dilleri) tarafından benimsenmiş olan IEEE754 standardına göre oluşturulur. Önerilen gösterimin ayrıntısına girmeden önce, anılan türlerin kullanımına dair şu uyarı yerinde olacaktır: tanım aralığındaki tüm değerlerin kusursuz bir biçimde temsil edildiği tamsayı türlerinin aksine, kayan noktalı sayı türleri tanım aralıklarındaki gerçel sayıların sadece bazılarını kusursuz olarak temsil edebilir, diğer sayılar ancak yaklaşık olarak temsil edilebilirler. Bu, tanım aralığındaki gerçel sayılar ile kayan noktalı sayılar arasında bire-bir bir ilişki olmadığı anlamına gelir. Bir diğer deyişle, aynı kayan noktalı sayı birden çok—aslında, sonsuz—gerçel sayıyı temsil eder. Dolayısıyla, aşağıdaki kod parçasının üreteceği çıktı bizi şaşırtmamalıdır. 3.14'ün yaklaşık temsil edilmesi nedeniyle 9.8596 olması gereken çarpma sonucu 9.859601 olarak hesaplanacak ve son satırdaki eşitlik denetimi beklenmedik bir yanıt üretecektir.¹

float pi = 3.14f;
float piKare = 9.8596f;
System.out.println(pi * pi == piKare); // ⇒ false

Değişkenlerin ilklenmesinde kullanılan ilk değerlerin sonundaki f—F de olabilir—sabitlerin float türünden ele alınması gerektiğini ifade etmek için kullanılır. Bu niteleyicinin yokluğunda, sabitin türü double olarak hesaba katılacaktır.²

Kayan noktalı tanımlayıcılara değer sağlamakta kullanılan sabitler değişik şekillerde yazılabilir.

double bütçeAçığı = 8000000000000000;
bütçeAçığı = 8e15; // 8.0e15 olarak da yazılabilir
bütçeAçığı = 80e14; // Yukarıdakiler ile aynı.
final float üç = 3.f; // 3.0f yazmak daha iyi bir fikir.

double dSayı = 0x49.0p0; // dSayı ← 73 (2^0(4*16^1+9*16^0))
dSayı = 0x4.9p4; // dSayı ↞ 73 (2^4(4*16^0+9*16^-1))
dSayı = 0x1.24p6; // dSayı ↞ 73 (2^6(1*16^0+2*16^-1+4*16^-2))
dSayı = 0xA.5p3; // dSayı ↞ 82.5 (2^3(10*16^0+5*16^-1))

Yukarıda verilen seçeneklerin kullanımında şu noktaların akılda tutulması yararlı olacaktır.

Sayının kesir kısmının var olması durumunda, 16'lı taban sadece bilimsel gösterimle birlikte kullanılabilir. Buna göre, Java derleyicisi 0x49 ve 0x49.0p0 seçeneklerini kabul ederken 0x49.0'ı reddedecektir.
Bilimsel gösterim sayılarda ölçekleme yapılırken, çarpan olarak 16'lı tabanda 2, 10'lu tabanda ise 10 kullanılır.

İlk kod parçasındaki eşitlik denetiminde▵ ortaya çıkan beklenmedik durumun nedenini daha iyi anlayabilmek için IEEE754'ün koyduğu kurallara bakalım. Öncelikle, gerçel sayıların temsilinde kullanılan kayan noktalı değerlerin içeriklerinin yorumlanmasında ortaokul yıllarından hatırlayacağınız (normalize edilmiş) bilimsel gösterimin temel alındığını söyleyerek başlayalım: kayan noktalı değerlerin içerikleri ∓i₀.i_-1i_-2...x2ⁿ şeklinde yorumlanır. Dolayısıyla, normalize edilmiş bilimsel gösterimde i₀'ın 0 olamayacağı düşünüldüğünde, kayan noktalı sayı bulunduran bellek bölgelerinin aşağıdaki gibi hesaplanan bir sayıyı tuttuğunu söyleyebiliriz.

∓1.i_-1i_-2...x2ⁿ = ∓(1 + i_-12^-1 + i_-22^-2 + ...)2ⁿ
Bir diğer deyişle, gerçel sayılar işaret bilgisi, kesir kısmındaki ikili basamaklar ve ölçeklemek amacıyla kullanılan üs değeri kullanılarak temsil edilirler. İşaret bilgisinin bir ikil ile gösterildiği float ve double türleri arasındaki fark, diğer iki özellik için ayrılan alanın büyüklüğünden kaynaklanır. Bu alanların büyüklüğü aşağıdaki tabloda verilmiştir.

*Kayan noktalı sayı türleri ve özellikleri*
Özellik		`double`	`float`
Uzunluk (ikil)	İşaret	1	1
	Üs	11	8
	Kesir	52	23
Duyarlık (Ondalık)		16	7
Merkez		1023	127

Temsil edilebilecek gerçel sayılara dair yoruma girişmeden önce, tablodaki özelliklerin sayının değerini nasıl etkilediğine bir bakalım.

İşaret ikilinin 0 olması sayının artı, 1 olması ise eksi olduğunu gösterir. Bu ikilin 1'e tümlenmesi—yani, 1 iken 0 veya 0 iken 1 yapılması—temsil edilen sayıyı -1 ile çarpma etkisini yaratır. Bunun doğal bir sonucu olarak, artı ve eksi sıfırdan bahsedilmesi de mümkündür.
Kesir kısmının en küçük değeri—tüm ikillerin 0 olması durumu—0 olabilirken en büyük değeri—tüm ikillerin 1 olması durumu—1-2^{-kesir uzunluğu} olabilir. Bu değerlerin, başta varsayılan 1 değerine eklenmesi mantis değerini [1..2-2^{-kesir uzunluğu}] aralığına taşıyacaktır. Ayrıca, 52 ve 23 ikili basamak duyarlığında temsil edilen sayılarımızın ondalık basamak türünden en yüksek duyarlığı, sırasıyla, 16 ve 7 olacaktır.³
[1..2-2^{-kesir uzunluğu}] aralığındaki mantisin eksi olmayan üs değerleriyle ölçeklenmesi sonucunda mutlak değerce 1'den küçük sayıların temsil edilemeyecek olması nedeniyle, üs kısmı tablodaki Merkez adlı maddedeki değerin sıfır noktası seçildiği bir tamsayı çizgisine eşlenir. Örneğin, float türlü bir sayının üs kısmının 130 olması, ölçeklemekte kullanılan üs değerinin 3 (130-127) olarak alınmasına neden olacaktır. Ayrıca, üs kısmının 1'lerle dolu gösterimi ∓∞ ve temsil edilemeyecek mutlak değerce büyük sayıları göstermek için kullanıldığından, en büyük üs değeri 2^{üs uzunluğu}-1-merkez olacaktır. Benzer şekilde, üs kısmının 0'larla dolu gösterimi ∓0 ve temsil edilemeyecek mutlak değerce küçük sayıları göstermekte kullanıldığından, en küçük üs değeri de 1-merkez olacaktır.

Buna göre, double ve float türlerince temsil edilebilecek en büyük değer, sırasıyla, (2-2^-52)2^2046-1023 ve (2-2^-23)2^254-127 olarak hesaplanacaktır.⁴ Temsil edilebilecek mutlak değerce en küçük sayılar ise, her iki tür için de 2^1-merkez formülü kullanarak bulunabilir. Bu değerler ve Java programları içinden bu değerlere atıfta bulunmak için kullanılabilecek simgesel sabit adları aşağıdaki tabloda verilmiştir.

*Kayan noktalı sayıların değer sınırları*
Sınır türü	`double`		`float`
En büyük	2¹⁰²⁴-2⁹⁷¹	`Double.MAX_VALUE`	2¹²⁸-2¹⁰⁴	`Float.MAX_VALUE`
En küçük	2^-1022		2^-126
En küçük (özel)	2^-1075	`Double.MIN_VALUE`	2^-150	`Float.MIN_VALUE`

Yukarıdaki tablonun son sırasında verilen değerler, üs kısmının tümüyle 0 olduğu gösterimde kullanılan özel hesaplamanın üreteceği değerlerdir. Bu özel gösterime sahip bir kayan noktalı sayının temsil ettiği değerin hesaplanması esnasında kesir kısmına 1 eklenmez ve sonuç kesir kısmı ile 2^-merkez'in çarpılması yoluyla elde edilir. Bu özel uygulama sayesinde, mutlak değerce daha küçük sayıların temsil edilmesi olanaklı kılınır.

Verilen sınırlar göz önünde bulundurularak, kayan noktalı sayı türlerinin hangi aralıktaki gerçel sayıları temsil edebileceği aşağıdaki şekille özetlenebilir. Şeklin incelenmesi sırasında temsil edilebilir aralıktaki sayıların bazıları dışında tümünün ancak yaklaşık olarak temsil edildiği unutulmamalıdır.

Kısaca açmak gerekirse;

➃ 0 noktasını, ➁ ve ➅ nolu bölgeler ise 0 dışındaki temsil edilebilir gerçel sayı aralıklarını gösterir. ➁ nolu bölgenin sınırları, double türü için [-Double.MAX_VALUE..-Double.MIN_VALUE], float türü için [-Float.MAX_VALUE..-Float.MIN_VALUE] olarak belirlenirken, ➅ nolu bölgenin sınırları, sırasıyla, [Double.MIN_VALUE..Double.MAX_VALUE] ve [Float.MIN_VALUE..Float.MAX_VALUE] olarak belirlenmiştir.
➀ ve ➆ nolu bölgeler mutlak değerce temsil edilemeyecek büyük gerçel sayıları, ➂ ve ➄ nolu bölgeler ise mutlak değerce temsil edilemeyecek küçük gerçel sayıları kapsar. ➀ ve ➆ nolu bölgelerdeki gerçel sayılar, sırasıyla, -∞ (Double.NEGATIVE_INFINITY veya Float.NEGATIVE_INFINITY) ve +∞ (Double.POSITIVE_INFINITY veya Float.POSITIVE_INFINITY) olarak ele alınırken, ➂ ve ➄ nolu bölgelere düşen gerçel sayılar, sırasıyla, -0 ve +0 olarak ele alınır.

Açıklık getirmek için aşağıdaki kod parçasını ele alalım. f1 değişkenini float tanımlayıcıların alabileceği en yüksek değerin 1 fazlasıyla ilklememiz sonrasında, ikinci satırda aynı değişkeni Float.MAX_VALUE ile karşılaştırıyoruz. Normalde yanlış olması gereken eşitlik denetiminin sonucu, söz konusu gerçel sayıların aynı kayan noktalı sayı ile temsil edilmesi nedeniyle, doğru sonucunu üretiyor. Sonraki iki satırda, en büyük float değer olarak hesaba katılan d1'in tersini bir kez daha d1 ile bölüyoruz. Sonuç, temsil edilemeyecek kadar küçük bir sayı olduğu için, 0.0 (ve -0.0) olarak ele alınıyor. Benzer bir durum, 5. ve 6. satırlar için de geçerli; bu sefer, işlemin sonucu temsil edilemeyecek kadar büyük olduğu için, f3 ve f4, sırasıyla, ∞ ve -∞ ile ilkleniyor. Kod parçasının son satırında ise, ∞'un -∞ ile bölünmesi, f5 değişkeninin "Sayı Değil" (İng., Not A Number) özel değeriyle ilklenmesi sonucunu doğuruyor.

float f1 = Float.MAX_VALUE + 1; // f1 ← 3.4028235E38
System.out.println(f1 == Float.MAX_VALUE); // ⇒ true
float f2 = 1 / f1 / f1; // f2 ← 0.0
f2 = -1 / f1 / f1; // f2 ↞ -0.0
float f3 = f1 * f1; // f3 ← Float.POSITIVE_INFINITY
float f4 = -f1 * f1; // f4 ← Float.NEGATIVE_INFINITY
float f5 = f3 / f4; // f5 ← Float.NaN

İlkel Tamsayı Türleri
Karakterler
Mantıksal Değerler

Bazılarınız, böylesine can sıkıcı bir durumun varlığını IEEE754 komitesinin yaptığı bir gafa bağlayabilir. Ancak, bilgisayarların sonlu makine olma özelliği ve herhangi bir gerçel sayı çifti arasında sonsuz sayıda gerçel sayı olması birlikte düşünüldüğünde, bunun çok haksız bir yakıştırma olduğu kolaylıkla görülecektir. ↑
Aslına bakarsanız, f ekinin konmaması örneğimizde bir hataya neden olmayacaktır. Ancak, ilkleme sonrasında değişkenlerimize benzer bir şekilde niteleyicisiz bir şekilde kayan noktalı sayı sabitlerinin atanmaya çalışılması derleyici tarafından reddedilecektir. ↑
Duyarlığın hesaplanmasında yapılması gereken, ikili basamak sayısını log₁₀2 değeriyle çarpmak ve çıkan sonucu bir üst tamsayıya yuvarlamak. ↑
1 + 1/2 + 1/4 + ... 1/2^-n ifadesinin 2-2^-n'e eşit olduğunu hatırlamanız, hesaplamanın doğruluğuna ikna olmanızı kolaylaştıracaktır. ↑

Tevfik AKTUĞLU-Java Programlama

Doğrusal Veri Kapları

Giriş

Genel Liste Arayüzü: java.util.List

Geziciler: java.util.Iterator ve java.util.ListIterator

Genel Liste Gerçekleştirimleri

Doğrudan Erişimli Listeler: java.util.ArrayList ve java.util.Vector

Kısıtlı Listeler: java.util.PriorityQueue ve java.util.ArrayDeque

Bağlaçlı Liste: java.util.LinkedList

Clojure, Java Platformunun Fonksiyonel Programlama Dili

Peki Ama, Neden Clojure?

Kurulum

Fonksiyonlar Birer Hesaplama Nesnesidir

Temel Veri Türleri

Veri Kapları

Fonksiyon Tanımı, Yeniden

Özyineleme

Hızlı Arama Zamanlı Kaplar-2

TreeMap Sınıfı

SortedMap Arayüzü

NavigableMap Arayüzü

Uzmanlaşmış Eşlemler

Hızlı Arama Zamanlı Kaplar-1

Giriş

Map Arayüzü ve AbstractMap Sınıfı

HashMap ve LinkedHashMap Sınıfları

Hashtable Sınıfı

Düzenli Deyimler

Temel Kullanım

Düzenli Deyim İçeriği

Karakter Sınıfları

Düzenli Deyim İşleçleri

Bayraklar

Öbekler

Eşleştirici Kipleri

Soysallık

Soysal Türlerin Tanımı ve Kullanımı

J2SE 5.0 Öncesi Kod İle Birliktelik: Ham Türler

Daha Esnek Metot İmzaları İçin Joker Türler

Soysal Metotlar

Soysallık ve Diziler

Hatasız Programcı Olmaz: Java'da Hata Kotarımı

Java Platformunun Dikkate Değer Bir Dili: Scala-2

Karakter Katarı Sınıfları

Değişken Uzunluklu Diziler: java.util.Vector

Yapıcılar

Desteklenen Arayüzler

Desteklenen İletiler

Kategorize Etmenin Yararları ve Arayüzler

Türlerin Evrimi ya da Kalıtlama

Java ve J'li Harf Çorbası

Bazı Önemli Sınıflar-java.util.Arrays

Arşiv Dosyaları

Arşiv Manipülasyonu

Arşiv Manifestosu

İndeksleme

Arşiv Kullanımı

Paketler ve Sınıf Yolu

Sınama Aracı Olarak BeanShell

Temel BeanShell

BeanShell Kaynak Dosyaları

Kod Örtüsü ve Nesneler

BeanShell İle Birim Sınama

Her Sınıfa Lazım Metotlar

Hoş Yazım

Eşitlik Denetimi

Kopyalama

Varsayılan Yapıcı

Karşılaştırma

Nesnelerin İlklenmesi

Java Platformunun Dikkate Değer Bir Dili: Scala-1

Basit Bir Scala Programı

Java Programlama Dili Sınıflarının Kullanımı

Diziler Soysal Bir Türün Örneğidir

Bileşke Türler-Sınıflar

Bileşke Türler-Diziler

boolean Türü ve İlkel Türler Arasında Tür Uyumluluğu

boolean Türü

İlkel Türler Arasında Tür Uyumluluğu

Java SE 7 İle Gelen Yenilikler

Genel Liste Arayüzü: `java.util.List`

Geziciler: `java.util.Iterator` ve `java.util.ListIterator`

Doğrudan Erişimli Listeler: `java.util.ArrayList` ve `java.util.Vector`

Kısıtlı Listeler: `java.util.PriorityQueue` ve `java.util.ArrayDeque`

Bağlaçlı Liste: `java.util.LinkedList`

`TreeMap` Sınıfı

`SortedMap` Arayüzü

`NavigableMap` Arayüzü

`Map` Arayüzü ve `AbstractMap` Sınıfı

`HashMap` ve `LinkedHashMap` Sınıfları

`Hashtable` Sınıfı

`boolean` Türü

`switch-case` Komutlarında String Türlü Seçici İfade

Kaynak Yönetimli `try` Bloğu

`SafeVarargs` Açımlaması