Yazı dizisi olan yayınlamaya başladığım Java Kodunuzun Nesne-Merkezli Olmadığının 10 İşareti başlıklı yazıların ilkinde aşırı statik metot kullanımını ele almıştım. Bu yazıda bir yerde şöyle dedim:

“… (statik metotların aşırı kullanımı) Programlamada yeni olan ya da tamamen prosedürel dünyaya alışkın programcıların Java kodu yazmaya başladıklarında sıklıkla karşılaştıkları bir durumdur. Problemli olan şey, statik kullanımının bulaşıcı ve yayılma eğiliminde olduğu gerçeğidir. Bir sınıf oluşturup üzerine statik metotlar ve alanlar koymaya başladığınızda kısa sürede kendinizi sadece statik metot yazarken bulacaksınız.”

Evet doğru, bir kere statik kullanmaya başladınız mı, her şeyin artık statik olarak devam etmesini engelleyemezsiniz. Statik kullanmada, bahsettiğim yazıda açıkladığım gibi bir problem yok, doğru yerde kullandığınız müddetçe.

Statik kullanımının nasıl bulaşıcı olduğunu göstermek için genelde Java’ya giriş eğitimlerinde kendi kendime konuşarak bir oyun oynarım, bir monolog yani. Bu oyundaki kişi yeni yetişmekte olan bir Javacıdır. Bu Javacı okulda almış olduğu örneğin “Java ile nesne-merkezli programlamaya giriş” isimli dersin hocasının verdiği program örneğinin benzerini eve gelip, kendisi yapmaya çalışmaktadır. Tek derdi bir değişkene bir değer atayıp sonra da onu ekrana basmaktır. Yani şöyle bir sınıf yazar:

public class MyFirstOOProgram {

	private int i = 5;

	public static void main(String[] args) {
		System.out.println(i);
	}
}

Yukarıda da görüldüğü gibi yeni bir Javacı ya da nesne-merkezli programlamaya yeni başlamış olan arkadaşımızın yapmak istediği şey, bir nesne değişkeni tanımlayıp sonra da main metodunda onu print etmektir. Son derece masum bir istek 🙂 Evet “i”yi nesne değişkeni olarak tanımlıyor ama aslında derdi “nesne değişkeni” tanımlamak değil, çünkü daha nesnenin ne olduğunu bilmiyor, henüz kafasına oturmuş durumda değil. Derdi sadece bir değişken tanımlayıp onu print etmek. Aslında bu değişkeni main metotta tanımladığında problem olmuyor ama main metodunun dışında tanımladığında problem olduğunu görüyor. Derleyici “System.out.println(i);” satırında problem veriyor ve “Can not make a static reference to non-static variable i” gibi bir mesaj veriyor. Tabi sonuçta yeni Javacı için bu mesaj hiç bir anlam ifade etmiyor.

Yeni Javacımız bu problemin üstesinden gelmeye kararlı. Ve programcılığın gereği olarak başlıyor hatayı giderebilmek için programın orasıyla burasıyla oynamaya. Amaç bu “i” 5 olarak basılacak 🙂 Lafı uzatmayalım, pek çok denemeden sonra “i” değiskenini tanımladığı satıra “static” anahtar kelimesini koyduğunda yani satırı “private static int i = 5;” şekline getirdiğinde programı çalışıyor. Yani yeni Javacı olan arkadaşın ilk nesne-merkezli programı basit bir “static” eklemesiyle şu hale geldi ve çalıştı;

public class MyFirstOOProgram {

	private static int i = 5;

	public static void main(String[] args) {
		System.out.println(i);
	}

}

Nesne-merkezli programlamayı bilmeyen, muhtemelen kendisine “Google programcısı” sıfatı daha uygun düşen arkadaşımız, “i” değişkenini instance için tanımlamak yerine class için tanımlar hale gelince problemini çözdü ama o böyle düşünmüyor. Eksik olan şeyin “static” olduğunu düşünüyor. Olması gereken, artık nesne-merkezli programlama yaptığının farkında olup, “i”nin bir nesne içın tanımladığı gerçeğininden hareketle print edilecek ‘i”nin basit bir değişken olmayıp, bir nesnenin parçası olduğunu ifade etmesiydi. Yani “i”yi statik yapmak yerine önce bir nesne tanımlayıp sonra sonra o nesnenin “i” değişkenini print etmeliydi:

public class MyFirstOOProgram {

	private int i = 5;

	public static void main(String[] args) {
         MyFirstOOProgram object = new MyFirstOOProgram();
		System.out.println(object.i);
	}

}

Nesne yaratıp o nesnenin üzerinden “i”ye erişmek yerine “i”yi statik yapınca probleminin çözüldüğünü düşündü ve bütün bu maskaralık da burada başladı zaten. Bakın devamında ne oluyor.

Arkadaşımız bir de metot yaratıp, onun içinde “i”yi print etmek ister. Ve bu amaçla programa bir “f()” metodu ekler:

public class MyFirstOOProgram {

	private static int i = 5;

	public static void main(String[] args) {
		System.out.println(i);

		f();
	}

	public void f() {
		System.out.println(i);
	}

}

Tabi derleyici bu sefer de main metodundaki “f();” satırında problem verir. Ve, arkadaşımız ne düşünür? “İster misin problem f() metodunun statik olmaması olsun?”. Ve “f()” metodunu da statik yapar:

public class MyFirstOOProgram {

	private static int i = 5;

	public static void main(String[] args) {
		System.out.println(i);

		f();
	}

	public static void f() {
		System.out.println(i);
	}

}

Bu kod da

5
5

basar ve görev tamamlanır. Kısa bir denemeden çıkan ana fikir şudur: Java’da her şeyi statik yaparsan her şey yolunda gider. Bir problem varsa bir yerleri statik yaparak çözebilirsin.” 🙂

Yukarıdaki koda artık ne eklerseniz statik olmak zorundadır. Herhangi bir yeni değişken class değişkeni, herhangi bir metot da sınıf metodu olmalıdır. İşte bu yüzden “static” anahtar kelimesi bulaşıcıdır.

Aslolan statik değil nesnedir. O yüzden “nesne-merkezli” programlama diyoruz.

Toplam görüntülenme sayısı: 1548

Ne mutlu biz Javacılara ki Java SE 8 çıktı. Bu durum merakımızı tetikliyor ve heyecanlandırıyor bizi. Belki işimizi yaparken Java SE 8 kullanmaya daha çok zaman olsa bile iş dışı zamanlarımızda nelerin yeni olarak dile eklendiğini merak ediyoruz. Gerçi çıkış öncesinden takip ediyorduk, beta sürümlerini indirmiştik vs. ama son halinin heyecanı başka tabi.

Java’nın Oracle’in eline geçmesinden itibaren büyük bir ivme kazandığı ve bu sayede hem  SE’de hem de EE’de yeni sürümlerin arka arkaya geldiği bir gerçek. Açıkçası her yeni sürüm yep yeni özellikler de getirdiğinden, her ne kadar ilk bakışta çok heyecan verici görünse de bu durum nihayetinde Java-severlere ne kazandıracak bunu zaman gösterecek. Fakat şu gerçek ki Java gittikçe daha büyüyor, daha karmaşıklaşıyor ve tabi olarak da daha güçleniyor. Aslında Java “minimalist” bir dil olarak çıkmıştı. Bir şeyi yapmanın olabildiğince bir ve basit olan yolunu içinde barındırmayı seçmişti. Gosling’in 90lı yıllardaki konuşmalarını hatırlıyorum da, örneğin dilin ilk başlarda enumeration yapısına sahip olmaması, tamamen bu amaca yönelikti: Basit ve küçük bir dil. Ama artık Java’nın ne kadar basit olduğu tartışılır. Ne kadar büyük olduğu ise pek tartışılacak gibi değil, bayağı büyük. Bu anlamda Java SE 8, Java tarihindeki en büyük değişiklikleri içeriyor. Belki sayıca az ama etki alanı olarak geniş değişiklikler söz konusu. Java’ya fonksiyonel programlama yetkinliklerinin kazandırılması sanırım. Hadi hayırlısı…

Bir Javacı olarak ilk yapılacak 4-5 adım bence şu:

1. JDK 8‘i indirmek.
2. Java SE 8’in API’sini indirmek (JDK ile aynı sayfadan.)
3. JDK 8 Demos and Samples’ı indirmek. (JDK ile aynı sayfadan.)
4. Java SE 8 Tutorial‘ı indirmek.
5. Java SE 8 Specification‘unu indirmek.

Ayrıca isterseniz Netbeans 8‘i ya da Eclispe Kepler‘i indirebilrisiniz.

Öte yandan Java SE 8 ile nelerin geldiğini merak ederseniz buraya bakabilirsiniz. Arkadaşlarımızdan Yaşar Safkan da blogunda sağolsun Java SE 8’e hızlı bir giriş yapmış.

Profesyonel ortamlarda Java Se 8’e geçmek açıkçası hemen oalcak bir şey değil. Kullanılan Java SE’nin sürümünü güncellemek öyle ha deyince olacak bir şey değil. Hele pek çok yerde hala Java SE 5 ve 6 kullanılıyor ve henüz Java SE 7’ye bile geçilmemişken.

Neyse, ben de yakında Java SE 8 ile ilgili yeni özellikler üzerine yazacağım burada.
Bol Java SE 8’li günler dilerim.

Toplam görüntülenme sayısı: 2636

Geliştirdiğimiz Java kodunun nesne-merkezli olmadığının 10 işaretinin neler olduğunu bu yazıda listelemiştik. Şimdi de bu listedeki ilk maddeyi ele alalım:

Sınıflarda aşırı miktarda statik metot kullanımı. (Excessive use of static methods in classes.)

Kodunuzdaki statik metotların sayısı, kodunuzun ne kadar nesne-merkezli olduğunun göstergesidir. Hiç statik metota sahip olmayan bir yazılım düşünmek pek de mümkün değildir ama statik metotların kullanımının istisnai durumlardan çıkarak genel bir hal kazanması, yaklaşımınızın nesne-merkezli olmaktan çıktığının kanıtıdır.

Nesne-merkezli programlamada esas olan, nesne kullanmaktır; statik metotlar ise nesne oluşturmadan, sınıf üzerinden programlama yapmanın yoludur ve bu yüzden de nesne-merkezli programlamanın varlık sebebine karşı bir durum oluşturmaktadırlar. Dolayısıyla aslolan, nesne metotlarının (instance methods) kullanılması, statik metotların ise tamamen istisnai sebeplere bağlı olarak yazılmasıdır. Ne kadar çok statik metot kullanırsanız nesne-merkezli programlamadan o kadar çok uzaklaşıp prosedürel programlamaya o kadar yaklaşmış olursunuz.

Statik metot kullanıp nesne metotu kullanmamak, yazılımı geliştirirken nesneye ihtiyaç duymamak demektir. Bunun birkaç sebebi olabilir:

İlk sebep, nesne-merkezli bir yaklaşıma sahip olmayıp, bundan dolayı nesne üretmemektir. Bu durumda nesne-merkezli bir dil kullanılsa bile yaklaşım nesne-merkezli değildir, daha çok prosedüreldir.

Konu ister iş alanı nesneleri, isterse de algoritmik yapıdaki davranışları içeren servis nesneleri olsun, temelde sadece statik metotlar tercih etmek nesne oluşturmadan nesne-merkezli programlama yapmak anlamına gelmektedir ki bu durum eğer çok özel bir sebepten kaynaklanmıyorsa nesne kavramını ve nesne-merkezli programlamayı bilmemek demektir. Programlamada yeni olan ya da tamamen prosedürel dünyaya alışkın programcıların Java (ya da nesne-merkezli herhangi bir başka dil kullanarak) kodu yazmaya başladıklarında sıklıkla karşılaştıkları bir durumdur. Problemli olan şey, statik kullanımının bulaşıcı ve yayılma eğiliminde olduğu gerçeğidir. Bir sınıf oluşturup üzerine statik metotlar ve alanlar koymaya başladığınızda kısa sürede kendinizi sadece statik metot yazarken bulacaksınız.

İkinci sebebi ki bu çok daha meşru bir hali ifade eder, çünkü bu durumda metot hakikatten de nesnenin kendisine özel olan durumunu değil, nesnelerin ortak değerlerde barınan durumuna bağımlıdır. Bu durumda nesnelerin ortak durumu, statik değişkenlerle ifade edilir ve bu ortak duruma erişen metotların da statik olmaları normaldir. Bu anlamda statik metot kullanımı, olmadığında sıkıntılı ve verimsiz olacak halin sağlıklı bir şekilde çözülmesinde ibarettir. Örneğin Singleton tasarım şablonunda bir tane yaratılmış olan nesnenin “static” olması ve o nesneye ancak yine “static” olan bir metottan ulaşılması bir zorunluluktur:

public class Singleton {

	private static Singleton singleton = new Singleton();

	private static int count;
	private String name;

	private Singleton() {
		count++;
		name = "Singleton" + count;
	}

	public static Singleton getInstance() {
		return singleton;
	}

	public void printName() {
		System.out.println(name);
	}
}

Nesnesiz programlama yapmanın uçüncü sebebi ise nesne oluşturmanın anlamsız olduğu durumlardır. Bu gibi hallerde durum da vardır ve bu durum üzerinde çalışan metotlar da vardır ama durum ve metotların üzerinde tanımlandığı yapının nesne olması konusunda çok da açıklık yoktur. Böyle hallerde sınıfın kendisinin nesne olarak davranmasını bekleriz. Örneğin “Tanrı” diye bir sınıfımız olsa bu sınıftan kaç tane nesne üretmeyi düşünürdünüz? Eğer çok tanrılı bir dine inanmıyorsak, olsa olsa bir tane Tanrı nesnesi üretmek yeterli olurdu. Bu durumda hiç nesne oluşturmadan Tanrı sınıfını nesne gibi kullanmak dolayısıyla da bu sınıfın üzerindeki her türlü durumu ve davranışı statik yapmak son derece anlamlı olur.

Dolayısıyla bazen ya kavram o kadar soyuttur ki gerçekte bir nesne ile ifade etmezsiniz ve sınıfı nesne olarak kullanırsınız ya da kavramınızın verdiği hizmetler hiç bir şekilde o sınıftan üretilecek nesnelerin farklı olacak durunmlarına bağlı değildir. Java APIsindeki java.lang.Math sınıfı buna çok güzel bir örnektir. Math sınıfının nesnesini oluşturmanın anlamı yoktur, çünkü onun sınıfını yukarıdaki Tanrı sınıfında olduğu gibi olsa olsa ancak bir tane nesneye sahip olabilir (eğer tek bir evrenimiz varsa ve evrenin her yerinde aynı Matematik geçerliyse 🙂 )bu yüzden sınıfını nesne olarak kullanabiliriz. Ayrıca Math sınıfının metotlarının davranışı bu sınıftan oluşturulacak nesnelerin durumuna bağlı değildir. Dolayısıyla Math sınıfından nesne oluşturmadan üzerindeki statik metotlar sayesinde ondan hizmet alabiliriz.

Math sınıfına benzer tabiatta olan, yani nesne modelinin bir parçası olmayan, araçsal (utility) metotlar da genelde statik olurlar çünkü ya nesnelerin durumlarına göre değişen davranışa sahip değildirler, tüm durum bilgisi zaten statik olan sınıfın durum bilgisinden ibarettir ya da gerekli bilgiyi zaten çağrılırlarken dışarıdan argüman olarak alırlar. Bu gibi metotların bulunduğu sınıflardan nesne oluşturmak, çoğunlukla iş alanını modelemeye bir katkıda bulunmadığı gibi, kod kalabalığı yapıp, belleği de şişirirler. Örneğin loglama vb. işleri yapan bu tip metotlar da genel olarak statik metotlar olarak ifade edilirler. Dolayısıyla statik metotların bu gibi durumlarda özenle ama doğru bir şekilde kullanılması şarttır.

Bazen, gereksiz nesne oluşturmama gibi masum bir amacın, bol statik metot kullanımına yol açtığı görülmektedir. Gereksiz nesne oluşturma, belleğin gereksiz kullanımına dolayısıyla da, bellek kaçağı (memory leak), performans ve ölçeklenirlik (scalability) problemlerine yol açar. Ama bu durumun tedavisi “hiç nesne oluşturmamak” değildir. Yani “nesneler belleği şişiriyor dolayısıyla nesne oluşturmayıp statik metotlarla çalışıyoruz” demek daha büyük sorunlara yol açacaktır. Eğer hakikatten bellek kullanımı bu kadar önemli ve kritik ise, bunun mimari bir ihtiyaç olarak ortaya konması ve bu seviyede çözümünün aranması daha doğru bir yaklaşım olur. Böyle bir çalışma, nesne merkezli bir dil kullanmak yerine bellek konusunda daha cimri olan prosedürel bir dil kullanmak gibi bir karar ile de sonlanabilir. Ya da Java kullanarak ve bellek konusunda daha tedbirli davranarak da bu sorunu çözebilirsiniz. Nesne oluşturmaktan kaçınmanın ana sebebi nesnenin “gereksiz” değil olsa olsa “anlamsız” olmasıdır. Yukarıda bahsedilen Tanrı ya da java.lang.Math sınıfı gibi, modellenen işin bir parçası olmayan, dolayısıyla işle ilgili nesneden nesneye değişen bir duruma sahip olmayan, araçsal sınıflar ve genelde onların statik olan metotları olmasaydı (ve dolayısıyla da biz bu sınıfların metotlarını ancak nesneleri üzerinden kullanabilir olsaydık,) bellek probleminden çok daha önce kod yapımızla ilgili problemler yaşardık. Çünkü bu gibi sınıfların nesnelerini yaratmak çoğu zaman çok fazla bilgi gerektirir ve bu durumu aşmak için nesne üretici (factory) yapılar gibi başka tasarım desenlerine ihtiyaç duyardık.

Uzun lafın kısası, statik metot kullanımını şu durumlarla sınırlı kılmak, bu durumlar dışında daima nesne oluşturup, nesne metotlarını kullanmak gereklidir:

• Nesne yaratmanın anlamsız olduğu durumlar. Bu durumlarda sınıfı, nesne olarak kullanabilirsiniz. Nesne yaratılsa bile sadece bir nesneye ihtiyaç varsa ki bu durum Singleton tasarım şablonuna karşılık gelir, sınıfın kendisini o tek nesne yerine, sanki nesneymiş gibi kullanılabilir. Böyle durumlarda hala nesne kullanımını tercih etmek burada açıkladığımız sebeplerden dolayı daha uygun olabilir.
• Metodunuz, üzerinde çağrılacağı nesnenin hiç bir nesne değişkenini (instance variable) kullanmıyorsa, yani nesnenin durumuna ulaşmıyorsa, statik metot kullanabilirsiniz. Çünkü statik metotlar statik olmayan değişkenlere ulaşamazlar.
• Metodun çağrılması için bir nesneye ihtiyacınız yoksa statik metot kullanabilirsiniz. Özellikle aynı nesnenin pek çok farklı bağlama geçilip, hepsinde kullanılması gibi durumlarda, farklı bağlama nesne geçmek yerine orada doğrudan sınıf üzerindeki statik metotları çağırmak son derece kolaylıktır. Özellikle araçsal davranışlara sahip (utility) sınıfları bu şekilde yazılımın her bölgesinde kullanmak anlamlıdır.
• Birden fazla nesne metodu tarafından ortak kullanılacak, nesnenin değişkenlerine ulaşmayan ve muhtemelen dışarıya da açılmayacak kodlar statik metotlarda tutulabilir.

Statik kullanırken iki kere düşünün 🙂

Toplam görüntülenme sayısı: 2031