Yazılım Modelleme

Tasarım Kalıpları: Singleton (Tek Nesne) – I

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

Tasarım kalıpları yazı serisine, ilk kalıp örneğimiz ile devam edebiliriz.

Singleton, İngilizce’de tek olan şeye verilen isimdir. Yalnız yaşayan kişiye ya da biriç gibi oyunlarda, oyunun başında elde olan bir renkten tek kağıda da singleton denir. Yazılım açısından ise singleton, bir sınıftan sadece bir nesneye sahip olmak anlamına gelir. Bu yüzden bu kalıba dilimizde “tek nesne” diyebiliriz.

Singleton kalıbı, GoF’un nesne yaratmayla ilgili “creational” kalıplarındandır. GoF singleton için şu amaç (intent) ifadesine sahiptir:

Ensure a class only has one instance, and provide a global point of access to it.

Ya da

Bir sınıfın sadece bir tane nesnesinin olduğundan emin ol ve ona global bir erişim noktası sağla.

Singleton, yazılımlarda sıklıkla karşımıza çıkan ve bir sınıftan sadece ve sadece bir tane nesnenin bulunması gereken durumlara bir çözümdür. Bir sınıftan bir tane nesne olmasından kasıt ise, herkesin istediği zaman bu sınıfın bir nesnesini oluşturmaya çalışmamasıdır, oluşturamamasıdır. “Bir sınıfın sadece bir tane nesnesinin olduğundan emin ol” ile kastedilen budur.

Böyle bir durumla çok sık karşılaşırız. Arka taraftaki sisteme erişimleri kontrol eden yapıdan sadece bir tane olması istenir. Çünkü, bu tür nesneler trafik polisi gibi geçişi kontrol ederler, arka taraftaki sistemin vereceği hizmetlerin alınmasını düzenlerler vs. Örneğin, bir sistemde var olan yazıcıların, merkezi bir yerden yönetilmeleri makul bir durumdur. Kim hangi yazıcıya erişebilir, kim hangi yazıcıdan iş istiyor, bir yazıcıdan istenen işlerin sıraya konulması ve farklı tipte kullanıcıların farklı yazıcılarda farklı basım haklarına ve sayısına sahip olması gibi ihtiyaçların olduğu durumlarda, tüm yazıcıları ve onlara gönderilen basım isteklerini yönetecek bir merkezi sistemin (print spooler gibi) olması kaçınılmazdır. Bu sistemde merkezde bulunup, bu işleri yapacak olan nesneden sadece bir tane olması istenir. Hiç bir istemci, var olan tek nesne dışında, ikinci bir nesne yaratamamalıdır.

Benzer durum, yogun veri tabanı iletişimi bulunan OLTP tipindeki sistemlerde de veri tabanı erişim yönetiminde ortaya çıkar. Veri tabanına erişmek isteyen uygulamanın, erişimi sağlayan bağlantı (örneğin java.sql.Connection) nesnesine sahip olması gereklidir. Ama uygulamanın veri tabanına erişecek kısımlarının hepsinin ayrı ayrı bağlantı oluşturması istenen bir durum değildir. Çünkü hem bağlantı oluşturmak merkezileştirilmeli hem de bağlantı oluşturmak pahalı bir iş olduğundan, bağlantılar önceden oluşturulup bir havuzda (connection pool) tutulmalıdır ki isteyene bu havuzdaki hazır bağlantılardan servis yapılabilsin. Bu yüzden, bağlantıların üretilmesi, bir havuza atılması, isteyenlere servis edilmesi, istemcilerin kullandıkları bağlantılarla işleri bittikten sonra bağlantıyı havuza geri döndürmesi vb. gibi, tüm uygulamanın bağlantılarla ilgili ihtiyaçlarının merkezi bir yerden halledilmesi, mimari olarak uygun hatta gerekli bir yöntemdir. Bu durumda da bu merkezi konumdaki sınıfın, ismi ConnectionManager olabilir örneğin, sadece ve sadece bir tane nesnesinin olması gereklidir. Birden fazla nesne olması durumunda veri tabanına erişim ile ilgili ciddi problemler ve tutarsızlıklar olacağı açıktır.

Diğer taraftan, singleton yani tek olan nesneye erişim problemi de olmamalıdır. Kalıbın amacındaki “ve ona global bir erişim noktası sağla.” ifadesi, bu erişimin her yerden yapılabilecek şekilde olması gerektiğini söylemektedir.

Şimdi bu kalıbın çözümüne geçelim. Çözümde ben Java’yı kullanacağım ve bu çözüm, aslında kalıp olarak çok basit olmasına rağmen, detay bazı noktalardan dolayı bir yazı da gerektirecek cinstendir.

Peki şimdi son derece analitik olarak yaklaşıp, “nesne yaratma”ya odaklanalım. Çünkü kalıp, nesne yaratmakla daha doğrusu nesne yaratmayı sınırlandırmakla ilgili. Java’da nesne yaratmak için (iki sınıf hariç) daima “new” anahtar kelimesini kullanır ve yapılandırıcı (constructor) çağrısı yaparız. Yani singleton olacak sınıfın ismi Singleton ise, bu sınıfın nesnesini aşağıdaki gibi yaratırız:

...
Singleton object = new Singleton();
...

Singleton sınıfından nesne oluşturmanın ifadesi yukarıdaki satır olduğuna göre, biz bu satırın çağrılmasını nasıl kısıtlarız? Yani bu satırın herhangi bir istemci sınıfta yazılmasını nasıl engelleriz? Kalıbın çözümündeki esas mekanizma bu soruya verilecek cevap ile ortaya çıkar. Çünkü herhangi bir istemci sınıf bu ifadeyi yazabilirse, çok rahatlıkla bir for döngüsü içerisinde bu sınıftan bir sürü nesne oluşturabilir. Yani, öncelikle bu sınıftan tek bir nesne oluşturulmasına değil, istemcilerin hiç nesne oluşturamamasına odaklanmamız gereklidir. Bu da ancak ve ancak yukarıdaki satırın bir istemcide yazılmasının önüne geçmekle olabilir. Dolayısıyla, Singleton sınıfının dışında herhangi bir yerde, “Singleton object = new Singleton()” yazılmasının önüne nasıl geçebiliriz?

Soru nefis değil mi? Bu gibi bulmaca cinsinden sorular, kalıpların içinde çok sıklıkla ortaya çıkar ve tam da bu yüzden kalıpları öğrenmek çok zevklidir, çünkü zekanızı zorlarsınız.

Bakın, analitik yani çözümlemeci olmanın dibine vuralım ve sırayla gidelim. Bu cümlede

  • İlk element olan “Singleton”ın yazılmamasını sağlamanın yolu bu sınıfı public yapmamaktır. Singleton sınıfı public olmazsa, hiç bir erişim niteleyici (access modifier) kullanılmaz ve bu yüzden de bu sınıf, varsayılan erişime (default access) sahip olur. Bu durumda bu sınıfa sadece ve sadece içinde bulunduğu paketten erişilebilir. İstediğimiz ise bu değildir, çünkü bu durum global erişimi engelleyen bir haldir. Dolayısıyla çözüm, Singleton sınıfını public yapmamak değildir. Bu yüzden istemcilerde “Singleton” kelimesinin yazılmasını önleyemeyiz.
  • İkinci element olan “object”, üçüncü element olan “=”, atama işlemcisi ve dördüncü element ve bir anahtar kelime olan “new” da yazılmaları engellenemeyecek olan elementler değillerdir. Bir istemcide bu üç elementi de rahatlıkla yazabilirsiniz. Yani çözüm burada da değildir.
  • Geriye yazımını kontrol edebileceğimiz sadece ve sadece beşinci element olan “Singleton()” yapılandırıcı çağrısı kalmaktadır. Yukarıdaki cümlede, Singleton sınıfı dışında herhangi bir yerde yazılmasını engelleyebileceğiniz tek kısım “Singleton()” çağrısıdır. Çünkü Java’da erişim sınırlaması sağlayan yapılar (access modifiers) temelde üye elementlere erişimi kontrol ederler. Üye elementler ise ya üye değişkenler ya da üye metotlardır. Yapılandırıcı da üye bir metot olarak bu erişim kısıtlamasına dahildir. Uzun lafın kısası, yapılandırıcıyı “private” olarak nitelerseniz, kimse “Singleton()” yapılandırıcı çağrısını yapamaz.

Bu durumda Singleton sınıfımızı şöyle tanımlayabiliriz demektir:

public class Singleton{

   private Singleton(){
      System.out.println("Creating a singleton object");
   }
}

Yukarıdaki gibi bir kod daha önce hiç görmüş müydünüz? Garip olan şey, kaş yapayım derken göz çıkarmış olmamızdır 🙂 Yani böyle bir sınıfın hiç bir nesnesini kimse oluşturamaz, değil mi? Değil, doğrusu, “yukarıdaki Singleton sınıfının nesnesini, Singleton sınıfı dışında kimse oluşturamaz” şeklindedir. Yani Singleton, kendi nesnesini oluşturabilir çünkü “private” erişim niteleyicisi, kendi sınıfı için geçerli değildir. Bu durumda sınıfımız şu hale gelecektir:

public class Singleton{

   private Singleton object = new Singleton();

   private Singleton(){
      System.out.println("Creating a singleton object");
   }
}

Yukarıdaki kodu görünce ne düşündünüz? Böyle bir kod ile nesne kavramını ne kadar iyi bildiğinizi sınayabilirsiniz. Çünkü bu kod, “imkansız” koddur, fasit dairedir, hiç bir işe yaramaz. Çünkü singleton bir nesnenin, kendi tipinden bir nesne değişkeni olamaz. Bu yüzden “private Singleton object = new Singleton();” ifadesi bu haliyle saçma bir durum oluşturmaktadır. Düşünün öyle bir nesne oluşturacaksınız ki, içinde kendi tipinde bir başka nesne (yukarıdaki örnekte “object” ile ifade edilen) olacak ve bu içindeki nesne daha önce oluşturulmuş olacak ki yeni oluşan nesnenin parçası olabilsin. Bu mümkün değildir çünkü yukarıdaki yapıya göre Singleton sınıfının nesnesi zaten Singleton sınıfı dışında bir yerde oluşturulamaz. Buradan şu sonuç çıkar, “object” ile referans verdiğimiz nesne, nesne değişkeni değil, sınıf değişkeni, yani “static” olmalıdır. Bu durumda sınıfımızın yeni hali şöyle olur:

public class Singleton{

   private static Singleton object = new Singleton();

   private Singleton(){
      System.out.println("Creating a singleton object");
   }
}

Sınıfımızın bu son hali, kalıbın amacının “Bir sınıfın sadece bir tane nesnesinin olduğundan emin ol ” kısmını karşılamaktadır. Kalıbın amacının ikinci kısmı olan “ve ona global bir erişim noktası sağla.” ise bu sınıfa konulacak ve oluşturulan “object”i servis edecek public ve static bir metotla halledilebilir. Bu durumda da sınıfımız şu hale gelmiş olur:

public class Singleton{

   private static Singleton object = new Singleton();

   private Singleton(){
      System.out.println("Creating a singleton object");
   }

   public static Singleton getInstance(){
      return object;
   }
}

Artık Singleton sınıfımız gerçekten tasarım kalıbının istediği gibi tek bir nesnesi olan ve bu nesneye global bir erişim sağlayan yapıdadır.

Yukarıdaki Singleton sınıfını, sadece tek bir nesnesinin oluşturulduğunu ispatlayacak şekilde değiştirirsek:

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

Bu sınıfın bir de istemcisini de yazarsak:

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

public class SingletonClient {

	public static void main(String[] args) {
		for (int i = 0; i<10; i++){
			Singleton s = Singleton.getInstance();
			s.printName();
		}
	}
}

ve bu istemciyi, SingletonClient, çalışırırsak, göreceksiniz ki program konsola 10 tane “Singleton1” yazacaktır. Çünkü sadece bir nesne oluşturulmuştur çünkü o tek nesnenin ismi “Singleton1″dir.

Singleton tasarım kalıbıyla ilgili daha geniş bilgi için hem GoF kitabına hem de c2.com’a bakabilirsiniz.

Singleton tasarım kalıbı üzerine daha pek çok şey söylenebilir. Bunları da bir sonraki yazıya bırakalım.

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

Tasarım Kalıpları – IV: Kalıbı Tanımlamak

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

Daha önce yayınladığım ilk yazıyla tasarım kalıplarına giriş yapmış, ikinci yazıyla da tasarım kalıplarını öğrenmek üzerinde durmuştuk. Bu yazıda da tasarım kalıplarını nasıl ifade edebileceğimizi ele alalım. Sonraki yazıda da tasarım kalıpları örneklerini ele aşmaya başlarız.

Bir tasarım şablonunun temelde dört bileşeni vardır:

  • İsmi: Kalıbın ismi, o kalıbı, problemi ve çözümüyle birlikte ayırt etmemizi sağlar. Dolayısıyla kalıpların isimleri önemlidir ve genelde ilk bulanın koyduğu isimle anılır.
  • Problem: Tasarım kalıbının hangi bağlamda ve nasıl ortaya çıktığını ifade eder. Genelde sözel anlatım olarak verilir.
  • Çözüm: Tasarım kalıbının problemi nasıl çözdüğünü, bu amaçla kullandığı parçaları ve aralarındaki ilişkileri ifade eder. Çözüm, genelde UML’in class ve sequence diyagramları ile soyut olarak betimlenir, örnek bir gerçekleştirme ise C++ ya da Java gibi uygun bir nesne-merkezli dilde verilir.
  • Sonuçlar: Kalıbın sağladıklarını ifade eder. Kalıp hem bazı kazanımlar sağlar hem de bunların karşılığında bazı kayıplara sebep olur. Sonuçlar, ayrıntılı olarak bunları ifade eder.

GoF kitabında yukarıda sayılan dört bileşeni, daha detaylı bir şekilde ele almışlar ve aşağıdaki gibi bir kalıp tanımlama yapısı kullanmışlardır. Aşağıdaki listede var olanların bazıları doğrudan yukarıdaki dört maddeden birine denk gelmektedir.

  • Name (İsim): Kalıbın ismidir.
  • Intent (Amaç): Kalıbın amacıdır.
  • Problem/Motivation (Problem/Motivasyon): Kalıbın çözmeye çalıştığı, geniş bir alandaki pek çok özel problemi ifade eden ve soyut olarak tanımlanan tipik problemdir.
  • Solution/Structure (Çözüm/Yapı): Ortaya çıktığı bağlamda kalıbın verdiği çözümdür.
  • Participants and Collaborators (Katılımcılar ve Ortakları-Paydaşları) : Çözümde var olan ana nesneler ve onlarla beraber bulunan arayüz, yardımcı nesne vb. diğer yapılardır.
  • Consequences (Sonuçlar): Kalıbın sağladıklarını ifade eder.
  • Implementation (Gerçekleştirme): Kalıbın önerdiği çözümün gerçekleştirilmesidir.
  • Generic Structure (Genel Yapı): Genelde çözümün, UML’in class ve sequence diyagramları ile soyut olarak çizimidir.
  • Applicability (Uygulanabilirlik): Kalıbın uygulanabileceği bağlamları ifade eder.
  • Sample Code (Örnek kod): Gerçekleştirmeden bahsedilen ve nesne-merkezli bir dilde yazılan örnek kod parçalarıdır.
  • Known Uses (Bilinen Kullanımlar): Gerçek sistemlerde bilinen kullanımları.
  • Related Patterns (İlgili kalıplar): İlgili diğer kalıplar, aralarındaki benzerlik ve farklar ifade edilir.

GoF kitabının sonunda, kalıplar arasındaki ilişkileri şöyle bir çizimle vermişlerdir:

Kalıplar arasındaki ilişkiler

 

Bu yazıdan sonra artık tasarım kalıplarının kendilerinden bahsetmeye başlayabiliriz.

 

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

Tasarım Kalıpları – III: Nasıl Öğrenelim?

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

Tasarım Kalıpları ile ilgili ilk yazıda konuya giriş yapmıştık. Bu yazıda ise tasarım kalıpları nasıl öğrenebileceğimiz konusunu ele almak istiyorum. Çünkü bu konuda çok soruya muhatap oluyorum.

Bir kere peşinen şunu söylemekte fayda var: tasarım kalıpları bir teknoloji değildir. Bu yüzden de tonla farklı konuda kitap okuyan ya da bilgi konusunda abur-cubur beslenip bilgi obezitesi ya da bilgi sindirimi bozukluğu gibi sıkıntılara duçar olmuş pek çok genç arkadaşın, benzer düşünceyle tasarım kalıplarına yaklaşması çok ciddi hazım sorunları oluşturacaktır. Demek istediğim şu: Bir kitabı okumak, bir yaklaşımı öğrenmek ya da bir fikri hazmetmek için belli bir zihni olgunluğa gelmiş olmanız gereklidir. Benzer şey tasarım şablonları için de geçerlidir. Hatta bu gibi soyut yapıları öğrenmek için odaklanmanız da gerekir çünkü kavranmaları zordur. Odaklanmak her başarının ardındaki önemli noktalardan ama tasarım kalıplarını öğrenmek için teknolojinin ötesine odaklanmanız gerekecektir.

Tasarım kalıplarını öğrenmek, en çok soyut düşünme konusunda sizi zorlayacaktır. Soyut düşünme yeteneklerinizi de geliştirecektir aynı zamanda.  Bu durumu kolaylaştırmak için bir miktar UML özellikle de class ve interaction diyagramlarına bakmanızı öneririm.

Önce kitaplardan başlayalım. Tasarım kalıplarını öğrenmekten bahsedildiğinde tabi olarak akla ilk gelen kitap Gang of Four’un Design Patterns isimli kitabıdır. İşin açıkçası bu kitap 1994’de yazılmış olmasına rağmen henüz devrini tamamlamadığı gibi, pek aşılmış da değildir. Konu ile ilgili yazılmış pek çok kitap, bu kitabın tefsiri ya da farklı dillere uygulaması mahiyetindedir. Gerçi bu cins açıklayıcı kitaplar arasında çok başarılar da var elbette ama temelde bu kitapların pek çoğu, Design Patterns kitabına orijinal bir şey katmazlar.

Tecrübeli olmayanlar için zor bir kitaptır Design Patterns. Ciddi bir nesne altyapınız yok ise, nesne-merkezli dillerle uzunca süredir uğraşmıyorsanız, sırf ismi çok sık geçiyor diye bu kitabı okumaya çalışmak çok da faydalı bir hareket değildir, sadece öğrenilmiş çaresizlik üretir. Bu kitabı anlamak için yazılım üzerine çok ciddi soyut düşünce yeteneğine sahip olmak gereklidir. Kitabın örnekleri C++ ile verilmiştir ama Java ve C# gibi dillerde örnekleri olan pek çok açıklama ve uygulama mahiyetinde kitaplar da mevcuttur. Ben egitimlerde bu kitabı kullanıyorum. Hatta  gerek Pdf’inden gerek ise bizzat kendisinden sınıfta bazı kısa okumalar yapıp, eğitime katılanları bu kitaba yaklaştırmaya çalışıyorum.

Bu kitabın ilk iki bölümü nefis bir OO özetidir, hiç okuyamazsanız, bu iki bölümü, altını çizerek ve anlayarak okumanızı tavsiye ederim. Özellikle ilk bölümdeki nesnelerin bulunması, sorumluluklarının atanması, interface ve implementation ayrımı ve ilgili miras yapıları son derece keyifle okunacak konulardır. Yine bu bölümdeki “program to an interface, not an implementation”, “favor object composition over class inheritance” ve “design for change” prensipleri, her daim akılda tutulması gereken en temel yazılım tasarımı prensiplerdendir. Bu kitabı okumaya kesinlikle ilk iki bölümünü atlayarak başlamayın. Bu iki bölümü hazmederek okuyun sonrasında kalıplara geçin. Ben tasarım kalıpları eğitimlerinde, sınıfın durumuna göre bazen 1-1,5 günü bu üçünün yanında “tek sorumluluk” gibi diğer başka prensipleri de örneklerle açıklayarak geçiriyorum, aksi taktirde katalog gibi kalıpların üzerinden gitmenin bir faydasını görmem mümkün değildir.

Peki bu kitabı okuması zorsa ne ile başlayalım? Uzunca bir müddet burun kıvırarak baktığım Head First serisi kitaplarından olan “Head First Design Patterns” kitabı ile son zamanlarda biraz haşır neşir oldum ve bu seri ile ilgili fikrim değişti. Bu kitap GoF’un kalıplarının ciddi bir kısmını son derece eğlenceli tarzda anlatıyor. Ben kitabı “Lise mezunları için Tasarım Kalıpları” olarak niteliyorum zaman zaman 🙂 Temel nesne-merkezli prensipleri bilen, hatta bu konularda kafası karışık olan kişilerin bile sabrederek ilerlediklerinde çok faydalı olacak bir kitaptır. Bu kitapla, gayret ederseniz, muhakkak konuyu anlarsınız. Bu kitap hem anlaşılır, detaylı anlatımı, hem konuyu özetleyen güzel UML çizimleri hem de son derece kolay örnekleri ile tasarım kalıplarının dünyanıza girmesini sağlayacaktır. Kod örneklerini indirip, konularla atbaşı işleyebilirsiniz.

Head First Design Patterns kitabı, kalıplardan önce temel prensipleri açıklayan bir ön bölüme sahip. Aslında pek çok prensibi kalıpları anlatırken yapıyor. Fakat ilk bölümde, yazılımın en temel özelliklerinden olan “değişim”i ele alarak, GoF’un yukarıda bahsettigim üç prensibini açıklıyor. Bu amaçla örnekler üzerine kurgulanan bir problemi önce kalıtım sonra da arayüz ile tasarlıyor. Kitap sonrasında GoF’un kalıplarının yaklaşık yarısını, 11 bölümde ele alıyor. Geriye kalan kalıplara da son bölümde kısaca değiniyor.  Bu kitabın genişçe ele aldığı kalıplar, aslında öğrenilmesi en kolay olanlar. Dolayısıyla kitap okuyarak ve uygulamalarını yaparak kalıpları öğrenmek istiyorsanız, bu kitap tam bu iş için.

Benim tasarım kalıpları konusunda faydalandığım bir başka kaynak da Design Patterns Explained isimli kitaptır. Bu kitap GoF’un açıklaması mahiyetindedir ama bir kalıp kataloğu değildir. Dolayısıyla kitap daha çok kalıp merkezli düşümeyi sağlamak üzere, temel nesne-merkezli yaklaşım problemlerini ele almakta ve kalıplarla bu problemlerin nasıl giderildiğini anlatmaktadır. Kitabın örnekleri Java ile yapılmıştır ve bu örneklere online olarak ulaşabilirsiniz. Kitapta, GoF’un Façade ya da Strategy gibi sadece bazı kalıpları yer almaktadır. Head First kitabi size çok basit geliyorsa, bu kitapla başlayabilirsiniz.

Craig Larman’ın geniş ve güzel “Applying UML and Patterns” kitabından bahsetmeden geçmek olmaz. Bu kitap da aslen bir kalıp kataloğu değildir. Bu kitap hem temel prensipleri hem de bazı kalıpları, UML kullanarak, baştan sona bir tasarım süreci içerisinde ele alır ve detaylıca anlatır. Bu kitap kendi kendinize çalışmak için de nefis bir kaynaktır. Bu kitabın pek çok üniversitede UML ile nesne-merkezli analiz ve tasarım amaçlı derslerde kullanıldığını da biliyorum.

Kaynaklardan bahsedince tabi olarak “Türkçe kitap yok mu” sorusu akla geliyor. Maalesef dilimizde bu konularla ilgili özgün kitap pek yok. Zaten okuyan bir millet olmadığımız için, yazmak hepten bize uzak. Az da olsa bizim sektörümüzde fedakarlık yapıp, zaman ayırıp, güzel kitaplar yazanlar var. Bunlardan birisi de Özcan Acar. Özcan,  “Java Tasarım Şablonları ve Yazılım Mimarileri” isimli 290 sayfalık kitabında GoF’un 22 kalıbı yanında Java EE’nin de en bilinen mimari kalıplarını ele almıştır. Kitabın giriş mahiyetindeki ilk bölümünde soyut sınıflar ve arayüzler ele alınmakta ve altı temel prensipten bahsedilmektedir. Kitabın ikinci bölümü ise tasarım kalıpları kavramını açıklamaktadır. Kitabın 3., 4. ve 5. bölümlerinde GoF’un kalıpları, 6. bölümde ise Java EE kalıpları açıklanmaktadır. 7. bölümü ise tasarım kalıplarının, 3 katmanlı bir yazılım mimarisi içinde nasıl uygulandığı bir örnek uygulama ile ele alınmıştır. Son bölüm ise Spring mimarisi ve bu mimaride Data Access Object (DAO) kalıbının kullanımını ele almaktadır. Kitapta konuların sıklıkla UML sınıf diyagramlarıyla zenginleştirilmiş olması anlaşılmayı kolaylaştırmaktadır.

Özcan, muhtemelen okumama alışkanlığımızı aşmak için kitabını olabildiğince kısa tutmaya çalıştı diye düşünüyorum. Zaten önsözünde de belirttiği gibi anlaşılması için Java örneklerini olabildiğince basit halde vermiştir. Kitap ile birlikte gelen CD’den kitabın örneklerini edinebilirsiniz.

Ayrıca DZone’un konu ile ilgili referans kartlarını da elinizin altında tutmak isteyebilirsiniz.

Zaman zaman konuyla ilgili baktığım bazı web kaynakları da şunlardır:

Konu ile ilgili bazı güzel makaleleri de şöyle verebilirim:

Siz de tasarım kalıpları üzerine faydalandığınız kaynaklardan bahsederseniz buraya eklerim.

Bol tasarım kalıplı çalışmalar dilerim 🙂

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

Statik Metotlu Sınıf mı Yoksa Singleton mı? – I

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

Nesne-merkezli dillerde çok tartışılan konulardan birisi de hiç nesne oluşturmaya gerek bırakmadan kod yazmamızı sağlayan statik özellikler ve metotlar mı yoksa sadece bir tane nesne oluştuğundan emin olup, bu tek nesne üzerinde çağıracağımız nesne özellikleri ve metotları mı? Bu probleme kısaca statik-singleton (static vs. singleton) de denir çünkü tasarım kalıplarında, bir sınıftan sadece bir nesne oluşturmaya “singleton” yani “tekil” denir.

Bence statik kullanımı, tabi özellikle statik metot kullanımı, nesne-merkezli dillerin, yanlış kullanıma en fazla konu olanı ya da bir başka deyişle suistimale uğrayan alanı. Malum, loglama vb. utility metotlarını, üzerinde bulunduğu sınıfın nesnesini oluşturmadan hızlıca kullanmak isteriz. Örneğin aşağıda üzerindeki metotları statik olarak tanımlanmış ve bu yüzden de bu metotları kullanmak için nesnesine ihtiyaç duymayacağımız bir Log sınıfı vardır:

public class Log{
	
	public static void logInfo(String infoString){...}
	
	public static void logError(String errorString){...}

        ...
}

Bu sınıfın kullanım örneği de şöyle olabilir:

public class Client{
	public void doThis(){
                ...
                ...
               if(...)
                  Log.logInfo("...");
               else
                  Log.logError("...");
	}
}

Statik metotlara sahip böyle bir sınıfı kullanmanın kolaylığı çok açıktır: Sınıfın kendisini nesne gibi kullanmak. Dahası o tek nesneyi herhangi bir yere geçmenize bile gerek yok, doğrudan sınıfın üzerinden statik alanlara ve metotlara ulaşabilirsiniz.

Eğer yukarıdaki Log sınıfının metotlarını statik yapmak istemezsek ve bu sınıfın sadece bir tane nesnesinin olacağını planlıyorsak bu durumda Log sınıfını singleton olarak şöyle kodlardık:

public class LogSingleton{
	private static LogSingleton logger = new LogSingleton();
	
	private LogSingleton(){...}
	
	public static LogSingleton getInstance(){
		return logger;
	}
	
	public void logInfo(String infoString){...}
	
	public void logError(String errorString){...}
}

Bu durumda da yukarıdaki Client sınıfı şu şekilde değişirdi:

public class Client{
        private LogSingleton logger;

        public Client(){
                logger = LogSingleton.getInstance();
        }

	public void doThis(){
                ...
                ...
               if(...)
                  logger.logInfo("...");
               else
                  logger.logError("...");
	}
}

Şimdi soru şu: Hangi yöntemi kullanmalıyız?

Bazı diller bu ikilemi baştan çözmüşler ve yapılarına statik özellikler almamışlar. Örneğin Scala’da statik metotlu sınıf tanımlamanız mümkün değil, bunun yerine “object” anahtar kelimesiyle nesne tanımlıyorsunuz. Olan biten şey, Scala size doğrudan bir nesnesi olan sınıf tanımlamanızı sağlıyor. Güzel bir çözüm. Java, C#, C++ gibi dillerde ise statik kullanımı söz konusu olduğundan bu tartışma da geçerlidir. Bu durumda sizce hangi kullanımı tercih etmeliyiz ya da siz hangisini tercih ediyorsunuz? Statik metotlar mı yoksa singleton nesne mi?

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

«< 4 5 6 7 8 >