2 Aralık 2011 Cuma

Hızlı Arama Zamanlı Kaplar-2

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.🔎

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.1

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.


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.2 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.


  1. 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.
  2. 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

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 durumlar1 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ş


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.2

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:
  1. 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.]
  2. Diğer eşlem sınıflarının aksine, Hashtable anahtar değeri olarak null değerinin kullanılmasına izin vermez.
  3. 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.

  1. Ç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.
  2. 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.

23 Kasım 2011 Çarşamba

Düzenli Deyimler

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.1 İ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.2 İ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, isMirroredjavaMirrored'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"

  1. İki yöntem ile bir programın doğrudan yorumlanması ve Bytecode gibi bir aradile çevrildikten sonra yorumlanması arasında koşutluk kurabiliriz.
  2. 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.

10 Kasım 2011 Perşembe

Soysallık

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.1 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.2 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.3

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:
  1. 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.
  2. 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.4
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


  1. 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.
  2. 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.
  3. 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.
  4. 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.