Bir önceki yazıda arayüzlerdeki bir gerçekleştirmeye sahip olan metotlara giriş yapmıştık.

Java SE 8 ile birlikte gelen, arayüzlerde varsayılan metot kullanımı, default method, işin içine girdikçe kafamızı karıştırmaya devam edecek gibi görünüyor. Bende hep öyle olur. Bir konuyu öğrenirken başta çok karmaşık gibi gelmez ama sıklıkla, ilerlemeyle birlikte durum çetrefilleşir ve olmadık yerlere çıkar. Bu durum tabi olarak büyük keyif verir, zekanızı zorlar, sizi düşünmeye iter ama geldiğiniz noktanın acaipliği hep aklınızda kalır.

Bakın arayüzlerde default metot kullanımının bizi getirdiği yere. Hangisinden başlayalım? Çoklu mirası (multiple inheritance) ele alalım önce.

C++’tan bilirim, eğer bir alt sınıf, aynı virtual olmayan metoda sahip iki sınıftan miras devralıp da o metodu override etmezlerse, probleminiz var demektir. Eski zamanlardan hatırladığım şey bu duruma “diamond problem” ya da “deadly diamond of death” dendiği. Java’da bir sınıftan devralma anlamında çoklu mirasa izin verilmeyişi, sadece arayüzlerden devralma anlamında çoklu mirasın söz konusu oluşu, bu problemi şu ana kadar ertelemişti. Ama arayüzlere default metot koyunca durum değişti. Bakın, Artist bir arayüzümüz ile onun alt arayüzleri olan Actor ve Musician arayüzlerimiz olsun:

package org.javaturk.oofp.ch04.multipleInheritance;

public interface Artist {
	
	void play();
}

package org.javaturk.oofp.ch04.multipleInheritance;

public interface Actor extends Artist{
	
	default void play(){
		System.out.println("Actor plays!");
	}
}

package org.javaturk.oofp.ch04.multipleInheritance;

public interface Musician extends Artist{
	
	default void play(){
		System.out.println("Musician plays!");
	}
}

Yukarıdaki henüz tamamlanmamış elması, Actor ve Musician arayüzlerininden devralan ama “play()” metoduna bir gerçekleştirme vermeyen MusicianActor sınıfı ile tamamlayalım:

package org.javaturk.oofp.ch04.multipleInheritance;

public class MusicianActor implements Actor, Musician{

}

MusicianActor‘ün araryüzünde “play()” metodu var ama hangi gerçekleştirmeye sahip? Gelinen noktada, “diamond problem” ile karşılaştık. Bu durumda MusicianActor sınıfı derlenmeyecektir. Bunu çözmenin yöntemi ise ancak MusicianActor‘ün “play()” metoduna bir gerçekleştirme vermesidir.

package org.javaturk.oofp.ch04.multipleInheritance;

public class MusicianActor implements Actor, Musician{
	
	public void play(){
		System.out.println("MusicianActor plays!");
	}
}

Dolayısıyla default metotlara sahip olmanın ilk maliyeti, diamond problemine duçar olmaktır.

Default metotlarla alakalı bir başka durum ise, üst bir arayüzün default metot tanımlamasına karşın, onun alt arayüzünün aynı metodu abstract olarak tekrar tanımlamasında oluşur. Yukarıda verdiğimiz örneği biraz değiştirerek devam edebiliriz. Bu defa Actor, play() metodunu default olarak tanımlar:

package org.javaturk.oofp.ch04.multipleInheritance.v2;

public interface Artist {
	
	default void play(){
		System.out.println("Artist plays!");
	}
}

Ve tek alt arayüzleri olarak Musician ise “play()” metodunu abstract olarak tekrar tanımlarlar:

package org.javaturk.oofp.ch04.multipleInheritance.v2;

public interface Musician extends Artist{
	
	void play();
}

Tabi olarak bu durumda, hiyerarşinin en altındaki Pianist sınıfı “play” metoduna bir gerçekleştirme sağlamak zorundadır, aksi taktirde abstract bir sınıf olur. Pianist‘i abstract yapalım:

package org.javaturk.oofp.ch04.multipleInheritance.v2;

public abstract class Pianist implements Musician{	
}

Geçmiş olsun 🙂 Herkese iyi günler dileriiim, iyi hafta sonlarııııı 🙂

Üst arayüz Artist ile Musician ve Pianist arasındaki ilişkiye bir bakın. Farkedebildiniz mi?

Gariplik şurada: “interface” anahtar kelimesiyle oluşturduğumuz arayüzler, bir önceki yazıda da vurguladığım gibi sadece davranışların tanıtımının (declaration) yapıldığı yerlerdir. Davranışların tam olarak tanımlandığı (definition) yer değildir, davranışlar arayüzlerde tanıtılır, sınıflarda tanımlanır. Bu yüzden bu yapılara, sadece arayüz sağladığı için “arayüz” ya da “interface” denir. Ama yukarıdaki durumda tanımlamayı yapan arayüzdür, tanıtımı yapan ise sınıf! “play()” metodu Artist arayüzünde tam olarak tanımlanıyor ama hiyerarşinin en altındaki Pianist sınıfı ise aynı davranışı tanıtıyor, yani üst tipi olan Mucisian arayüzünden abstract olarak devralıyor ama bir gerçekleştirme vermiyor.

Ne demiş atalarımız böyle durumlarda: “Ne oldum demeyeceksin, ne olacağım diyeceksin.” ya da “büyük lokma ye büyük laf konuşma.”

Bol düşünmeli bir haftasonu dilerim 🙂

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

Java SE 8, son zamanlardaki en fazla değişiklik içeren ve bundan dolayı da heyecan getiren Java SE sürümü oldu. Çünkü Java SE 8 ile gelen değişiklikler, abartmayayım ama, bazı konulardaki düşüncemizi kökten değiştiren cinsten.

Tabi dillerde değişiklik yapmak, hele temel mekanizmalarıyla oynamak kolay değil. Örneğin switch ifadelerinde String kullanımı için senelerce beklemiştik. Benzer şey Java’ya fonksiyonel özelliklerin eklenmesinde de oldu. Java SE 8’i, Java SE 1.2 ve 5.0 gibi, diğerleri arasında öne çıkan sürümlerden olması, Java’ya, çehresini değiştirecek fonksiyonel yapılar katmasıyla ilgili. Ve muhtemelen en çarpıcı olan değişiklik ise arayüzlerin (interfaces) artık gerçekleştirmesi olan metotlara sahip olması.

Malum, arayüz, kavramsal olarak da Java’da “interface” anahtar kelimesiyle ifade edilen yapı olarak da sadece şekil sağlayan, bir davranışın “neliği”ni ifade eden, “nasıllığı”nı, onu gerçekleştiren sınıflara bırakan bir yapıdır. Bu anlamda arayüze, İngilizce’de “contract” de denir. “program to an interface, not an implementation” ya da “design by contract” gibi felsefe ve yaklaşımlar hep arayüz kavram ve mekanizmalarının ifade ettiği soyutluk üzerine bina edilmişlerdir.

Durum böyle iken Java SE 8’de, arayüzlerin bir gerçekleştirmeye yani koda sahip metotları içermesi mümkün hale geldi. Artık Java’da bir arayüz sadece soyut (abstract) metotlara değil,  default (varsayılan) ve statik metotlara da sahip olabilir.

Default metotlar metot arayüzünde “default” anahtar kelimesi ile tanımlanır ve arayüzdeki soyut metotların aksine bir gerçekleştirmeye sahip olmaları zorunludur.

public interface Printable {
	
	void view();
	
	void print();
	
	default void format(){
		System.out.println("Printable is being formatted.");
	}
}

Bu durumda Printable arayüzünden miras alan sınıfların default olan format() metoduna bir gerçekleştirme vermeleri gerekmeyecektir. Çünkü bu metodun Printable arayüzünden devir alınan hali zaten bir gerçekleştirmeye sahiptir.

public class Document implements Printable {

	@Override
	public void view() {
		System.out.println("Document is being viewed.");
	}

	@Override
	public void print() {
		System.out.println("Document is being printed.");
	}
}

Yukarıdaki kodun, yazının basında bahsettiğim arayüz kavramına alışkın bir zihinde karışıklığa neden olacağı kesin gibidir. Anlamayı kolaylaştırmak için neden böyle bir şeye ihtiyaç duyulduğunu hızlıca açıklayalım.

Eğer projenizde kullandığınız bir arayüze yeni bir metot ekleyip, onu derledikten sonra .class dosyasını projenizdeki yerine koyarsanız, tekrar derlemediğiniz müddetçe, o arayüzü kullanan, örneğin gerçekleştiren (implement eden), sınıflar çalışmaya devam ederler. Buna “binary compatibility” (ikili uyumluluk) denir. Ama o arayüzü kullanan bir sınıfı tekrar derlemeye kalkarsanız, örneğin bir hatasını düzelttikten sonra, derleme hatası alırsınız çünkü bu durumda source compatibility (kaynak uyumluluğu) yoktur.

Arayüzlerde default olarak tanımlanan ve bir gerçekleştirmeye sahip olan metotlar, arayüzlerin eski sürümlerini kullanan sınıflar ile arayüzün default metotlarla zenginleştirilmiş yeni sürümü arasında kaynak uyumluluğu sağlamak amacına hizmet etmektedir. Diğer bir deyişle, bir arayüze yeni bir metot eklediğinizde, o arayüzden miras devir alan sınıfların tekrar derlenmeleri halinde derleme hatası vermemeleri için yapmaları gereken, arayüzdeki yeni metotlara bir gerçekleştirme sağlama zorunluluğundan kurtulmanın yolu, arayüze eklenen metotları default olarak tanımlamak ve bir gerçekleştirme vermektir.

Statik metotlar ise, bildiğimiz, sınıflarda tanımlanan statik metotlarla aynı yapıdadırlar. Arayüzlerdeki statik metotların tek farkı devir alınmayıp, sadece ve sadece tanımlandığı arayüz üzerinden çağrılabilmesi kısıtıdır. Örnekle açıklayalım:

package org.javaturk.oofp.ch04.staticMethods;

public interface Printable {
	
	void view();
	
	void print();
	
	default void format(){
		System.out.println("Printable is being formatted.");
	}
	
	static void startPrinting(){
		System.out.println("Printing has been started.");
	}
}

package org.javaturk.oofp.ch04.staticMethods;

public class Document implements Printable {

	@Override
	public void view() {
		System.out.println("Document is being viewed.");
	}

	@Override
	public void print() {
		System.out.println("Document is being printed.");
	}
}

Bu durumda test sınıfımız şöyle olacaktır:

package org.javaturk.oofp.ch04.staticMethods;

public class TestDefaultMethods {

	public static void main(String[] args) {
		Printable printable = new Document();
		printable.print();
		printable.format();
		
		Printable.startPrinting();
		
//		Document.startPrinting();  // Can't do this!
	}
}

Yukarıdaki örnekte “Document.startPrinting();” satırının problemli olduğuna dikkatinizi çekmek isterim.

Arayüzlerde tanımlanan tüm metotlar, soyut, default ya da statik olsun, her zaman public erişim belirtecine varsayılan halde sahiptirler.

Bir sonraki yazıda kafanızı hepten karıştırmak üzere 🙂

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