Effective Java Madde 29: Üreysel Türleri Tercih Edin

JDK tarafından sağlanan üreysel türleri (generic types) ve metotları kullanmak çok zor olmasa da, kendiniz üreysel türler yazmak istediğinizde biraz zorlanabilirsiniz ama bunu öğrenmeniz çok faydalı olacaktır.

Şimdi Madde 7’deki basitleştirilmiş yığıt (stack) gerçekleştirimine bakalım:

// Object tabanlı yığıt - üreysel tür olmak için müsait!
public class Stack {
    private Object[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;

    public Stack() {
        elements = new Object[DEFAULT_INITIAL_CAPACITY];
    }
    
    public void push(Object e) { 
        ensureCapacity(); 
        elements[size++] = e;
    }

    public Object pop() { 
        if (size == 0) {
            throw new EmptyStackException();
        }
        Object result = elements[--size];
        elements[size] = null; // kullanılmayan referansı kaldır 
        return result;
    }

    public boolean isEmpty() {
        return size == 0;
    }
    
    private void ensureCapacity() {
        if (elements.length == size) {
            elements = Arrays.copyOf(elements, 2 * size + 1);
        }
    } 
}

Bu sınıf en başından beri üreysel olmalıydı ama sonradan mevcut istemcilere zarar vermeden üreysele dönüştürmek de mümkündür. Bu haliyle, istemciler yığıttan okudukları değerleri kullandıkları türe kendileri dönüştürmek zorundadır. Bu tür dönüşümleri çalışma zamanında başarısız olup aykırı durum (exception) fırlatabilir.

Bir sınıfı üreysele çevirmek için ilk adım, sınıf tanımına bir veya daha çok tür parametresi eklemektir. Bizim örneğimizde eleman türünü temsil edecek şekilde tek bir tür parametresi yeterlidir. Eleman türünü temsil eden tür parametreleri genellikle E olarak isimlendirilir. (Madde 68)

Sonraki adım ise Object türü kullanılan yerlere yeni tanımladığımız tür parametresini yazıp programı derlemek olacaktır:

// Yığıtı üreysel türe çevirmek için ilk deneme. Derlenmez!
public class Stack<E> {
    private E[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;

    public Stack() {
        elements = new E[DEFAULT_INITIAL_CAPACITY];
    }

    public void push(E e) { 
        ensureCapacity(); 
        elements[size++] = e;
    }

    public E pop() { 
        if (size == 0) {
            throw new EmptyStackException();
        }
        E result = elements[--size];
        elements[size] = null; // kullanılmayan referansı kaldırın 
        return result;
    }
       ... // isEmpty ve ensureCapacity değişmiyor
}

Stack sınıfını yukarıdaki gibi üreysel türe dönüştürmeye çalışırsak aşağıdaki üreysel dizi yaratma (generic array creation) hatasını alırız:

Stack.java:8: generic array creation
        elements = new E[DEFAULT_INITIAL_CAPACITY];
                   ^

Madde 28’de anlatıldığı gibi E gibi tür parametrelerinden dizi yaratamayız. Bu problem, arka planda dizi kullanan üreysel türler yazmaya çalıştığınızda her zaman karşınıza çıkacaktır. Mantıklı bir şekilde çözmek için iki yol bulunur. Birincisi, diziyi E türünde yaratmak yerine Object türünde yaratıp sonradan E türüne dönüştürmektir. Yani yukarıdaki örnekte 8. satırı aşağıdaki gibi değiştirebiliriz:

elements = (E[]) new Object[DEFAULT_INITIAL_CAPACITY];

Bu kullanım geçerlidir ancak derleyici bu sefer hata yerine tür güvenliğini sağlayamadığı için uyarı verecektir.

Stack.java:8: warning: [unchecked] unchecked cast
   found: Object[], required: E[]
         elements = (E[]) new Object[DEFAULT_INITIAL_CAPACITY]; 
                        ^

Derleyici burada tür güvenliği olup olmadığından emin olamasa da, siz bunu kanıtlayabilirsiniz. Tabi öncelikle buradaki kontrolsüz tür dönüşümünün programdaki tür güvenliğini tehlikeye düşürmediğinden emin olmalısınız. Burada söz konusu olan elements dizisi private bir alanda saklanıyor ve istemciye asla döndürülmüyor. Diziye eleman eklenen tek yer push metodu. Burada da E türünde geçilen parametreler diziye eklendiği için tür güvenliğini sıkıntıya sokacak bir durum yoktur, dolayısıyla yapılan tür dönüşümü güvenlidir.

Tür dönüşümünün güvenli olduğunu kanıtladığımıza göre, derleyici uyarısını @SuppressWarnings("unchecked") notasyonu ile gizlemeyi deneyebiliriz. (Madde 27) Burada uyarıya sebep olan yapıcı metodun (constructor) tek yaptığı iş dizi yaratmak olduğu için, notasyonu yapıcı metoda uygulamakta bir sakınca yoktur. Yapıcı metot aşağıdaki şekilde güncellendiğinde sınıf hata ve uyarı vermeden derlenir:

// elements dizisi sadece push(E) tarafından eklenen E nesneleri
// içermektedir. Bu, tür güvenliğinin sağlanması için yeterlidir.
// Çalışma zamanında dizinin türü Object[] olacaktır, E[] değil.
@SuppressWarnings("unchecked")
public Stack() {
    elements = (E[]) new Object[DEFAULT_INITIAL_CAPACITY];
}

Stack sınıfı içerisinde üreysel dizi yaratma hatasını ortadan kaldırmanın ikinci yolu ise elements dizisinin türünü E[] yerine Object[] yapmaktır. Ancak bunu deneyince aşağıdaki gibi başka bir hata alırsınız:

 Stack.java:19: incompatible types
   found: Object, required: E
           E result = elements[--size];
                              ^

Burada artık elements bir Object dizisi olduğu için, diziden okunan değeri E türündeki referansta saklamamız tür uyumsuzluğundan dolayı mümkün olmuyor. Tabi biz okunan değeri E türüne dönüştürerek hatadan kurtulabiliriz. Stack sınıfında 20. satırı aşağıdaki gibi değiştirirsek:

E result = (E) elements[--size];

Sınıfı tekrar derleyince hata kaybolacaktır ama yine bir uyarı alırsınız:

Stack.java:19: warning: [unchecked] unchecked cast
   found: Object, required: E
        E result = (E) elements[--size]; 
                               ^

Bu ilk çözümde rastladığımıza çok benzer bir uyarı. Derleyici tür güvenliğini garanti edemediği için bizi uyarıyor. Ancak burada da biz tür güvenliği olduğundan eminiz, çünkü diziye eleman eklenen tek yer push metodu ve burada sadece E türünden elemanlar ekleniyor. Dolayısıyla okunan değer de E türünde olmak zorundadır. Madde 27’de anlatılan önerileri göz önünde bulundurarak, uyarıyı sadece buna sebep olan satır için gizliyoruz, pop metodu için değil:

// tür dönüşüm uyarısının doğru biçimde gizlenmesi
public E pop() {
    if (size == 0) {
        throw new EmptyStackException();
    }

    // push metodu sadece E türünden elemanlar eklediğinden 
    // tür dönüşümü güvenlidir
    @SuppressWarnings("unchecked") 
    E result = (E) elements[--size];
    elements[size] = null; // kullanılmayan referansı kaldırın
    return result;
}

Burada anlattığımız iki yöntem de kullanılabilir. Birinci yöntemde okunabilirlik daha yüksektir çünkü dizi sadece E türünden elemanları tuttuğunu açıkça göstermek için E[] türünde tanımlanmıştır. Ayrıca sadece bir yerde, dizi yaratılırken tür dönüşümü yapılmaktadır. Bu şekilde üreysel türler yazılırken çoğunlukla birden fazla yerde diziden okuma yapılır. İkinci yöntem bu sebeple dezavantajlıdır çünkü her okuma yapılan yerde tür dönüşümü de yapılması gerekir. Bu yüzden de pratikte genelde birinci yöntem tercih edilir. Ancak birinci yöntemin dezavantajı da dizinin çalışma zamanındaki türü ile derleme zamanındaki türü uyuşmadığı için yığın kirliliğine (heap pollution – Madde 32) sebep olmasıdır. (E türünün Object‘i temsil ettiği durumda bu problem yaşanmaz ) Bazı programcılar bu konuda çok hassas davranıp ikinci yöntemi tercih etmektedirler, ancak bizim örneğimizde yığın kirliliği zararsızdır.

Aşağıdaki program üreysel Stack sınıfının kullanımını örneklemektedir. Komut satırından geçilen argümanları ters sırada ve büyük harflere çevirerek yazdırmaktadır. String‘in toUpperCase metodunu çağırırken tür dönüşümü yapmaya gerek kalmamıştır:

// Üreysel Stack kullanımı
public static void main(String[] args) {
    Stack<String> stack = new Stack<>();
    for (String arg : args)
        stack.push(arg);
    while (!stack.isEmpty())
        System.out.println(stack.pop().toUpperCase());
}

Bu maddede verdiğimiz Stack örneği, diziler yerine listeler kullanmayı önerdiğimiz Madde 28 ile çelişebilir. Üreysel türler içerisinde dizi yerine liste kullanmak her zaman mümkün olmayabilir veya istenmeyebilir. ArrayList gibi bazı üreysel türler mecburen dizileri kullanacak şekilde yazılmıştır. HashMap gibi örnekler de performans kazanımı için dizilerden faydalanmaktadır.

Bizim Stack örneğinde olduğu gibi, üreysel türlerin büyük çoğunluğu herhangi bir kısıtlamaya gitmeden istediğiniz tür parametrelerini kullanmanıza izin verirler. Örneğin Stack<Object>, Stack<int[]>, Stack<List<String>> gibi kullanımların hepsi geçerlidir, istediğiniz herhangi bir referans türünden elemanlar tutan bir Stack yaratabilirsiniz. Ancak int, double gibi temel türleri tutan bir Stack yaratmaya çalışırsanız derleme hatası alırsınız. Bu, Java’da üreysel tür sisteminin kısıtlarından birisidir. Ancak bunların yerine Integer, Double gibi kutulanmış temel türleri (boxed primitive type) kullanarak bu sorunu aşabilirsiniz. (Madde 61)

Kullanılabilecek tür parametrelerinde kısıtlama yapan üreysel türler de mevcuttur. Örneğin java.util.concurrent.DelayQueue sınıfının tanımı aşağıdaki gibidir:

class DelayQueue<E extends Delayed> implements BlockingQueue<E>

Burada parametre olarak tanımlanan <E extends Delayed>, ifadesinin anlamı şudur: istemci tür parametresi olan E yerine sadece Delayed türünün bir alt türünü geçebilir. Bu şekilde DelayQueue sınıfı ve bu sınıfın istemcileri, DelayQueue‘nun elemanları için Delayed türünden gelen metotları da tür dönüşümüne gerek kalmadan ve ClassCastException riski olmadan kullanabilirler. Buradaki tür parametresi E aynı zamanda sınırlandırılmış tür parametresi (bounded type parameter) olarak da anılır. Java’da her tür kendisinin alt türü kabul edildiği için (JLS 4.10), DelayQueue<Delayed> geçerli bir ifadedir.

Özetle, istemcilerin kullanırken tür dönüşümü yapmak zorunda kaldığı türlere kıyasla üreysel türleri kullanmak hem daha güvenlidir hem de istemcilere kullanım kolaylığı sağlar. Yeni türler tanımlarken, istemcilerin tür dönüşümü yapmadan bunları kullanabileceğinden emin olun. Bu çoğu zaman bu türlerin üreysel olarak tasarlanması anlamına gelmektedir. Eğer üreysel olması gerektiği halde olmayan türleriniz varsa bunları güvenle üreysele dönüştürebilirsiniz çünkü mevcut istemciler etkilenmeyecek ve yeni istemciler için kolaylık sağlayacaktır. (Madde 26)

Share

Effective Java Madde 9: try-finally Yerine try-with-resources Tercih Edin

Java kütüphaneleri yazılımcının close metodunu çağırarak kapatması gereken birçok kaynak barındırır. Bunlara örnek olarak InputStream, OutputStream ve java.sql.Connection verilebilir. Bu kaynakları kapatmak (serbest bırakmak), istemciler tarafından sıklıkla unutulur ve bu durum ciddi performans sorunlarına yol açar. Bu kaynaklar her ne kadar finalizer (sonlandırıcı) kullanarak istemci tarafında yapılacak hatalara bir önlem almaya çalışsalar da, pratikte biz sonlandırıcıların iyi çalışmadığını biliyoruz. (Madde 8)

Önceleri, try-finally ifadesi kullandığımız kaynakların bir istisna (exception) fırlatıldığında dahi doğru biçimde kapatılmasını garanti eden en iyi yoldu.

// try-finally - Artık kaynakları kapatmanın en iyi yolu değil!
static String firstLineOfFile(String path) throws IOException { 
    BufferedReader br = new BufferedReader(new FileReader(path)); 
    try {
        return br.readLine();
    } finally {
        br.close();
    }
}

Bu çok da kötü görünmüyor, ancak ikinci bir kaynak daha eklediğimizde durum kötüleşiyor.

// try-finally birden fazla kaynakla kullanılınca kod çirkinleşiyor
static void copy(String src, String dst) throws IOException {
    InputStream in = new FileInputStream(src);
    try {
        OutputStream out = new FileOutputStream(dst);
        try {
            byte[] buf = new byte[BUFFER_SIZE];
            int n;
            while ((n = in.read(buf)) >= 0) { 
                out.write(buf, 0, n);
            }
        } finally {
            out.close();
        }
    } finally {
        in.close();
    }
}   

İnanması zor olabilir ama, iyi programcılar bile çoğu zaman bunu yanlış kullanmaktadır. Örneğin, Java Puzzlers kitabının 88. sayfasında ben de hata yaptım ve yıllarca hiç kimse fark etmedi. Dahası, 2007 yılında Java kütüphanelerindeki close metodu kullanımlarının üçte ikisi yanlıştı.

try-finally blokları doğru kullanılarak kod yazıldığı durumlarda bile (yukarıdaki iki örnek gibi), ortada küçük de olsa bir sorun bulunmaktadır. Hem try hem de finally bloklarındaki kodların istisna fırlatma ihtimali bulunmaktadır. Örneğin, ilk örnekteki firstLineOfFile metodunda, try bloğundakireadLine çağrısı fiziksel aygıttaki olası bir problemden dolayı istisna fırlatabilir, finally içerisindeki close çağrısı da aynı sebepten dolayı başarısız olabilir. Bu durumda, ikinci fırlatılan istisna birinciyi tamamen görünmez kılacaktır. Stack trace içerisinde birinci istisna görülmeyecektir, bu da problemi çözmeye çalışan kişileri çok zor durumda bırakacaktır. Çünkü genellikle bir sorunu çözmeye çalışırken ilk hatanın nereden kaynaklandığını görmek önemlidir. Bu sorunu çözmek için yukarıda verilen kodları geliştirmek mümkündür, ancak sonuçta oluşan kod daha karmaşık olduğu için bunu genellikle kimse yapmaz.

Bütün bu problemler Java 7 ile birlikte gelen try-with-resources ifadesiyle çözülmüştür. Bu ifadeyi kullanabilmek için kapatılması gereken kaynakların, void geri döndüren tek bir close metodu içeren AutoClosable arayüzünü uygulaması gerekmektedir. Java kütüphanelerindeki birçok sınıf ve arayüz bugün bu arayüzü kullanmaktadır. Eğer siz de kapatılması gereken bir kaynağı temsil eden bir sınıf yazarsanız, AutoClosable arayüzünü mutlaka uygulamalısınız.

Yukarıda verdiğimiz birinci örneğin try-with-resources ile kullanımı aşağıdaki gibi olacaktır.

// try-with-resources - kaynakları kapatmanın en iyi yolu!
static String firstLineOfFile(String path) throws IOException {
  try (BufferedReader br = new BufferedReader(new FileReader(path))) {
    return br.readLine();
  } 
}

Ve bu da ikinci örneğimizin try-with-resources ile yazılışı:

// try-with-resources birden fazla kaynakla kullanımı 
static void copy(String src, String dst) throws IOException {
    try (InputStream   in = new FileInputStream(src);
         OutputStream out = new FileOutputStream(dst)) {
        
        byte[] buf = new byte[BUFFER_SIZE];
        int n;
        while ((n = in.read(buf)) >= 0) {
            out.write(buf, 0, n);
        }
    }
}

Burada gördüğünüz gibi, istemcinin ayrıca close metodunu çağırmasına gerek kalmamaktadır. try-with-resources kullanıldığında AutoClosable arayüzünden gelen close metodu otomatik olarak çağrılmakta ve istemci tarafında yapılacak hatalara karşı önlem alınmaktadır.

try-with-resources ifadesiyle yazılan kodlar daha kısa ve okunabilir olmasının yanında, hataların teşhisini de kolaylaştırmaktadır. firstLineOfFile metodunu düşünecek olursak, eğer hem readLine metodu hem de görünmez close metodu istisna fırlatırsa, ikinci istisna birinciyi görünmez kılmaz, tam tersine birinci görülebilsin diye ikinci gizlenir (suppressed). Hatta ikiden daha fazla istisna fırlatıldığı durumlarda birden çok istisna da gizlenebilir. Çünkü yazılımcının ilk oluşan hatayı görebilmesi hatanın teşhisi açısından önemlidir. Burada saklanan istisnalar da aslında kaybolmazlar, stack trace içerisinde yine görülebilirler ancak gizlendiklerine dair bir ibare yer alır. Hatta bunlara Java 7’de Throwable sınıfına eklenen getSuppressed metoduyla programatik olarak da erişmek mümkündür.

try-with-resources kullanırken aynen try-finally kullanırken olduğu gibi catch blokları eklemek de mümkündür. Bu, sizlere iç içe katmanlar eklemenize gerek kalmadan kodunuzda oluşabilecek istisnaları ele almanızı sağlar. Pratikte kullanımı pek mantıklı gözükmese de, ilk örneğimizi aşağıdaki gibi değiştirerek istisna fırlatmak yerine, veri okumada bir hata oluştuğunda varsayılan bir değeri döndürecek şekilde yazabiliriz.

// try-with-resources catch bloğuyla kullanımı
static String firstLineOfFile(String path, String defaultVal) {
  try (BufferedReader br = new BufferedReader(new FileReader(path))) {
    return br.readLine();
  } 
  catch (IOException e) {
    return defaultVal;
  } 
}

Buradaki ders çok net: kapatılması gereken kaynaklarla çalışırken try-finally yerine try-with-resources ifadesini kullanmalıyız. Bu sayede ortaya çıkan kod çok daha kısa ve anlaşılır olacaktır, oluşabilecek hatalar sonucunda da teşhis yapmamız kolaylaşacaktır. Bu yeni yöntem, try-finally ile yazılması çok zor ve zahmetli olan kod parçalarının doğru biçimde yazılmasını son derece kolaylaştırmaktadır.

Share