tasarım şablonu

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

Tasarım Kalıpları: Singleton (Tek Nesne) – III – Enum Kullanımı

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

Daha önceki singleton yazılarında, bu kalıbın, alışıla gelmiş haliyle (yani private yapılandırıcı hali) nasıl kurgulandığını ve üzerinde yaptığımız bazı değişikliklerin sonuçlarından bahsetmiştik. Açıkçası bu yazılarda ele alınan yöntem singleton kalıbını oluşturmanın tek yolu da değildir. “enum” yapısını kullanarak da tek bir nesneye sahip bir sınıf oluşturabiliriz.

Malum, “enum” Java’ya SE 5 ile birlikte katılmış anahtar kelimelerdendir. enum, İngilizce’deki “enumeration” yani sıralama kelimesinin kısaltılmış halidir. enum anahtar kelimesiyle, aynı “class” ve “interface” kelimelerinde olduğu gibi yeni bir tip oluştururuz. enum tipinin sahip olabileceği tüm nesneler, enum sınıfı içinde tanımlanırlar. Bu yeni tip aslında özel bir sınıftır ve yapısından dolayı bize getirdiği bazı kısıtları vardır:

  • enum, abstract ya da final olamaz.
  • Her enum, java.lang.Enum‘ın bir alt sınıfıdır.
  • Bir enum tipinin, kendi içinde tanımlanan ve sabite olan, enum nesneleri dışında hiç bir nesnesi yaratılamaz. Bu nesneler de bir enum tipinin metninde ilk sırada gelen üye değişkenler olmalıdır. Yani bir enum sınıfının farklı üye değişkenleri varsa, enum tipinde olan en önce olmalıdır.
  • Tüm enum tipindeki değişkenler otomatik olarak public, static ve final olarak tanımlanırlar.
  • Bir enum tipinin tüm yapılandırıcıları (constructor) private olmak zorundadır, yani bir enum tipinde public ve protected yapılandırıcı tanımlanamaz. Bir enum tipinde varsayılan erişimde bir yapılandırıcı tanımlansa bile bu yapılandırıcı private olur. Hiç yapılandırıcı tanımlanmazsa derleyici bir tane varsayılan private yapılandırıcı tanımlar.
  • Bir enum tipinin yapılandırıcıları çağrılamaz.
  • Bir enum tipinin abstract metodu olamaz. Eğer bir enum tipinin abstract bir metodu olursa, tüm enum değişkenleri bu metodu sınıf içinde ezmek zorundadırlar.
  • enum sabiteleri için parametre geçilebilir, bu durumda bu parametreleri alan yapılandırıcıların olması gereklidir.
  • Bir enum tipinin yapılandırıcıları, o tipteki final olmayan statik üye değişkenlerine ulaşamazlar.
  • java.lang.Enum‘ın “equals()“, “hashCode()” ve “clone()” metotları finaldır.
  • Bir enum tipi, kendi tipindne değişkenler dışında farklı tipte üye değişkenlere sahip olabilir, bu farklı tipteki üye değişkenleri parametre olarak alacak yapılandırıcılara sahip olabilir.

Yukarıda “enum tipinin sahip olabileceği tüm nesneler, enum sınıfı içinde tanımlanırlar” demiştik. Dolayısıyla sadece bir tek nesnesi olan bir enum tip tanımlarsak bu bir singleton olur. Aşağıdaki koda bakalım:

package org.javaturk.dp.pattern.gof.creational.singleton;

public enum EnumSingleton {
		
	SINGLETON;
	
	// In fact no need for this method because SINGLETON is already public.
	public static EnumSingleton getInstance(){
		return SINGLETON;
	}
}

 

Bu durumda istemci kodumuz şöyle olacaktır:

package org.javaturk.dp.pattern.gof.creational.singleton;

public class EnumSingletonClient {

	public static void main(String[] args) {
		EnumSingleton instance1 = EnumSingleton.SINGLETON;
		EnumSingleton instance2 = EnumSingleton.getInstance();
		
		if(instance1 == instance2)
			System.out.println("The same!");
		else
			System.out.println("Different!");
		
	}
}

 

EnumSingletonClient sınıfındaki main metot çalıştırıldığında ise konsola “The same” yazılacaktır.

Yukarıdaki enum sınıfında, daha önceki yaygın singleton sınıflarında olduğu gibi “private static int count;” tanımlayıp yapılandırıcıda da “count++; name = “Singleton” + count;” cümleleri ile değerini arttırıp, nesnenin name özelliğini belirleme  yoluna gitmedik, daha doğrusu gidemedik çünkü yukarıda da yazdığımız gibi enum tipinin yapılandırıcıları, o tipteki final olmayan statik üye değişkenlerine ulaşamazlar.

Açıkçası, sonradan çıkmış olmasına rağmen enum tipini kullanan bu yaklaşımın önce ele aldığımız yaygın yaklaşıma bazı üstünlükleri vardır. Çünkü yaygın yaklaşımda, singleton olan nesneden daha fazla nesne yaratmak bazı özel durumlarda söz konusudur. Örneğin reflection kullanarak yapılandırıcısı private olsa bile yeni nesneler oluşturabilirsiniz. Ya da “clone()” metodunu kullanarak var olan nesnenin kopyalanması söz konusudur. Ayrıca singleton olan nesneyi serialized yapıp, sonra deserialized yaparsanız, elinizde bir başka nesne daha oluşacaktır. Bu üç durum genel olarak yaygın olan yaklaşımın en problemli olan üç noktasıdır. Ayrıca yaygın yaklaşımda sonradan yüklemeli durumu tercih ettiğinizde, “synchronized” ve “volatile” anahtar kelimelerini kullanmazsanız başınızın derde gireceğini daha önce burada göstermiştik. Dolayısıyla enum kullanan singleton, eğer yukarıdaki kısıtlar sizi zorlamıyorsa, yaygın yapıya göre çok daha güvenli ve kullanışlıdır. Nitekim Jashua Block “Effective Java” isimli güzel kitabının ikinci baskısındaki singleton tartışımasın şöyle bitiriyor:

“This approach is functionally equivalent to the public field approach, except that it is more concise, provides the serialization machinery for free, and provides an ironclad guarantee against multiple instantiation, even in the face of sophisticated serialization or reflection attacks. While this approach has yet to be widely adopted, a single-element enum type is the best way to implement a singleton.”

 

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

Tasarım Kalıpları: Proxy (Vekil) – IV

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

Proxy tasarım kalıbıyla ilgili bir önceki yazıda, bu kalıp ile ilgili ikinci örneğimizi, ağ yapılarındaki proxy kullanımını simule etmiştik çünkü bizim yazılımda proxy kalıbıyla yapmaya çalıştığımız şey aslında yıllardır ağlarda güvenlik amacıyla kontrol ve filtreleme yapan proxylerin yaptığı şeydi. Şimdi bu konudaki son örneğimizle devam edelim.

GoF kitaplarında, proxy kalıbıyla ilgili örnek olarak içerisinde büyük hacimli resimlerin (image) olduğu bir metin dokümanını verir. Örnek yapıda, metin dokümanı açılırken yani belleğe yüklenirken, içerisinde var olan büyük hacimli resimlerin de yüklenmesini istemenin ciddi bir yaratma ve yükleme maliyeti yaratacağından bahsedilir. Bundan dolayı teklif edilen, metni görüntüleyenin, dokümanda gerçekten bu resimlere gelinceye kadar, resimlerin yüklenmesini geciktirmektir. Muhakkak böye bir yaklaşım metni daha hızlı belleğe yükleyecek ve kullanıcının metin üzerinde dolaşmasını ve onu kullanmasını daha rahat kılacaktır. Bu durumda yapılacak şey, metin dokümanı yüklenirken, resimlerin doğrudan belleğe yüklenmesi yerine, proxy yani, o resimler yerine geçen vekil nesnelerin ya da daha açık ifadeyle örneğin ikon gibi, İngilizce’de “placeholder” denen, o resmin olduğunu belirten “yer tutucu”ların yüklenmesidir. Yer tutucu nesne aşağıdaki şekilde “anImageProxy” olarak görüntülenmiştir.

ProxyDocument1

Bu noktada dikkat edilmesi gereken şey, gerçek resimler yerine yer tutucuların yüklendiğini, metnin bilmemesi gerektiğidir. Bu şekilde yer tutucu yani vekil resim (burada sanırım vekillikten ziyade “göstermelik” kelimesi daha anlamlı oluyor)  kullanmanın, metnin yapısında hiç bir değişikliğe sebep olmaması gereklidir. Bunu sağlamanın yöntemi ise gerçek nesne ile vekilinin aynı arayüze sahip olmasıdır. Eğer bu nokta atlanırsa, proxy nesnesi, doğrudan arada bulunan ve varlığından özellikle vatandaş ya da bu örnekteki metin dokümanı gibi müşteri (client) nesnelerinin tamamen haberdar olduğu, basit al-ver (delegation) yapan nesneye dönüşür ki bu durumda da zaten “program to an interface, not an implementation” prensibini ıskalamış oluruz.

Bu kalıp bu olaya uygulandığında aşağıdaki diyagrama ulaşırız:

 

ProxyDocument2

Yukarıdaki şekile bakarken, GoF’un kitabı yazılırken UML’in henüz tamamlanmadığı gerçeğini göz önüne almalıyız. Ayrıca GoF örneklerini C++ ile verdiklerinden şekildeki kod parçaları bu dildedir. Biz bu yapıyı Java ile yazarsak kodlarımız şöyle olacaktır:

Image, arayüzdür:

package org.javaturk.dp.pattern.gof.structural.proxy.image;

public interface Image {
	public void draw();
	public void erase();
}

 

BigImage, yüklenmesini geciktirdiğimiz büyük resim nesnemizdir.

package org.javaturk.dp.pattern.gof.structural.proxy.image;

public class BigImage implements Image {

	public void draw() {
		System.out.println("Drawing the big image");
	}

	public void erase() {
		System.out.println("Erasing the big image");
	}
}

 

ImageProxy ise vekil resim nesnesidir:

package org.javaturk.dp.pattern.gof.structural.proxy.image;

public class ImageProxy implements Image {
	
	private BigImage bigImage;

	public void draw() {
		if(bigImage == null)
			bigImage = new BigImage();
		bigImage.draw();
	}

	public void erase() {
		bigImage.erase();
	}
}

 

ImageChooser ise singleton resim gösteren nesnedir.

package org.javaturk.dp.pattern.gof.structural.proxy.image;

public class ImageChooser {
	
	private static ImageChooser ic = new ImageChooser();
	private Image image;
	
	public ImageChooser(){
		image = new ImageProxy();
	}
	
	Image getImage(){
		return image;
	}

	public static ImageChooser getInstance(){
		return ic;
	}
}

 

Document ise, sadece main metoda sahip olan metin nesnemizdir:

package org.javaturk.dp.pattern.gof.structural.proxy.image;

public class Document {

	public static void main(String[] args) {
		ImageChooser imageChooser = ImageChooser.getInstance();
		Image image = imageChooser.getImage();
		
		double chance = Math.random();
		if(chance > 0.9)
			image.draw();
	}
}

 

Document nesesinin main metodundaki “if” yapısı, gerçekte BigImage nesnesinin yüklenmesinin sanki %10’luk bir ihtimal dahilinde olacağını göstermek için konmuştur.

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

Tasarım Kalıpları: Proxy (Vekil) – III

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

Proxy tasarım kalıbıyla ilgili bir önceki yazıyı, “Proxy kalıbını kullanabileceğiniz ya da kullandığınız ne gibi durumlar olabilir ya da oldu?” şeklinde bir soruyla kapatmıştık. Bu kalıbın kullanılabileceği durumlara bir örnek daha verelim.

Eskiden, örneğin 80’li yıllarda ya da 90lı yılların başında, webin yeni yeni çıktığı dönemlerde kulandığımız bilgisayarlar, gateway denen ağ yapıları üzerinden internete bağlanırlar ve ihtiyacınıza göre http, ftp, telnet vb. protokolları kullanarak haberleşirlerdi. Dolayısıyla gatewaylerin arayüzlerinde, bu protokollarla ilgili istekleri karşılayan yapılar olurdu. (Bu anlamda gatewayleri, üzerinde protokollere karşılık gelen metotlara sahip sınıf olarak düşünebilirsiniz.) Bir müddet sonra bu durumun sakıncaları ortaya çıkmaya başladı ve internete çıkışın kontrol edilmesi gerekti. Örneğin belli protokolleri kullanmak, belli sitelere ulaşmak vb. konularında kısıtlamalara gidilmek istendi. Ya da yazışmaların filtrelenmesi ve belli anahtar kelimelerin olduğu yazışmaların engellenmesi gibi ihtiyaçlar ortaya çıktı. Fakat tüm bu kontrollerin var olan bilgisayarlarda, gatewaylerde ve protokollerde olabildiğince hiç bir değişikliğe gerek duyurmaması da ayrıca istendi. Aksi taktirde bu kontrollerin maliyeti çok yüksek olurdu. Örneğin makinalardaki tarayıcılar http ve https ile web ortamına ulaşıyorlarsa, bu kontrollerin olduğu durumda da aynı şekilde davranmalıydılar. Kontroller ise araya girerek çalışmalı ve duruma göre, haberleşmenin devam etmesine izin vermeliydiler. Bu şu anlama gelmekteydi: Bilgisayarlar hala sanki gateway ile haberleşiyormuş gibi davranmaya devam etmeliler ama gerçekte gateway ile değil de araya giren ve arayüzü tamamen gatewayler gibi olan ve kendilerine “proxy” denen, gerekli kontrol ve filtreleme işlerini yapan yapılar ile haberleşmeliler. Proxyler, kontrol ve filtrelerden sonra ya haberleşmeyi “buraya erişmeye yetkiniz yoktur” ya da “yasaklı site!” gibi bir uyarılarla kesmeliler ya da probem olmadığı durumlarda haberleşmeye izin vermeliler. Bu şekilde, makinalarla internet çıkışı sağlayan gatewayler arasına girerek bu tip kontroller yapan yapılara “proxy” denmesinin sebebi, bu yapıların tam da bu kalıpta olduğu gibi, “vekil” olarak davranmalarıdır. Bu tür vekillerin en temel iki özelliğini hızlıca tekrar edelim:

  • Gerçekte ulaşılmak istenen nesneyi saklamak ama bunu, saklanan nesne ile aynı arayüze sahip olarak yapmak ve bu şekilde “yokmuş gibi” davranmak. Bu durum, saklanan nesneye ulaşmak isteyen, onu bilen ve onunla haberleşebilen yapılarda (önceki örneğimizde vatandaş, bu örnekte ise bilgisayar) herhangi bir değişiklik yapmadan, araya bu tür vekiller sokmanızı sağlar. Çünkü vekiller “yokmuş gibi” (transparent) davranırlar.
  • Gerekli kontrol ve filtreleme işlerini yapmak. Vekiller bu işleri, yokmuş gibi davranarak yaparlar. Ben ilk bu tür proxylerin kullanıldığı ağ ortamların çalışmaya başladığımda, ftp, telnet, http vb. protokollerle örneğin tarayıcılar üzerinden çalışırken, daha önceki hale göre oluşan gecikmelerden, “araya proxy konmuş!”  yorumunu yapardım. Çünkü proxynin varlığını başka türlü anlamayabilirsiniz. (Gerçi sonraları tarayıcılarda proxy ayarları vb. ek işlerle proxyler hayatımızda fark edilmez olmaktan çıktılar.)

Şöyle bir soru sorulabilir: Neden kontrolleri gatewaylere koymuyoruz ki? Bu soru ile önceki yazıda ele aldığımız vatandaş-başbakan örneğindeki “neden bu kontrolleri başbakana koymuyoruz” sorusunun cevabı aynıdır: “Çünkü bu tür kontroller onların görevleri değil ki!” Düşünün bazı büyük markalar yogun ağ trafiğini etkin bir şekilde yönetmek için çok yetkin router, gateway vs. gibi, uzmanı olmadığım, tonla ağ yapısını hem donanım hem yazılım olarak yöneten yapılar üretiliyorlar. Bu yapıların temel görevi, http, ftp, telnet vb. protokolları gerçekleştirmek. Bu protokollarla ilgili, performans, ölçeklenirlik, uyumluluk vb. konularda envai çeşit detay var ve sonuçta zaten çok karmaşık yapılar ortaya çıkıyor. Bu yapılara, güvenlik kontrolleri ve filtreleme gibi farklı konularla ilgili yine son derece karmaşık ve özellikle de sıklıkla değişme eğiliminde olan yetkinlikleri koymak çok da tercihe dilecek bir durum değildir. Aynı şekide bu iki sorumluluk alanını birleştirmek, başbakanın önüne görüşülecek binelrce vatandaş listesini koymaktan farklı bir durum değildir. Fiziksel dünyada bu gibi durumlarda daima sorumlulukları ayırmayı tercihe diyorsak, “separation of concern” ya da “single responsibility” gibi prensipleri uyguluyorsak, soyut ve bundan dolayı anlaşılması ve yönetilmesi daha zor olan yazılım yapılarında bu prensipleri haydi haydi uygulamalıyız. Aki taktirde ne karmaşıklığı ne de değişimi yönetebiliriz. Aksi taktirde yazdığımız sınıflar da metotlar da devasa olur ve iki günde yazdığımız kodu değiştirmek bir haftayı alır. İşte bu yüzden tasarım kalıplarını bilmek ve uygulamak bize çok güzel bir sorumlulukları ayırma ve değişimi yönetecek şekilde nesnelere atama yeteneği kazandırır.

Tekrar esas problemimize dönersek, gateway, proxy ve bilgisayar arasındaki ilişkiyi proxy tasarım kalıbıyla modellersek örnek olarak şöyle bir yapıya ulaşabiliriz:

Network, internete açılacak yapıların arayüzüdür:

package org.javaturk.dp.pattern.gof.structural.proxy.network;

public interface Network {
	public void telnet(String ip, String targetIp) throws YasakKardesimException;
	public void ftp(String ip, String targetIp) throws YasakKardesimException;
}

Gateway, gerekte internet bağlantısı yapan yapıdır. Koddan da görüldüğü gibi Gateway, bir Network‘tür ve singletondır.

package org.javaturk.dp.pattern.gof.structural.proxy.network;

public class Gateway implements Network {
	private static Gateway gateway = new Gateway();

	public void ftp(String ip, String targetIp) {
		System.out.println(ip + " makes an ftp to " + targetIp + "\n");
	}

	public void telnet(String ip, String targetIp) {
		System.out.println(ip + " makes a telnet to " + targetIp + "\n");
	}
	
	public static Gateway getInstance(){
		return gateway;
	}
}

 

ProxyServer ise, bilgisayar ya da bu örnekte NetworkClient ile Gateway arasına giren proxy yani vekil nesnesidir. Bu yüzden ProxyServer, bir Network‘tür ve internete gerçek çıkışı sağlayan Gateway‘in tek olan nesnesine sahiptir:

package org.javaturk.dp.pattern.gof.structural.proxy.network;

public class ProxyServer implements Network {
	
	private Gateway gateway;
	
	public ProxyServer(){
		gateway = Gateway.getInstance();
	}
	
	public void ftp(String ip, String targetIp) throws YasakKardesimException{
		Logger.log(ip + ", " + targetIp + " adresine ftp yapmak istiyor");
		
		if(targetIp.startsWith("192"))
			throw new YasakKardesimException(targetIp + " adresine ftp yapmaniz yasaktir!");
		
		gateway.ftp(ip, targetIp);
	}

	public void telnet(String ip, String targetIp) throws YasakKardesimException{
		Logger.log(ip + ", " + targetIp + " adresine telnet yapmak istiyor");
		
		if(targetIp.startsWith("192"))
			throw new YasakKardesimException(targetIp + " adresine telnet yapmaniz yasaktir!");
		
		gateway.telnet(ip, targetIp);
	}
}

 

ProxyServer‘ın kullandığı Logger ise basit loglama yapan bir sınıftır:

package org.javaturk.dp.pattern.gof.structural.proxy.network;

import java.util.Date;

public class Logger {
	public static void log(String message){
		System.out.println(new Date() + ": " + message);
	}
}

 

NetworkServer ise bilgiayarları (ya da Network Client), ağ altyapısına bağlayan sınıftır:

package org.javaturk.dp.pattern.gof.structural.proxy.network;

public class NetworkServer {
	
	private static NetworkServer ns = new NetworkServer();
	private Network network;
	
	private NetworkServer(){
		network = new ProxyServer();
	}
	
	public Network getNetwork(){
		return network;
	}
	
	public static NetworkServer getInstance(){
		return ns;
	}
}

 

Pek tabi ki kodumuzun tam olması için YasakKardesimException isimli sıra dışı durum sınıfına da ihtiyacımız vardır:

package org.javaturk.dp.pattern.gof.structural.proxy.network;

public class YasakKardesimException extends Exception{
	
	public YasakKardesimException(String message){
		super(message);
	}
}

 

Bilgisayar gibi ağ hizmetlerini tüketen nesne ise bu örnekte NetworkClient‘dır. Bu sınfı aynı zamanda main metoda da sahiptir.

package org.javaturk.dp.pattern.gof.structural.proxy.network;

public class NetworkClient {

	public static void main(String[] args) {
		NetworkServer networkServer = NetworkServer.getInstance();
		
		Network network = networkServer.getNetwork();

		String myIp = "10.0.0.2";
		try {
			network.telnet(myIp, "88.168.2.200");
		} catch (YasakKardesimException e) {
			System.out.println(e.getMessage());
		}

		try {
			network.ftp(myIp, "192.168.2.200");
		} catch (YasakKardesimException e) {
			System.out.println(e.getMessage());
		}
	}
}

 

NetworkClient sınıfını çalıştırdığımzıda şı çıktıyı elde ederiz:

Wed Feb 11 14:01:23 EET 2015: 10.0.0.2, 88.168.2.200 adresine telnet yapmak istiyor
10.0.0.2 makes a telnet to 88.168.2.200

Wed Feb 11 14:01:23 EET 2015: 10.0.0.2, 192.168.2.200 adresine ftp yapmak istiyor
192.168.2.200 adresine ftp yapmanız yasaktır!

 

Bu yazıda hem  proxy kalıbının güzel bir örneğini gördük hem de hem genelde tasarım kalıplarının hem de özelde proxy kalıbının, sorumlulukları doğru nesnelere atamakta ve aralarını değişimi gözeterek ayırmakta bize nasıl yardımcı olduklarını gözlemledik.

 

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

1 2