Search Results for: tasarım kalıpları

Tasarım Kalıpları – II: Neden Öğrenelim?

Java, Tasarım Kalıpları, Yazılım Mühendisliği ,

Bu yazıda tasarım kalıplarını neden öğrenmemiz gerektiğini ele alalım.

“Tasarım Kalıpları” tamlaması, kullanıldığında bir “üst perde” havası oluşturan bir kavrama karşılık geliyor. Sanki bu tamlamayı kullanan kişi birden “erenler”den oluveriyor. Kullanıldığında konuya ve özellikle de kullanana “ileri derecede karmaşıklık” ya da “sofistikasyon” atfediyor. Halbuki durum öyle değil, ama belli ki bu algı bizim cehaletimizden kaynaklanıyor.

Bir de bu konuda öğrenilmiş çaresizlik yaşıyor gibiyiz. Ben üç-beş defa bu konuyu öğrenmeye niyetlenmiş ve girişmiş ama her seferinde belli bir yerde bırakmak zorunda kalmış insanlarla tanıştım. Ülkemizdeki “İngilizce”nin durumu gibi 🙁 Sanki bilmek zorundaymışız, ciddi bir miktar zaman harcamışlığımız da var ama malesef henüz tam olarak bilmiyoruz gibi bir durumdayız. Her eğitimde ya da danışmanlıkta müşteri tarafında olan yazılımcı arkadaşlar bazen bir miktar uğraştıklarını göstermek, bazen kötü durumda olan kodlarının bu durumunu açıklamak ya da doğrudan benimle sohbet etmek vs. gibi sebep ve niyetlerle tasarım kalıpları tamlamasını ya da bazı tasarım kalıplarını telaffuz ederler.

Tasarım kalıpları etrafındaki oluşan bu buğulu havayı dağıtmak, başarılı bir öğrenim süreci için elzem görünüyor.

Tasarım kalıplarını kullanmadan program yazmaya başladığınızda ilk yapacağınız hata, program olarak ifade etmeye çalıştığınız iş süreci ya da problemindeki sorumlulukları roller olarak ayırt edememenizdir. Yani “bu problemin çözümünde hangi sorumluluklar var?” ve “bu sorumluluklar farklı nesnelere nasıl dağıtılmalı?” sorularının sorulması ve cevaplanması aslen bir tasarım faaliyetidir. Hatta tasarım daha doğrusu fonksiyonel tasarım faaliyeti temelde bu soruları açıklığa kavuşturmak, alternatif cevaplar verip bunları kıyaslayarak sonuca ulaşmadan ibarettir bile denebilir. Tasarım yapma niyetiniz yoksa ki bunu biz “zamanımız yok” diye ifade ederiz, zaten bu yazının geri kalanı anlamsız olur 🙂 Yok, doğru düzgün bir yapı ortaya çıkarmak için tasarıma niyetimiz varsa tasarıma vakit ayırırız ki yukarıdaki soruları sorarız ve tasarım kalıplarının yardımıyla vereceğimiz cevaplarla nesne modellerini oluştururuz.

Tasarım yapılmazsa dolayısıyla da tasarım kalıpları kullanılmazsa, istenildiği kadar en yeni teknolojiler kullanılsın ya da nesne-merkezli bir dille program yazılsın, sağlıklı bir nesne yapısı kurgulama ihtimali sıfıra yakındır. Çünkü, yukarıda bahsettiğim, sorumlulukları bulma ve nesnelere dağıtma işinin sağlıklı yapılmaması söz konusudur. Bu durumda da gidilecek yön, nesne-merkezli programlama değil, olsa olsa prosedürel programlama hatta daha da kötüsü, karman-çorman kod yığınıdır.

Örneğin, normalde tasarım yaparak ve tasarım şablonlarını kullanarak nesnelere ve üzerinde muhtemelen override edilmiş metotlara bölünecek bir davranışın, tek bir metot altında pek çok “if” kullanarak kodlandığı sıklıkla görülür. Bu durum ise olsa olsa “functional decomposition”dır ve başınızı gittikçe belaya sokan bir yaklaşımdır. Dolayısıyla tasarım kalıpları çoğu defa bize, normalde nesne-merkezli programlama dili kullanmamıza rağmen prosedürel anlayışla yazılım geliştirmeye düşmekten kaçınmamızı sağlar. Tam da bu yüzden pek çok refactoring yani kod iyileştirmesi tekniği, var olan karmaşık ve devasa hale gelmiş nesne ve metotları, farklı kalıpları kullanarak, ufak-tefek nesne ve metotlara dönüştürür. Tasarım kalıplarının bunu yaparken elinde tuttuğu temel teknik, yukarıda bahsettiğim iki sorudur: “bu problemin çözümünde hangi sorumluluklar var?” ve “bu sorumluluklar farklı nesnelere nasıl dağıtılmalı?” Zaten bu sorular sorulmadığından devasa sınıflara ve metotlara ulaşılmıştır.

Ben danışmanlıklarımda, özellikle kod kalitesini arttırıcı işlerimde bu durumlarla çok sık karşılaşıyorum. Tek yapacağım şey konuyu anladıktan sonra bu iki soruyu sormak. Tasarım kalıpları, bu iki sorunun cevabını ciddi oranda veriyorlar. Çünkü tasarım kalıpları hem bir yöntemdir hem de bir sorumluluk kataloğudur. Tasarım kalıpları yöntemdir çünkü bu iki soruyu sormanızı ve nasıl cevap vereceğinizi size öğretir. Tasarım kalıpları aynı zamanda bir sorumluluk kataloğudur, çünkü en basitinden en karmaşığına kadar, farklı sektördeki yazılımlarda bulunan en yaygın sorumlulukları ortaya koyar. Dahası tasarım kalıpları, bu sorumlulukları nasıl bulacağınızı ve bunları iç tutarlılığı yüksek (highly-cohesive) ve dış bağımlılığı düşük (lowly-coupled) nesne modellerine nasıl çevireceğimizi de bize gösterir.

Eğer tasarım faaliyeti, yazılım geliştirme sürecinizin bir parçası ise zaten yolunuz bir şekilde kalıplarla kesişiyor demektir. Yani sadece Gof’un 23 kalıbını kullanmakla kalmıyor, kendi iş alanınızda sıklıkla karşılaştığınız sorumluluk problemlerine özel kalıplar da geliştiriyorsunuz demektir.

Dolayısıyla tasarım kalıplarını şu amaçlarla öğrenmeliyiz:

  • Tekerleği yeniden keşfetmemek, var olan ispatlanmış çözümleri kullanmak: Tasarım kalıpları sıklıkla karşılaştığımız, yaygın sorumluluk bulma ve dağıtma problemlerini çözerek, tekrar kullanılabilen, faydası ispatlanmış modeller ortaya koyar.
  • Formal ve yaygın bir dil oluşturmak: Tasarım kalıpları, formal bir kalıp dili (pattern language) oluşturmaktadır. Bu kalıp dilinin en temel kavramı sorumluluktur. Dolayısıyla tasarım kalıpları zihnimize, “şu şey yapar, şunu alır şuna verir” gibisinden sokak ağzı bir konuşma yerine “kontrol nesnesi (controller), request ve response nesnelerini, ilgili üreticilerden (factory) alıp sunum (view) nesnesine geçer” şeklinde konuşmayı öğretir. Bu dilin yazılım geliştiriciler arasında yayılması, anlaşmayı kolaylaştıracak, ifade gücümüzü arttıracaktır.
  • Tasarıma uygun, yüksek soyutlama gücü kazandımak, detaylardan sıyrılıp, daha yüksek hedefler cinsinden düşünmek: Bu anlamda tasarım kalıpları daha iyi bir yazılım geliştirici hatta mühendisi olmanın en temel gerekliliklerindendir.

Zaman zaman karşılaşıyorum, “biz aslında bir miktar tasarım yapmıştık” şeklinde cümlelerle. Bırakın kalıbı sistemde hiç arayüz yok, hiç bir nesne hiyerarşisi yok, devasa sınıflar ve metotlar var, nesneler arası ilişkiler karmakarışık, kim neyi biliyor belli değil, peki tasarım nerede? Yukarıda anlattığım gibi tasarım yapılacaksa o iki sorudur üzerinde düşünülmesi ve çözülmesi gereken şey. Ve yolunuz bir şekilde tasarım kalıplarıyla kesişir.

Tasarım kalıplarını bilmiyorsanız, tasarım da yapamazsınız.

Bol tasarımlı günler dilerim 🙂

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

Tasarım Kalıpları: – Builder (Oluşturucu) Kalıbı – I

Java, Tasarım Kalıpları, Yazılım Modelleme

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.

ClassDiagram1

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ı: 2617

Tasarım Kalıpları: Façade (Ön Yüz) Kalıbı – I

Java, Tasarım Kalıpları, Yazılım Modelleme

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:

ClassDiagram1

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:

SequenceDiagram1

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:

ClassDiagram1

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

SequenceDiagram1

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ı: 2554

Tasarım Kalıpları: Prototype (Prototip ya da Örnek Nesne)

Kategorisiz

GoF’un nesne yaratmayla ilgili 5 kalıbından bir diğeri de Prototype’dır. Dilimize “prototip” ya da “örnek nesne” olarak çevrilebilecek olan bu kalıbın amacıyla ilgili GoF’da şu bilgiler bulunmaktadır:

Intent: Specify the kinds of objects to create using a prototypical instance, and create new objects by copying prototype.

Amaç: Prototip bir nesneyi kullanarak yaratılacak nesneleri belirlemek ve yeni nesneleri prototipi kopyalayarak oluşturmak.

Anlaşılması son derece kolay ve tabi olan bu kalıbı özellikle karmaşık ve durumları arasında az farklar olan nesneleri yaratmada başarıyla kullanabiliriz.

Uygulamalarda sıklıkla iş sınıflarından nesneler oluştururuz. Bu nesneler zaman zaman ciddi karmaşıklıkta olurlar. Aynı tipten olan nesneleri sıklıkla farklı durumlarla yaratmak isteriz: UnAuthenticatedUser ve AuthenticatedUser gibi.

Bazen karmaşık bir nesneyi yaratıp, o nesneyi kopyalayarak yeni nesneler yaratabiliriz. Kopyalanan nesne prototip nesnedir. Bazen de karmaşık bir nesneyi, farklı durumlarla yaratmak isteriz. Yani nesnenin ilk yaratıldığında alacağı farklı durumlar ise birbirlerinden türetilebilir.

Çözüm olarak diğer nesnelerin yaratılabilmesi için oluşturulan örnek nesne ya da prototipten başlayabiliriz. Yani prototip olarak oluşturulan bir nesne, aynı türden diğer nesnelerin yaratılması için bir başlangıç noktasıdır. Dolayısıyla, yeni nesneler oluşturmak, için var olan prototipi kopyalarız (cloning). Muhtemelen prototype ile diğer nesneler arasında durum farklılıkları vardır. İstenirse bu farklı durumlar tek bir prototipten üretilen nesne üzerinde, gerekli setter metotları çağrılarak oluşturulur. İstenirse de farklı durumlar için farklı prototipler üretilir.

Örneğin aşağıdaki gibi örnek amacıyla yapılmış olduğundan basit yapıyı ele alalım.

ClassDiagram1

Örnek kodlar da aşağıdaki gibi olacaktır.

package org.javaturk.dp.pattern.gof.creational.prototype.simple;

public abstract class Customer implements Cloneable {
	protected int id;
	protected String address;
	protected String phone;
	boolean authenticated;

	public Customer(int id, String address, String phone) {
		this.id = id;
		this.address = address;
		this.phone = phone;
		authenticated = false;
	}

	public int getId() {
		return id;
	}

	public void setId(int id) {
		this.id = id;
	}

	public String getAddress() {
		return address;
	}

	public void setAddress(String address) {
		this.address = address;
	}

	public String getPhone() {
		return phone;
	}

	public void setPhone(String phone) {
		this.phone = phone;
	}

	public boolean isAuthenticated() {
		return authenticated;
	}

	public void setAuthenticated(boolean authenticated) {
		this.authenticated = authenticated;
	}
	
	@Override
	public String toString() {
		return "Customer [id=" + id + ", address=" + address + ", phone="
				+ phone + ", authenticated=" + authenticated + "]";
	}

	@Override
	public Customer clone() {
		Customer customer = null;
		try {
			customer = (Customer) super.clone();
		} catch (CloneNotSupportedException e) {
			System.out.println("Problem when cloning the object: " + e.getMessage());
			e.printStackTrace();
		}
		return customer;
	}
}

Görüldüğü gibi nesnenin “clone()” metodu override edilmiştir.

Benzer şekilde yapıdaki diğer iki nesne de şöyledir:

package org.javaturk.dp.pattern.gof.creational.prototype.simple;

import java.util.Date;

public class IndividualCustomer extends Customer{
	private String firstName;
	private String lastName;
	private Date dob;
	
	public IndividualCustomer(int id, String address, String phone,
			String firstName, String lastName, Date dob) {
		super(id, address, phone);
		this.firstName = firstName;
		this.lastName = lastName;
		this.dob = dob;
	}

	public String getFirstName() {
		return firstName;
	}

	public void setFirstName(String firstName) {
		this.firstName = firstName;
	}

	public String getLastName() {
		return lastName;
	}

	public void setLastName(String lastName) {
		this.lastName = lastName;
	}

	public Date getDob() {
		return dob;
	}

	public void setDob(Date dob) {
		this.dob = dob;
	}

	@Override
	public String toString() {
		return "IndividualCustomer [firstName=" + firstName + ", lastName="
				+ lastName + ", dob=" + dob + ", id=" + id + ", address="
				+ address + ", phone=" + phone + ", authenticated="
				+ authenticated + "]";
	}
}
package org.javaturk.dp.pattern.gof.creational.prototype.simple;


public class CorporateCustomer extends Customer {

	private String corporateName;
	private double discount;

	public CorporateCustomer(int id, String address, String phone,
			String corporateName, double discount) {
		super(id, address, phone);
		this.corporateName = corporateName;
		this.discount = discount;
	}

	public String getCorporateName() {
		return corporateName;
	}

	public void setCorporateName(String corporateName) {
		this.corporateName = corporateName;
	}

	public double getDiscount() {
		return discount;
	}

	public void setDiscount(double discount) {
		this.discount = discount;
	}

	@Override
	public String toString() {
		return "CorporateCustomer [corporateName=" + corporateName
				+ ", discount=" + discount + ", id=" + id + ", address="
				+ address + ", phone=" + phone + ", authenticated="
				+ authenticated + "]";
	}
}


Bu durumda client kodumuz da basitçe şöyle olacaktır:


package org.javaturk.dp.pattern.gof.creational.prototype.simple;

import java.util.Date;

public class Test {

	public static void main(String[] args) {
		IndividualCustomer unAuthenticatedCoskunCustomerPrototype = new IndividualCustomer(1,
				"Cumhuriyet Cad. No 28 Beşiktaş Istanbul", "2128399041",
				"Selim", "Coskun", new Date());
		System.out.println(unAuthenticatedCoskunCustomerPrototype);
		
		
		IndividualCustomer authenticatedAhmetCoskun = (IndividualCustomer) unAuthenticatedCoskunCustomerPrototype.clone();
		authenticatedAhmetCoskun.setId(2);
		authenticatedAhmetCoskun.setFirstName("Ahmet");
		authenticatedAhmetCoskun.setAuthenticated(true);
		System.out.println(authenticatedAhmetCoskun);
		
		
		CorporateCustomer unAuthenticatedGECustomerPrototype = new CorporateCustomer(100, "Manolya Cad. No 5 Sariyer Istanbul", "2124199047", "GE", 0.25);
		System.out.println(unAuthenticatedGECustomerPrototype);

	}
}
Bu basit uygulamadan da görüldüğü gibi, karmaşık nesneler, bir örnek nesneden clonelanarak oluşturulup,  gerekirse olması gereken duruma getirilebilir.

Okuyuculara ödev olarak aşağıdaki durumu verebiliriz:


	public JTUser execute(RegistrationForm form, 
          HttpServletRequest request, Locale locale) throws JTException {

		String uid = utils.generateUUID();
		String salt = utils.generateSalt(32);
		String accountId = utils.generateUUID();

		JTUser user = new JTUser(
				form.getEmail().trim(), null, true, true, true, true,
				AuthorityUtils.NO_AUTHORITIES, // spring security fields
				uid, formorm.getEmail().trim(), salt, form.getName().trim(),
				form.getSurname().trim(), null, accountId, true,
				true, form.getWelcomeMessage().trim(), true,
				new Date(), null);

		user.setStatus(JTConstants.PENDING);

		String servletPath = request.getServletPath();
		if (executeInner(form, locale, user)) {
		     auditLogDao.insert(new AuditLog(user.getUid(), user.getUsername(),
					utils.getRemoteIp(), utils.getSid(),
					AuditType.REGISTRATION, AuditSubtype.PENDING,
					ResponseCode.SUCCESS, new Date(), null));

		     authenticateFastRegisterUser(form, request);
		}

		return user;


Yukarıdaki kodu prototype kalıbıyla nasıl iyileştirebiliriz? Kodda JTUser oluşturulurken pek çok boolean parametre geçildiği görülüyor. Muhtemelen sistemde farklı JTUser nesneleri farklı boolean değerlerle oluşturuluyor. Bu durumda prototype kalıbı kullanışlı görünüyor.


Benzer durum AuditLog nesnesi için de geçerli midir?


Prototype kalıbının artısı, Factory ya da Abstract Factory kalıplarında var olan miras mekanizmasını kullanmamasıdır. Çünkü yeni nesneler sadece var olan prototipten üretilirler, ama factorylerde her nesne için ayrı bir üretici sınıf vardır. Bu yüzden derin factory hiyerarşisinden kaçmak için Prototype kalıbını kullanabilirsiniz.


Factory Method ve Abstract Factory nesne oluştururken Prototype kalıbını kullanabilir. Prototype, Composite ve Decorator kalıplarında sıklıkla kullanılır.


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



					
				

						
					

					
				


	


		
		


		
	

	
	



							
											
			

			

			
 1  2  3  4  5 >»