Builder, GoF’un nesne yaratma kalıplarından bir diğeridir. Özellikle karmaşık olan nesnelerin oluşturulması için kullanılır. Dilimize “oluşturucu” (ya da daha yakın bir çeviriyle “binacı” ya da “bina eden”) olarak çevrilebilecek olan bu kalıbın amacıyla ilgili GoF’da şu bilgiler bulunmaktadır:

Intent: Separate the construction of a complex object from its representation so that the same construction process can create different representations.

Amaç: Karmaşık bir nesnenin oluşturulmasını, sunumundan ayırın öyle ki aynı oluşturma süreci farklı sunumlar yaratabilsin.

Bazen bir nesneyi yaratmak, basit bir yapılandırıcı çağrısından ziyade bir süreç içinde olur. Böyle durumlarda hem nesne karmaşıktır hem de nesneyi yaratma süreci karmaşıktır. Bu türden nesneleri oluşturmak için gerekli süreç Builder kalıbı olarak modellenebilir. 

Bir nesnenin karmaşık olduğunun en temel göstergesi, çok parametre alan kurucularıdır (constructor): Telescoping constructor anti-pattern. Kurucuya geçilen parametrelerin de oluşturulması gerektiği düşünüldüğünde bu sürecin soyutlanması gerektiği açık hale gelir. Factory Method ve Abstract Factory bu problemi çözmez.  Çünkü J. Bloch’un da Effective Java kitabında söylediği gibi bu iki kalıp ta kurucular gibi büyüme (scale) probemi olan yapılardır.

Aşağıdaki sınıf diyagramını ele alalım örneğin. Bu örnekteki Computer sınıfı, böyle bir örnek için uygun karmaşıklıkta bir sınıftır. Diyagramdan da görüldüğü gibi bu sınıfın 4 tane kurucusu vardır. Bu tipten karmaşık kuruculara sahip olan sınıfların nesnelerini oluşturmanın bir yolu argüman alan kuruculardan hangisini kullanacağınıza karar verip, sırayla, geçilecek argümanları oluşturup sonrasında ise kurucunun istediği sırayla oluşturulan argümanları geçmektir.

Computer nesnesini bu şekilde oluşturan client kod örneği şöyle olabilir:

package org.javaturk.dp.pattern.gof.creational.builder.problem;

import org.javaturk.dp.pattern.gof.creational.builder.CPU;
import org.javaturk.dp.pattern.gof.creational.builder.Display;
import org.javaturk.dp.pattern.gof.creational.builder.GraphicCard;
import org.javaturk.dp.pattern.gof.creational.builder.HardDrive;
import org.javaturk.dp.pattern.gof.creational.builder.Keyboard;
import org.javaturk.dp.pattern.gof.creational.builder.Mouse;
import org.javaturk.dp.pattern.gof.creational.builder.RAM;

public class Test {

	public static void main(String[] args) {
		Test test = new Test();
		
		CPU cpu1 = test.produceCPU();
		RAM ram1 = test.produceRAM();
		HardDrive hd1 = test.produceHardDrive();
		GraphicCard graphicCard1 = test.produceGraphicCard();
		Computer computerWithoutDisplayKeyboardAndMouse = new Computer("computerWithoutDisplayKeyboardAndMouse", cpu1, ram1, hd1, graphicCard1);
		computerWithoutDisplayKeyboardAndMouse.start();
		
		
		CPU cpu2 = test.produceCPU();
		RAM ram2 = test.produceRAM();
		HardDrive hd2 = test.produceHardDrive();
		GraphicCard graphicCard2 = test.produceGraphicCard();
		Display display2 = test.produceDisplay();
		Keyboard keyboard2 = test.produceKeyboard();
		Mouse mouse2 = test.produceMouse();
		Computer computerFull1 = new Computer("computer full", cpu2, ram2, hd2, graphicCard2, display2, keyboard2, mouse2);
		computerFull1.start();
	}

	public CPU produceCPU(){
		return new CPU();
	}
	
	private RAM produceRAM() {
		return new RAM();
	}
	
	public HardDrive produceHardDrive(){
		return new HardDrive();
	}
	
	public GraphicCard produceGraphicCard(){
		return new GraphicCard();
	}
	
	private Display produceDisplay() {
		return new Display();
	}

	private Keyboard produceKeyboard() {
		return new Keyboard();
	}

	private Mouse produceMouse() {
		return new Mouse();
	}
}

Görüldüğü gibi yukarıdaki koddaki Computer nesnelerinin oluşturulması, pek çok parametre alan ve birbirine benzeyen, dolayısıyla ayırt edilmeleri pek de kolay olmayan kurucu çağrılarıyla yapılmaktadır. Bu tip kurucu çağrılarının hataya elverişli olması bu yaklaşımın bir diğer zorlu tarafını oluşturur.

Yukarıdaki yaklaşıma alternatif olarak J. Bloch, kitabında “JavaBean” yaklaşımından bahsetmektedir. JavaBean nesneleri bildiğimiz gibi, argüman almayan kurucu çağrısı ile bol miktarda “set” metodu çağrısıyla oluşturulur. Yani client kodu şöyledir:

...
		Computer computerFull2 = new Computer();
		computerFull2.setName("computer full2");
		CPU cpu3 = test.produceCPU();
		computerFull2.setCpu(cpu3);
		RAM ram3 = test.produceRAM();
		computerFull2.setRam(ram3);
		HardDrive hd3 = test.produceHardDrive();
		computerFull2.setHd(hd3);
		GraphicCard graphicCard3 = test.produceGraphicCard();
		computerFull2.setGraphicCard(graphicCard3);
		Display display3 = test.produceDisplay();
		computerFull2.setDisplay(display3);
		Keyboard keyboard3 = test.produceKeyboard();
		computerFull2.setKeyboard(keyboard3);
		Mouse mouse3 = test.produceMouse();
		computerFull2.setMouse(mouse3);
		computerFull2.start();
...

Yukarıdaki kod parçası, teleskopik kurucu problemini daha zor bir problemle değiştirmektedir: Çok sayıda set metodunun çağrılmasının zorluğu yanında, bu sırada yapılabilecek olan eksik çağrıların Computer nesnesinde sebep olacağı durum problemlerini çözmek ciddi zaman alacaktır. Bu türden nesne oluşturan kodların copy-paste yoluyla pek çok yere dağılacağı da düşünülürse, nasıl bir problemle karşı karşıya kalındığı ortaya çıkar. JavaBean yaklaşımı ayrıca nesnenin durumunu devamlı değiştirilebilir kılmaktadır.

Görüldüğü gibi karmaşık nesnelerin tekrar kullanılabilir şekilde oluşturulmasını sağlayacak bir yaklaşım, yukarıdaki problemleri ortadan kaldıracaktır. Böyle bir yaklaşım Builder kalıbıyla mümkün olabilir. Builder kalıbıyla böyle bir problemin nasıl çözülebileceğini bir sonraki yazıda ele alalım.

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

GoF’un yapısal kalıplarından bir diğeri de Façade’dır. Bu kelime pek çok yerde “c” ile “Facade” olarak yazılmasına rağmen aslen Fransızca’da “ç” ile “Façade” olarak yazılır ve binaların ön yüzü, ön cephesi anlamına gelir. Zaten kelime yapısı itibarıyla “face” yani “yüz” ile de akrabadır.

Bu kısa açıklamdan sonra GoF’un bu kalıp ile ilgili dediklerine bir bakalım:

Intent: Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher level interface that makes the subsystem easier to use.

Amaç: Bir alt sistemdeki arayüzlere, bir birleşik arayüz sağla. Façade, alt sistemi daha kolay kullanmak için daha yüksek seviyeli bir arayüz sağlar.

Evet bu amaç açıklamasından da anlaşıldığı gibi Façade, karmaşık iş süreçlerini saklamakta kullanılan bir kalıptır. Çoğunlukla kullandığımız algoritmalar veya iş mantığı, bir süreç oluşturacak şekilde, pek çok farklı nesneden hizmet alarak ilerler. Süreç, hangi nesneden hangi durumlarda hizmet alınacağı bilgisini detayıyla ifade eder. Süreç, aynı zamanda pek çok iş kuralı ile de yönlendirilir. Böyle durumlarda client nesnelerin, süreci tüm detayıyla bilmelerini istemeyiz. Bu sıkıntılı durumu aşağıdaki örnekte rahatlıkla görebiliriz:

Yukarıdaki yapıda görüldüğü gibi Client, bir bilgisayarı çalıştırmak için onun parçalarına tek tek ulaşıp, bir süreç halinde hepsini başlatması gereklidir. Bu çalışma şekli aşağıdaki akış diyagramında verilmiştir:

Böyle bir çalışma şeklinin Client nesnesini ne kadar karmaşık yaptığı ortadadır. Client nesnesinin koduna bakarsak:

package org.javaturk.dp.pattern.gof.structural.facade.computer.problem;

import org.javaturk.dp.pattern.gof.structural.facade.computer.CPU;
import org.javaturk.dp.pattern.gof.structural.facade.computer.Display;
import org.javaturk.dp.pattern.gof.structural.facade.computer.HardDrive;
import org.javaturk.dp.pattern.gof.structural.facade.computer.RAM;

public class Client {
	
	private CPU cpu;
	private RAM ram;
	private HardDrive hd;
	private Display display;

	public Client() {
		cpu = new CPU();
		ram = new RAM();
		hd = new HardDrive();
		display = new Display();
	}
	
	public void start() {
		cpu.start();
		hd.start();
		boolean kernelLoaded = ram.loadOSKernelImage();
		while(!kernelLoaded){
			ram.fixIt();
			kernelLoaded = ram.loadOSKernelImage();
		}
		
		boolean osLoaded = ram.loadOS();
		while(!osLoaded){
			ram.fixIt();
			osLoaded = ram.loadOS();
		}
		
		ram.loadDrivers();
		ram.startServices();
		display.start();
		System.out.println("Computer has started.");
	}

	public static void main(String[] args) {
		new Client().start();

	}
}

Client nesnesinin start() metodunun yukarıdaki basit örnekte bile bilgisayarın parçaları olan nesnelerle pek çok mesajlaşma içermesi ve bu nesnenin bir bilgisayarın ayağa kalkmasıyla ilgili süreci detayıyla bilmesi, gerçek bir projede iş süreçlerinden haberdar olan nesnelerin ne kadar karmaşık olabileceğini göstermeye yeter sanırım. Öte taraftan, CPU ya da RAM gibi nesnelerde ya da bilgisayarı ayağa kaldırma sürecinde yapılacak bir  değişikliğin Client’da değişikliğe sebep olacağı da aşikardır. Bu sıkıntılardan kurtulmanın yolu, diğer mühendisliklerde başarıyla yaptığımız gibi burada da arka taraftaki karmaşık sistemi saklayıp, önüne koyulacak basit bir arayüz ile yönetimini sağlamaktır. Bu basit arayüz, Façade’dır.

Arka tarafta bulunup, süreci yerine getiren nesnelerle ön taraftaki client arasına konan Façade, algoritma ya da iş mantığındaki süreci tüm detaylarını bilir. Bu şekilde bir ara nesne olarak Facade, clientı, süreci yerine getiren nesnelerden yalıtmakta kullanılır. Façade, sürecin tüm detaylarını bilir ama bu detayların hepsini arayüzünde dışarıya sunmaz, muhtemelen arayüzünde bir seferde çok iş yapacak şekilde, coarse grained metotlar sağlar Client ise bu şekilde Façade nesnesinden hizmet alır. Client bu hizmeti alırken, sürecin detaylarından etkilenmez, sürecin işlemesi için gerekli bilgileri Façade’a sağlayarak, Façade’ın süreci çalıştırıp kendisine dönmesini bekler.

Façade gibi bir yalıtım nesnesinin kullanımı zaman zaman seçilen mimari ve teknolojilerden dolayı da faydalı hatta zorunlu olabilir. Örneğin uzak nesnelere (distributed objects) erişerek hizmet alma durumunda, bu nesnelere pek çok ufak-tefek iş yapan çağrı yapmaktansa, uzak nesnelerin önüne konulacak bir uzak Façade nesnesi ile, yapılacak uzak metot çağrılarının sayısı bir hayli azaltılabilir. Bu durumda ağ trafiği kullanımı da daha etkin hale gelir.

Bakın Façade nesnesinin kullanımıyla çözümümüz ne hale gelir:

Bu durumda Client nesnesinin, Computer façade nesnesiyle haberleşmesi ise şöyle olur:

Client nesnesinin koduna bakarsak, artık son derece sade olduğunu farkederiz:

package org.javaturk.dp.pattern.gof.structural.facade.computer;

public class Client {

	public static void main(String[] args) {
		Computer computer = new Computer();
		computer.start();
	}
}

Çünkü tüm karmaşıklık ve bağımlılık Computer nesnesine kaymıştır:

package org.javaturk.dp.pattern.gof.structural.facade.computer;

public class Computer {
	private CPU cpu;
	private RAM ram;
	private HardDrive hd;
	private Display display;

	public Computer() {
		cpu = new CPU();
		ram = new RAM();
		hd = new HardDrive();
		display = new Display();
	}
	
	public void start() {
		cpu.start();
		hd.start();
		boolean kernelLoaded = ram.loadOSKernelImage();
		while(!kernelLoaded){
			ram.fixIt();
			kernelLoaded = ram.loadOSKernelImage();
		}
		
		boolean osLoaded = ram.loadOS();
		while(!osLoaded){
			ram.fixIt();
			osLoaded = ram.loadOS();
		}
		
		ram.loadDrivers();
		ram.startServices();
		display.start();
		System.out.println("Computer has started.");
	}
}

Façade ile ilgili tartışmamıza burada ara verelim. Bir sonraki yazıda biraz daha kurumsal yapılardaki kullanımından bahsedeceğiz.

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