tasarım desenleri

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

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

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

Tasarım kalıpları üzerine olan ilk yazıda şöyle demiştik: “Tasarım kalıpları, temel nesne-merkezli prensipleri kullanarak doğru sorumlulukları bulmamıza (finding responsibilities), değişimi göz önüne alarak bu sorumlulukları nesnelere dağıtmamıza (highly-cohesive objects) ve nesneleri, aralarında az bağımlılık olacak şekilde (lowly-coupled objects) kurgulamamıza yardımcı olur. Bir başka deyişle tasarım kalıpları, yüksek birliktelikli ve düşük bağımlılıklı yapıları nasıl kurgulayacağımızı, sıklıkla karşılaşılan problemler bağlamında, model olarak ortaya koyar.”

Şimdi de bu cümleyi daha iyi hazmetmek için, Proxy ya da Vekil kalıbımızı ele alalım. Malum “proxy” İngilizce’de vekil demek. Burada da vekalet kavramı üzerine kurgulanan bir yapı söz konusu. Vekil kalıbı ile yapmak istediğimiz şey, “herhangi bir sebepten dolayı bir nesneye olan erişimi kontrol etmektir”. Nitekim GoF’da da bu kalıbın amacı şöyle ifade ediliyor:

“Provide a surrogate or placeholder for another object to control access to it.”

Yani

“Kendisine erişimi kontrol etmek için bir nesneye geçiş sağla”.

Burada elimizde, kendisine erişimi, herhangi bir sebepten dolayı kontrol etmek istediğimiz bir nesne söz konusudur. Bu nesne çok değerli ya da çok tehlikeli olduğu için kendisine ulaşımı kontrol etmek isteyebiliriz. Yani kimse bu nesneye doğrudan ulaşmasın, arada ulaşımı sağlayan bir elçi, geçiş sağlayan nesne olsun isteriz. Ya da GoF’da anlatıldığı gibi bellek ve CPU açısından pahalı olan bir nesnenin oluşturulmasını, gerçekten o nesneye ihtiyaç duyuncaya kadar geciktirmek ama aynı zamanda sistemin sanki bu nesne zaten varmış gibi davranmasını isteyebiliriz. Örneğin, uygulamalarınızın “Help” dokümanlarını düşünün. Sistem ayağa kalkarken bu dokümanın da yüklenmesini istemezsiniz ama sistemin bundan haberdar olmamasını ve sanki bu doküman varmış yani yüklenmiş gibi davranmasını istersiniz. Tüm bu gibi durumlar, esas nesneye erişimi kontrol etmek için farklı sebepler demektir.

Şimdi bu kalıbı daha iyi anlayabilmek için, ihtiyacımızın ortaya çıktığı bir durumu anlatalım:

Malum, demokrasilerde halklar kendilerini, seçtikleri vekiller yardımıyla yönetirler. Dolayısıyla vatandaşın, kendisini yönetenlere erişme hakkı vardır. Erişilecek en tepe seçilmiş yönetici ise başbakandır. Yani vatandaşların başbakana erişimleri olmalıdır, bu onların hakkı, başbakanın ise sorumluluğudur. Buraya kadar tamam ama her önüne gelenin doğrudan başbakana erişebilir durumda olması çok da arzu edilen bir durum değildir. Örneğin böyle bir durum başbakan açısından güvenlik problemi oluşturduğu gibi, örneğin ülkemizde milyonlarca vatandaşın olduğu göz önüne, alınırsa pratik de değildir. Bu durumda başbakana erişimi kontrol etmemiz gereklidir fakat bunu yaparken vatandaşların rahatsız olmasını da engellememiz önemlidir.

Yukarıdaki problemde başbakan nesnesine erişimi, bu nesnenin hem değerli olmasından hem de erişecek nesnelerin sayıca çok olmasından dolayı, kontrol etmek istiyoruz. Dolayısıyla bu problemi vekil kalıbı yardımıyla çözmek için sorumluluklardan başlayarak ilerleyelim. Sorumluluklar nelerdir?

  • Başbakan, vatandaşın derdini dinlemek ve ona iş bulmak (:) ) gibi iki sorumluluğa sahip olsun.
  • Vatandaş da başbakana derdini anlatmak ve ondan iş istemek gibi iki sorumluluğa sahip olsun.

Buraya kadar kolay. Yukarıdaki sorumluluklardan Başbakan ve Vatandaş isimli iki nesneye ihtiyacımız olduğunu çıkarabiliriz. Yani şöyle bir sınıf diyagramına sahibiz:

Proxy0

Bu yapıdaki problem, Başbakan‘ın korunmuyor olmasıdır. Bu “korunmama” durumundan dolayı, Vatandaş, örneğin pek çok Başbakan nesnesi oluşturabilir. Başbakan‘ı singleton yaparak bunun önüne geçebiliriz ama aynı anda binlerce, milyonlarca Vatandaş nesnesinin Başbakan‘a gelişi güzel erişmesini engelleyemeyiz. Burada bir engelleyici, daha doğru ifadeyle kontrol edici, filtreleyici bir yapıya ihtiyaç vardır öyle ki Başbakan‘ın kimle hangi şartlar altında konuşacağı belirlenebilsin. Örneğin, Başbakan nesnesinin, her gün aksam saat 10:00 ile 12:00 arasında Vatandaş‘ların derdini dinlemek istemesi ama herhangi bir iş isteğini dinlemek istememesini nasıl bu yapıyla halledebiliriz? Eğer düzgün bir nesne kültürümüz yok ise, bu tür kontrolleri ya Vatandaş ya da Başbakan nesnesine, muhtemelen Başbakan‘a koyma eğiliminde oluruz. Bu ise problemli bir durumdur çünkü bu sorumluluk ikisinin de sorumluluğu değildir. Aşağıda resmedilen bu durumda Başbakan’ın koduna sıklıkla müdahele edilmesi gerekecektir. Her halükarda bu yapı, ne sorumlulukları ayırmakta ne de değişimi yönetmektedir.

Proxy1

Bu durumla ilgili bir başka problem hem Başbakan‘ın hem de kontrol yapısının zaman zaman değişeceği gerçeğidir. Yani örneğin Başbakan bir yurt dışı gezi yapacağı hafta rahatlıkla, “bu hafta dert dinleyemeyeceğim” diyebilir. Dolayısıyla bu yapıda en sık değişecek kısım bu kontrol mekanizmasıdır. Bu durumda kontrol sorumluluklarını arada bir nesneye yükleyip, bu nesnenin Vatandaş ile Başbakan arasında bir tampon oluşturması makul görünebilir. Bu durumda şöyle bir yapıya ulaşırız:

Proxy2

Bu yapının en büyük problemi ise, bu kalıbın amacına tamamen ters düzen bir durum: Vatandaş, Başbakan ile konuşmuyor, Vekil ile konuşuyor ve bu durum problemde bahsettiğimiz demokrasinin en temel şartını ihlal ediyor.

Açıkçası olması gereken durumda, Vatandaş, Başbakan ile konuştuğunu düşünmeli ama biz hala Başbakan‘ı korumalıyız. Bu duruma ancak Başbakan ile Vekil‘in aynı görünmelerini sağlayarak ulaşabiliriz. İki nesnenin aynı görünmesi ise arayüzlerinin aynı olması ve polymorphism sayesinde birbirleri yerine geçebilmeleriyle mümkün olur. Yani Vekil ve Başbakan, aynı arayüzü devralmalıdırlar. Yani, aşağıdaki gibi bir yapıya sahip olmalıyız.

Proxy3

Bu sınıf diyagramına göre, Vatandaş, Başbakan arayüzünü bilmekte ve onun bir nesnesiyle konuşmaktadır. Lakin, BaşbakanlıkVekili, Vatandaş‘a konuşması için GerçekBaşbakan‘ın bir nesnesini değil, VekilBaşbakan‘ın nesnesini geçmektedir. Bu durum, bize hem Vatandaş‘ın Başbakan‘la konuşmuş olmasını sağlayacak hem de GerçekBaşbakan‘ı korumamıza imkan verecektir çünkü Vatandaş, gerçekte VekilBaşbakan‘la konuşmaktadır. Bu yapıda VekilBaşbakan da yukarıda bahsettiğimiz, kontrol sorumluluklarını yerine getirecektir. Yani aslında GerçekBaşbakan‘ın neyi ne zaman dinleyeceğini belirleyen nesne VekilBaşbakan‘dır. Bu yüzden VekilBaşbakan, GerçekBaşbakan’ın nesnesine sahiptir ve kontrol kuralları çerçevesinde Vatandaş‘tan kendisine gelen istekleri, GerçekBaşbakan‘a iletecektir.

Bir sonraki yazıda bu çözümün kodlarına bakalım.

 

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

Tasarım Kalıpları – V: Singleton (Tek Nesne) – II ve Double-Checked Locking

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

Tasarım kalıpları dizisinin bir önceki yazısında, ilk kalıbımız olarak Singleton’u ele almıştık. Aslında Singleton kalıbı başlangıç itibariyle kolay ve kısa olmasına rağmen, üzerinde yapılacak ufak bir oynamayla son derece karmaşık hale gelebilir. Bu yazıda da Singleton tasarım kalıbı üzerine yapılacak bu ufak değişikliğin ne olduğunu ve nasıl sonuçları olduğunu ele alalım.

Singleton kalıbımızın kodu şöyleydi:

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

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);
	}
}

Yukarıdaki örnekteki problem, Singleton sınıfı yüklenirken “private static Singleton singleton = new Singleton();” satırının çalışması ve hiç kullanılmayacak olsa bile Singleton’un tek nesnesini yaratmasıdır. Özellikle bellek açısından ciddi kaynak tüketecek kadar büyük ve karmaşık olan nesnelerin oluşturulmasını, gerçekten erişilinceye kadar geciktirebiliriz. Bu şekilde, bir nesnenin oluşturulmasının istenildiği ana kadar geciktirilmesine, “sonradan yükleme” ya da “lazy loading” denir. Bunun tersi, yani yukarıdaki durum ise “önden yükleme” ya da “eager loading” olarak adlandırılır. Sonradan yüklemeyi kullandığımız durumda şöyle bir yapıya ulaşırız:

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

public class LazySingleton {

	private static LazySingleton singleton;
	
	private static int count;
	private String name;

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

	public static LazySingleton getInstance() {
		if(singleton == null)
			singleton = new LazySingleton();
		return singleton;
	}

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

Yukarıdaki sınıftaki singleton nesne, LazySingleton sınıfından üretilmektedir ve koddan da görüldüğü gibi tek nesnenin oluşturulması, “getInstance()” metodunun çağrısına kadar geciktirilmektedir. Bu yüzden tek nesne, bu metot çağrılmadıkça oluşmayacaktır, ilk defa metot çağrıldığında nesne oluşacak, sonraki çağrılarda ise bu meottaki “singleton == null” ifadesi false döneceğinden, tek nesne doğrudan metottan döndürülecektir.

Bu ikinci tip singleton yani LazySingleton, son derece şık duruyor ama çok ciddi bir yanlışı var. LazySingleton, bu haliyle birden fazla kanalın (multi-threaded) olduğu durumlarda tek nesne olmaktan çıkacak, birden fazla nesnesi oluşabilecektir. Yani, birden fazla kanal aynı anda “getInstance()” metodunu çağırırsa, bu kanalların hepsi aynı anda tek nesnenin null olduğunu görüp, birer nesne oluşturulmasına sebep olabilir. Bu durumu görmek için aşağıdaki örneğe bakalım:

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

public class ThreadedLazySingleton {

	private static ThreadedLazySingleton singleton;

	private static int count;
	private String name;

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

	public static ThreadedLazySingleton getInstance() {
		if (singleton == null) {
			try {
				Thread.currentThread().sleep(1);
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
			singleton = new ThreadedLazySingleton();
		}
		return singleton;
	}

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

Birden fazla kanal oluşturan aşağıdaki istemciyi çalıştırırsak göreceğiz ki birden fazla ThreadLazySingleton nesnesi oluşacaktır. (Yukarıdaki örnekte “getInstance()” metodundaki “sleep()” metodu o anda çalışan kanalı 1 ms. uyutmak için konumştur ve tek amacı aynı anda birden fazla kanalın “singleton” nesnesini oluşturması ihtimalini arttırmak içindir.)

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

public class ThreadedLazySingletonClient extends Thread {

	public static void main(String[] args) {
		for(int i = 0; i < 10; i++){
			new ThreadedLazySingletonClient().start();
		}
	}
	
	public void run(){
		ThreadedLazySingleton ls = ThreadedLazySingleton.getInstance();
		ls.printName();
	}
}

Bu durumu yani birden çok “tek nesne” oluşmasını önlemek için tabi olarak “getInstance()” metodunu synchronized yapmalıyız. Bu metodu “public static synchronzied ThreadedLazySingleton getInstance()” olarak tanımladığımızda, ThreadedLazySingletonClient istemcisi kaç kanal oluşturursa oluştursun, sadece ilk kanal tek nesnenin oluşmasına sebep olacak, diğerleri ancak ilk kanal”getInstance()” metot çağrısını bitirdikten sonra aynı metodu çağırabileceğinden, tek nesne üzerinde null kontrolü artık false dönecektir. Çünkü synchronized anahtar kelimesi, “getInstance()” metodunu thread-safe hale getirecektir.

synchronized anahtar kelimesi ile thread-safe hale getirilen ThreadedLazySingleton sınıfın problemi, “getInstance()” metodunun sürekli olarak synchronized anahtar kelimesinin getirdiği kontrollerden dolayı yavaş çalışmasıdır. Bildiğiniz gibi, Java’da bu anahtar kelimeyi sadece metotlara değil, metot içindeki bloklara da uygulayabiliriz. Yani bu metodu aşağıdaki gibi sadece bir bloğunu thread-safe hale getirerek kullanabiliriz. Thread-safe hale getirdiğimiz ThreadedLazySingleton sınıfın bir metodu olduğundan dışlayıcı kilit (mut-ex lock) olarak ThreadedLazySingleton sınıfın “class” nesnesini kullanmalıyız.

public static ThreadedLazySingleton getInstance() {
      synchronized(ThreadedLazySingleton.class){
           if (singleton == null) {
		try {				   
                   Thread.currentThread().sleep(1);
		} catch (InterruptedException e) {
		   e.printStackTrace();
		}
		singleton = new ThreadedLazySingleton();
           }
      }
      return singleton;
}

Yukarıdaki kod ile aslında çok da fazla bir performans kazanımında bulunmadık çünkü if içindeki “singleton == null” kontrolü, bu metodun her çağrılışında, hem de synchronized olarak çalışıyor. Yani “singleton == null” kontrolünün thread-safe olarak çalışması gereken zaman aslında “singleton” tek nesnesinin oluşturulmasından önce olan zamandır. Bu nesne henüz oluşturulmadan, bütün “singleton == null” kontrolleri thread-safe olarak yapılmalı ama bir defa oluşturulduğunda yani “singleton = new ThreadedLazSingleton()” satırı çalıştığında, artık “singleton == null” kontrolünün synchronzied olarak olmasına gerek yoktur. Buradan şu sonuç çıkar: Eğer tek nesnenin oluşturulmasını sonradan yüklemeyle yapmak ama aynı zamanda performanslı olmasını istiyorsak, “singleton == null” kontrolünü, birisi çok kanallı, diğeri thread-safe halde iki defa yapmalıyız. Bu durumda kodumuz şu hale gelecektir:

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

public class ThreadSafeLazySingleton {

	private static ThreadSafeLazySingleton singleton;

	private static int count;
	private String name;

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

	public static ThreadSafeLazySingleton getInstance() {

		if (singleton == null) {
			synchronized (ThreadSafeLazySingleton.class) {
				if (singleton == null) {
					try {
						Thread.currentThread().sleep(1);
					} catch (InterruptedException e) {
						e.printStackTrace();
					}
					singleton = new ThreadSafeLazySingleton();
				}
			}
		}
		return singleton;
	}

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

Bu son durumda istemcimiz benzer şekilde şöyledir:

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

public class ThreadSafeLazySingletonClient extends Thread{
	
	public static void main(String[] args) {
		for(int i = 0; i < 10; i++){
			new ThreadSafeLazySingletonClient().start();
		}
	}
	
	public void run(){
		ThreadSafeLazySingleton ls = ThreadSafeLazySingleton.getInstance();
		ls.printName();
	}
}

Son durum olan ThreadSafeLazySingleton sınıfının “getInstance()” metodunda “singleton == null” kontrolünün iki defa yapılmasından dolayı bu yaklaşıma double- checked locking kalıbı denir.

Double-checked locking, bir kalıp ya da ters-kalıp (anti-pattern) olarak literatüre geçmiştir. Bir kalıptır çünkü çok kanallı hallerde daha etkin yazmamızı sağlar, ters-kalıptır çünkü kodumuzu karmaşıklaştırır ve… Ve’sini bir sonraki yazıda ele alalım 🙂

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

Yazılım Karmaşıklığı ve Değişim – I

Yazılım Mühendisliği , , , ,

Yazılımın en temel iki özelliği, karmaşıklık ve değişmedir.Yani yazılım ürünleri aşırı karmaşık ve çok sık değişmesi gereken yapıdadırlar. F. Brooks, “No Silver Bullet” isimli makalesinde, yazılımın asli (essential) özelliklerinden bahsederken, diğer iki özelliğinin yanında (görülemezlik (invisibility) ve uyumluluk (conformity)) karmaşıklık ve değişebilirlikten bahseder. Görülemezlik ve uyumluluk özelliklerini, karmaşıklığın ve değişebilirliğin sebeplerinden birer tanesi olarak görürsek, “yazılım asli olarak karmaşık ve değişebilirdir” diyebiliriz.

Yazılım, soyuttur, kavramsaldır, görünmezdir, dolayısıyla anlaşılması ve anlatılması zordur. Yazılımın genelde örneği yoktur; aynı türden yazılım olsa bile farklılıkları çok fazladır, dolayısıyla birinden diğerine geçiş yapmak ya da birinden diğerini türetmek imkansızdır. Çünkü yazılımın bileşenleri kendi başlarına özeldirler, benzerleri yoktur. Bu anlamda yazılımda aynı “şey”den (satır, blok, metot, sınıf, dosya, modul, vs.) iki tane olması istenmeyen bir durumdur. Zaten eğer iki şey benzer ise birleştirilirler. Tekrar kullanılabilirlik bu yüzden son derece zordur. Dolayısıyla yazılımların büyümesi var olan bileşenlerin büyümesiyle değil de yeni ve orijinal bileşenlerin eklenmesiyle gerçekleşir.

Yazılım sistemlerinin bütün durumlarını (state) düşünmek, elde etmek, test etmek, dokümante etmek vs. imkansızdır. Çünkü, soyut kavramların durumlarını belirlemek genel olarak ya çok zordur ya da imkansızdır.

Yazılımların bileşenleri arasındaki ilişkiler de doğrusal (linear) değildir. Fiziksel dünyada, sistemler fiziksel kısıtlarla çevrelendiğinden, alt sistemler ve parçalar arasındaki ilişkileri kontrol altında tutmak mümkündür. Örneğin, bir aracın kasasının, tekerleklerle olan bağlantısı, son derece basit, standart ve akıllıca tanımlanmıştır öyle ki bu standartlara her araç ve jant üreticisi uyar; böylece aracınızı nereden almış olursanız olun, istediğiniz yerden jant ya da lastik alıp, aracınıza takabilirsiniz. Aracınızın tekerleklerini değiştirmek, sileceklerde ya da akaryakıt filtresinde bir etkiye sebep olmaz. Yazılımda durum nasıldır? Yazılım sistemlerindeki karmaşıklık öylesine büyüktür ki aynı karmaşıklığa araçlarda sahip olsaydık muhtemelen bir tekerleğin çalışmasını anlamak için bujiden tutun da sileceklere, kaportadan tutun da antene kadar pek çok şeyi anlamamız gerekecekti.

Benzer durum değişim için de geçerlidir. Son derece karmaşık yapıdaki yarış arabalarının bir yarış esnasında dört tekerleğini değiştirmek 15-20 saniyede yapılabiliyor. Benzer karmaşıklıktaki bir yazılımın, tekerleğe karşı gelen, benzer büyüklükteki bir modülünü bırakın tamamen değiştirmeyi, böyle bir yazılımın en basit bir tarafıni bile değiştirmek günler hatta haftalar sürebilir. Karşılaştırma yapmak zor, farkındayım, ama uğraştığımız alanın kendine has özelliklerini anlamak ancak böyle kıyaslamalı örneklerle mümkün oluyor. Bu anlamda eğitimlerde çok sıklıkla tekrarladığım bir örneğim vardır: “Geçenlerde arabamın lastiklerini değiştirttim. Sonra yolda geri dönerken yağmür yağmaya başladı ve silecekleri çalıştırdım. Ama baktim ki silecekler çalışmıyorlar. Ne olabilir diye düşünürken aklıma lastikleri değiştiren ustayı aramak geldi. Belki orada bir şey olmuştur diye düşündüm. Usta da bana, ‘evet Akin abi, lastikleri değiştirince ilk bir – iki saat silecekler çalışmaz’ dedi.” Böyle bir şey yaşasak herhalde ustam şaka yapıyorsun değil mi deyip karşılıklı gülerdik. Peki böyle bir durum bir yazılım sisteminde olsa, hiç bir yazılımcıyı hiç şaşırtmaz ama. Çünkü, yazılımın parçaları arasındaki bu türden, kontrolsüz bir şekilde kurgulanmış ilişkiler o kadar yaygındır ki, aksini düşünmek zordur.

Fiziksel dünyada değişimi kolaylaştırmak amacıyla, sık değişecek şeyler kolay değişecek şekilde tasarlanmışlardır. Değişmesi zor olan parçalar genelde pek de sık değişmeyecek parçalardır. En sık değişen parçaları, işinin ehli olmayan insanlar bile değiştirebilirler. Ama örneğin trigger kayışı (ya da timing belt), genelde 60.000, 80.000 km gibi aralıklarla değiştiğinden, değişimi zor ve zaman alan bir parçadır.

Karmaşıklık

Robert E. Wood, 1986 yılında yayınladığı bir “Task Complexity: Definition of The Construct” isimli makalesinde, bir işin teorik yapısında üç parça olduğunu ifade eder:

• İşin ürettiği çıktılar (products)

• İşin yapılması sırasında gerekli işler (işlemler) ve davranışlar (required acts)

• İşin yapılması sırasında karar verirken gerekli bilgi parçaları (information cues)

Bu teoriyi yazılım sistemlerine uyguladığımızda, yazılımın karmaşıklığının sırasıyla en temel üç faktörü olarak şunları sayabiliriz:

• Program parçalarının karmaşıklığı: nesneler, metotları ve aralarındaki statik ilişkiler (temelde bilme ilişkisi),

• Program girdileri ve çıktıları arasındaki kamaşıklık: girilen veriler ve eventler ile üretilen hizmetler, GUI yapıları, nesne, veri, rapor, vs. arasındaki yapı, d.nüşüm ve işlemlerle ilgili karmaşıklık (zamansal, prosedürel ilişkiler),

• Veriler ve bilgi karmaşıklığı: işlenen veri yapılarının durumları ile sahip olunması gereken bilginin karmaşıklığı.

Bu üç karmaşıklık faktörünü şu şekilde de ifade edebiliriz:

Bileşen Karmaşıklığı = Program parçalarının karmaşıklığı + Veri/bilgi karmaşıklığı
Koordinasyon Karmaşıklığı = Program girdileri ve çıktıları arasındaki kamaşıklık

Bileşen karmaşıklığı, bileşenin alt parçalarının ne kadar “birlikte” (cohesive) olduğunun bir ölçüsüdür. Yani bir bileşen, ne kadar birlikteliği yüksek ise o kadar az karmaşıktır. Birliktelikten kasıt ise tek bir şeye odaklılıktır. Bir yazılım bileşeni, ister bir satır olsun ister bir blok, ister bir metot isterse de bir sınıf olsun, hatta isterse bir bileşen olsun, tek ama tek bir şeye odaklı olmalıdır. Birliktelik İngilizce’de cohesion olarak ifade edilir ve arzu edilen şey, highly-cohesive yani yüksek birliktelikli yapılardır çünkü karmaşıklıkları düşüktür.

Yüksek birliktelikli yapılar, aynı yerde birden fazla şeyi halletmeye çalışmazlar, sadece bir şeyi ama her yönüyle halletmeye odaklanırlar. Bu anlamda Osmanlıca’da tanımın tanımı olarak verilen “efradını cami ağyarını mani” sağlıklı nesneler için de geçerlidir. Yani nesneleriniz öyle olmalıdır ki bir konuyla ilgili her şeyi hallederken, ilgisiz olan hiç bir şeye de bulaşmamalıdır. Birlikteliği düşük sistemlerin anlaşılması, kodlanması, bakımı, testi, dokümantasyonu vs. hepsi çok daha zordur.

Koordinasyon karmaşıklığı, bir işin ne kadar kendi başına ifade edilebilirliğinin ya da diğerleriyle ne kadar “ilgili” olduğunun ölçüsüdür. İlgililik, diğerleri hakkında bilgidir yani bağımlılıktır (coupling) ve bağımlılığı düşük olan bileşenlerin karmaşıklığı da düşüktür. Bir bileşen oalbildiğince sadece ve sadece kendi hakkında bilmelidir, diğerleriyle ilgili bilgisi ise olabildiğince minimal düzeyde kalmalıdır. Bağımlılık İngilizce’de coupling olarak ifade edilir arzu edilen şey, lowly-coupled yani düşük bağımlılıklı yapılardır çünkü karmaşıklıkları düşüktür. Dolayısıyla, çevresindeki diğer nesnelerle alakası, bilgisi az olan nesnelerın bağımlılıği düşüktür, bu yüzden böyle nesneler daha kolay anlaşılır, aktarılır, kodlanır, test edilir ve dokumante edilirler.

Bu anlamda, gerek karmaşıklığı gerek ise değişimi yönetebilmek için yüksek birliktelikli ve düşük bağımlılıklı (highly-cohesive and lowly-coupled) yapılar kurgulamalıyız.

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