Press "Enter" to skip to content

Effective Java Madde 51: Metot İmzalarını Dikkatli Tasarlayın

Last updated on August 18, 2021

Bu madde çeşitli API tasarım önerilerinin toplandığı bir yazı. Bu öneriler uygulandığı taktirde API’ınızın anlaşılmasını kolaylaştıracak ve hata ihtimalini minimuma indirecektir.

Metot isimlerini dikkatli seçin. İsimler her zaman için standart isimlendirme modellerini takip etmelidir. (Madde 68) Ana hedefiniz anlaşılabilir ve aynı pakette kullanılan diğer isimlerle tutarlı olan isimler seçmek olmalıdır. Uzun metot isimlerinden kaçının. Şüpheye düştüğünüz zaman Java kütüphanesinde yer alan API’lara bakın. Burada her ne kadar bazı tutarsızlıklar olsa da bu kütüphanelerin büyüklüğü ve kapsamı düşünüldüğünde çoğunlukla üzerinde fikir birliği kurulmuş isimlendirmeler olduğunu söyleyebiliriz.

Yardımcı metotlar yazarken aşırıya kaçmayın. Çok fazla sayıda yardımcı metot yazmak sınıfın bakımını, anlaşılmasını ve belgelenmesini zorlaştırır. Bu durum arayüzler için de geçerlidir. Geçerli kılınması gereken çok sayıda metot programcıların işini zorlaştırır. Sadece sıklıkla kullanılacağını düşündüğünüz yardımcı metotları ekleyin, eğer emin değilseniz eklemeyin.

Çok sayıda parametreden kaçının. Dört veya daha az sayıda parametre ile yetinmeye çalışın. Birçok programcı bundan daha fazlasıyla çalışırken hata yapabilir. Bu şekilde çok sayıda metodunuz varsa istemcileriniz sürekli olarak dokümantasyona başvurmak zorunda kalabilir. Her ne kadar IDE’ler bu konuda yardımcı olsa da parametre sayısını düşük tutmak her durumda avantajlıdır. Aynı türdeki parametre sayısının çok olması daha da zararlıdır. İstemciler bu parametrelerin sırasını karıştırabilirler. Bu durumda istemci kodları derlenecek, ancak çalışma zamanında istenmeyen davranışlar sergileyecektir.

Parametre sayısını azaltmak için üç yöntem vardır. Bunlardan bir tanesi metodu parçalamaktır. Böylece her biri az sayıda parametreye sahip birden fazla metot olacaktır. Ancak bunu da çok abartırsanız metot sayısı çok artabilir, bu yüzden dikkatli olunmalıdır. List arayüzü bu anlamda akıllıca tasarlanan örneklerden biridir.

Parametre sayısını azaltmak için kullanılabilecek ikinci yöntem ise yardımcı sınıflar oluşturarak bir grup parametrenin beraber tutulmasını sağlamaktır. Bu yardımcı sınıflar genelde statik üye sınıf olarak tanımlanırlar. (Madde 24) Eğer belli bir grup parametre sıklıkla tekrar ediyorsa ve bunlar mantıksal olarak bir bütünü ifade edebiliyorlarsa bu yöntemi kullanabiliriz. Örneğin, bir iskambil oyunu yazıyorsanız ve sıklıkla bir kartın takımını ve sırasını (örneğin maça 5) iki parametre olarak geçmeye başladıysanız, takım ve sıra değişkenleri ile kartı temsil eden bir sınıf yaratıp bunu parametre olarak kullanabilirsiniz.

Üçüncü yöntem ise Madde 2’de anlattığımız Builder tasarım deseni. Eğer çok sayıda parametre isteyen bir metodunuz varsa ve özellikle de bu parametrelerin bazıları isteğe bağlı ise bütün bu parametreleri tek tek geçmek yerine bunları temsil eden bir sınıf yaratılabilir ve istemci Builder tasarım desenini kullanarak bir nesne yaratıp metoda tek bir parametre geçebilir.

Parametre türleri için sınıflar yerine arayüz türlerini tercih edin. (Madde 64) Eğer sınıf türü yerine kullanabileceğiniz ve sınıfın uyguladığı bir arayüz var ise onu kullanın. Mesela, girdi olarak HashMap türünde parametre alan bir metot yazmanın bir gereği yoktur, bunun yerine Map arayüzünü kullanın. Böylece istemciler sadeceHashMap değil, TreeMap, ConcurrentHashMap veya başka bir Map gerçekleştirimini de gönderebilirler. Arayüz yerine sınıf türü kullanmak istemcileri kısıtlar ve esnekliği azaltır.

Boolean parametrelerin tam olarak neyi temsil ettiği metot adından anlaşılmıyorsa, bunun yerine iki elemanlı enum türlerini tercih edin. Enumlar kodun okunmasını ve anlaşılmasını kolaylaştırır. Ayrıca ileride yeni seçenekler eklenmesini mümkün kılar. Örneğin, statik bir fabrika metodu olan ve aşağıdaki enum türünü kabul eden Thermometer isimli bir türümüz olsun:

public enum TemperatureScale { FAHRENHEIT, CELSIUS }

İstemciler için nesne yaratırken Thermometer.newInstance(TemperatureScale.CELSIUS) kullanmak Thermometer.newInstance(true) ifadesine göre çok daha anlaşılır olacaktır. Dahası, ileride TemperatureScale enum türüne KELVIN türünü eklemek çok kolaydır. Ayrıca enum türleri metot tanımlamaya izin verdiği için ileride eklenebilecek özellikler için büyük esneklik sağlar. (Madde 34)

Share

Leave a Reply

%d bloggers like this: