Şablon

Yaratımsal Kalıplar (Creational Patterns)

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

Yaratımsal kalıpları (creational patterns) ele aldık ama bu konu hala bir yazıyı hakediyor. Çünkü yaratımsal kalıpların arasındaki ilişkileri ve hepsinin bir arada nesne yaratma problemini nasıl çözdüklerini görmek, nesne yaratma problemini ve çözümlerini bir arada görmek açısından çok faydalı olacaktır.

GoF’da 5 tane yaratımsal kalıp vardır. Bunlardan Singleton, diğer dördünden farklı ele alınabilecek yapıdadır. Çünkü Singleton, “nesne yaratma” hakkında bir kalıp değildir. Yani Singleton, nesnenin ya da nesnelerin nasıl yaratılacağıyla ilgili değildir, o çok daha özel bir problemi çözer: Bir sınıftan sadece ve sadece bir tane nesne nasıl yaratılır? Dolayısıyla Singleton‘u kenara koyarsak, geriye kalan dört kalıbı ve aralarındaki ilişkileri ele alabiliriz.

Singleton‘u çıkardığımızda geriye kalan dört kalıptan ikisi, Factory Method ve Abstract Factory, diğer ikisinden yani Builder ve Prototype‘tan görevleri itibariyle ayrılırlar. Dolayısıyla, geriye kalan dört kalıp, iki ayrı grupta ele alınabilir. Aralarındaki fark, ilk grubun yani Factory Method ve Abstract Factory kalıplarının nesne yaratmayı soyutlamalarına rağmen diğer iki kalıbın, yani Builder ve Prototype‘ın nesne yaratmayı soyutlamak yerine nesne yaratma mekanizmasını gerçekleştiriyor olmalarıdır. Bir başka deyişle, Factory Method ve Abstract Factory kalıplarının esas hedefi, nesne yaratma kodunun ortalıkta gezinmesini yani nesne yaratan kodların tekrarını önlemek ve bu kodları tekrar kullanılabilecek şekilde soyutlamaktır. Dolayısıyla Factory Method ve Abstract Factory kalıplarındaki metotlarda nesnelerin nasıl yaratılacakları, bu kalıpların çözdüğü bir şey değildir. Factory Method ve Abstract Factory kalıpları, “nesneleri nerede yaratalım?” sorusunun cevabıdırlar. Bu sorunun cevabını Factory Method ya da Abstract Factory olarak verdikten sonra soru değişir. Nesnenin nerede yaratılacağı belli olduğuna göre soru artık  “nesneyi nasıl yaratalım?”dır. Builder ve Prototype kalıpları ise GoF’un bu soruya verdikleri cevaplardır.

Malum,”nesneyi nasıl yaratalım?” sorusu klasik olarak iki cevaba sahiptir: ya kurucu çağrısı ile bütün gerekli veriyi parametre olarak geçerek nesne yaratma ya da önce varsayılan kurucu çağrısı ile en temel durumda nesne yaratma ve sonra da set metotları ile nesneyi istenilen duruma getirme. Bu ikinci durum “JavaBean modeli” olarak bilinir. Buna bir de Joshua Bloch’ın Effective Java kitabında tavsiye ettiği statik factory metodu yaklaşımı eklenirse, alternatifler 3’e çıkar.

Bu iki sorulu ayrım ve cevapları aşağıdaki şekilde özetlenmiştir:

Object Creation

Şimdi bu ayrımı aşağıdaki örnekte ele alalım.

Örneğin elimizde bir tane Car sınıfı var ve uygulamada bu sınıfın değişik nesnelerini oluşturmamız gerekiyorsa, nesne oluşturan kodları bir Factory Method’un içine koyarız. Yok elimizde Car ile beraber Engine, Brake, Wheel, Door vb. sınıflar da varsa ve bu sınıfların nesnelerini biz bir arada oluşturuyorsak, bu durumda her birisi için gerekli olan Factory Method‘unu bir sınıfın içine koyar ve Abstract Factory‘i elde ederiz. (Açıkçası  Factory Method, AbstractFactory‘nin tek nesne için olan halidir. Bu yüzden ikisinin Factory adıyla tek bir kalıp olarak ele alınması daha iyi bir durum olur. Fakat GoF, bir hata yapıp ikisini ayırmış ve nihayetinde karmaşaya yol açmıştır. Bu konuda buraya bakılabilir.) Hatta eğer farklı Car nesneleri için Brake, Wheel, Door vb. sınıfların farklı durumda nesneler oluşturuluyorsa, bu halde her nesne ailesi için ayrı bir Abstract Factory sınıfı oluştururuz.

Buraya kadar sistemde var olan Car, Brake, Wheel, Door vb. sınıfların nesnelerinin nerede oluşturulacağı ile ilgili gerekli yapıyı kurguladık ama ister Abstract Factory olsun ister Factory Method olsun, nihayetinde nesne oluşturan üretici yani factory metotlarının içinde nesneleri gerçekte nasıl üreteceğimizi konuşmadık. İşte şimdi de bu kısma geldiğimizde elimizde hangi alternatiflerin olduğunu ele almalıyız.

Factory Method ve Abstract Factory kalıplarında nesneleri üretmek için temelde beş yöntemimiz vardır. İlk ikisi ve handikapları şöyledir:

  • Kurucu (constructor) çağrısı: En iyi bilineni parametreli kurucu çağrısı ile nesne oluşturmak. Kurucular, isimlerinin aynı olmasınan dolayı karıştırılılar ve çoğu zaman hataya yol açarlar. Ayrıca artan parametre sayısı kurucu çağrılarını gittikçe zorlaştırır.
  • JavaBean yaklaşımı: Varsayılan kurucu ile nesneyi oluşturup set metotlarıyla nesneyi istenilen duruma getirmek. Bu yaklaşım da kurucu çağrısı gibi problemlidir, hataya yol açabilir.

Yukarıdaki iki alternatif de basit nesnelerin oluşturulması için kullanılmalıdır. Basit nesnelerden kasıt ise kurucusuna geçilen parametre sayısı ya da JavaBean yaklaşımında çağrılacak set metodu sayısı 3-4’ü geçmeyendir. Hele JavaBean yaklaşımında set edilecek durum parametreleri arasında bağımlılık varsa ve bu set metotlarının çağrı sırasını belirliyorsa bu durumda hataya çok elverişli bir durum var demektir, kaçınılmalıdır. Bu halde aşağıdaki yollar tercih edilmelidir.

Peki, geriye kalan üç alternatif nedir:

  • Joshua Bloch’ın statik factory metotları: Joshua Bloch, Effective Java kitabında, nesne oluşturmak için, sınıfta tanımlanan karmaşık yani çok argüman alan kurucular yerine, anlamlı isimlere sahip statik factory (nesne üretici) metotları önermektedir. Buna göre kurucular private yapılır ve var olan her kurucu için,aynı sınıfta, statik, nesne yaratan yani factory metotlar oluşturulur öyle ki bu metotların isimleri, yarattıkları nesnenin durumunu göz önüne alacak şekilde verilir. “createAuthenticatedUnvalidatedCorporateUser” gibi isimlerle, hem kullanıcının durumuyla ilgili geçilecek ikisi muhtemelan boolean tipinde, üç ya da daha fazla  argümandan kurtulunmuş olur hem de kurucuların isimlerinin aynı olmasının getirdiği karıştırma problemi oradan kalkar. Bu konuda ayrıntılı bilgi için Bloch’ın Effective Java kitabına bakılmalıdır.
  • Builder (İnşacı): Eğer nesne karmaşık ve bu karmaşıklık nesnenin oluşturulma şeklini de belirliyorsa, nesnenin oluşturulması bir süreç gerektiriyor demektir. Bu durumda nesnenin yaratılmasından değil de oluşturulmasından, inşa edilmesinden bahsedilir. Bu şekilde, nesneyi bir süreç dahilinde oluşturmayı öneren kalıp, Builder ya da İnşacı kalıbıdır. Dolayısıyla karmaşık nesneler, bir süreç dahilinde bu kalıp ile oluşturulmalıdırlar.
  • Prototype (Örnek Nesne): Prototype da Builder gibi, oluşturulması zor dolayısıyla da yüksek karmaşıklıktaki nesnelerin yaratılması içindir ama ufak bir farkla. Prototype, yeni nesneyi, var olan bir nesneden oluşturur. Yani önce var olan örnek (prototype) nesneyi kopyalayar (clone) sonra istenilen duruma getirir. Bu yüzden, Prototype kalıbının odağı, durumdan (state) kaynaklanan karmaşıklıktır. Bu da şu anlama gelir: Eğer nesnenizin karmaşıklığı, nesnenin sahip olduğu durumlardan kaynaklanıyorsa, yani nesneniz iş için belirlenmiş bir kaç durumdan birinde olması gerekiyor ve developerların hepsinin bu durumları detaylarıyla bilmesi zor ise, o nesneyi bu durumlardan birinde oluşturmak zor ve hataya elverişli bir durum var demektir. Bu durumda nesneyi sıfırdan oluşturmak yerine, arzu ettiğiniz durumda olan bir nesneyi kopyalayarak elde etmek daha kolay olur. Bu da Prototype kalıbıdır.

Yukarıdaki alternatiflerle ilgili şunlar söylenebilir:

  • Nesneleri daima bu işe hasredilmiş üretici (factory) sınıflarında oluşturun. Oluşturulacak nesneler birbirleriyle ilgili değillerse, her birisi için bir Factory Method kullanın, yok nesneler bir arada kullanılıyor ve muhtemelen de beraber oluşturuluyorsa, bu durumda nesne ailelerinden bahsediliyor demektir ve bunun için Abstract Factory‘i kullanın.
  • Factory Method, AbstractFactory‘nin tek nesne için olan halidir. Dolayısıyla Abstract Factory, Factory Method‘u kullanır. (Aslen her iki kalıp da Factory isimli genel kalıbın altında ele alınmalıdır.)
  • Factory Method (dolayısıyla da AbstractFactory), nesne oluşturmak için Builder ya da Prototype kalıplarını kullanabileceği gibi, nesneyi yaratmak için kurucu cağrısı, JavaBean yöntemini ya da Bloch’ın statik factory metotlarını da tercih edebilir.
  • Belki garip gelecek ama yukarıdakinin tersine, Builder da Factory Method‘u (dolayısıyla da AbstractFactory) kullanabilir çünkü nesneyi inşa sürecinde muhtemelen pek çok, esas nesnenin ihtiyacı olan diğer, muhtemelen farklı türlerden nesneler de oluşturulacaktır. Benzer şekilde esas nesnenin inşa sürecinde gerekli diğer nesnelerin yaratılması için, kurucu cağrısı, JavaBean modeli ya da Bloch’ın statik factory metotları da kullanılabilir.

Aşağıdaki şekil, yukarıda anlatılan seçenekleri ve kalıplar arasındaki ilişkileri özetlemektedir.

Creational Patterns

 

Bu yazıda nesne yaratmayla ilgili hem kalıpları hem de klasik diğer yolları ve Bloch’un önerisini ve aralarındaki ilişkileri ele aldık. Bu şekilde konu ile ilgili büyük resmi görmeye ve daha analitik bir anlayışa sahip olmaya çalıştık.

 

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

Yazılımı Anlamak Üzerine

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

C++’ın babası olan Bjarne Stroustrup, “The C++ Programming Language” isimli kitabında şöyle der: “Design and programming are human activities; forget that and all is lost.” ya da Türkçesiyle: “Tasarım ve programlama insani işlerdir; bunu unutun, herşey kaybolur. ”

Ben bu cümleyi eskiden bu yana şöyle anlıyorum: Yazılımı tasarlamak olsun, programlamak olsun, öyle uzaylıların yaptıkları işler değildir, tamamen insani faaliyetlerdir, fırıncının ekmeğini yapması gibi ya da futbolcunun futbolunu oynaması ya da bir öğretmenin öğrencilerini eğitmesi gibi, doğrusuyla, yanlışıyla, tamamen insan ve tabi çevresinin işin içinde olduğu faaliyetlerdendir. Eğer bu geçeği unutursak, yazılımı geliştirmeyi, elit, ayrık yani doğal insani ortamından koparılmış gibi ele alırsak, ortada yazılım falan kalmaz. Nitekim üstad bu cümleyi şöyle bir paragrafta söylüyor:

“Too often, we forget the human aspects of system building and consider the software development process as simply ‘‘a series of welldefined steps, each performing specific actions on inputs according to predefined rules to produce the desired outputs.’’ The very language used conceals the human involvement! Design and programming are human activities; forget that and all is lost.”

Yani

“Çok sıklıkla, sistem inşa etmenin insani taraflarını unutuyoruz ve yazılım geliştirmeyi “önceden tanımlanmış kurallara göre girilen verilerden istenen çıktıları üretmek için özel işlemleri yapacak şekilde kurgulanmış, her biri iyi tanımlanmış adımlardan oluşan bir seri” gibi düşünüyoruz. Kullanılan programlama dilinin kendisi, insanın katkısını saklıyor. Tasarım ve programlama insani işlerdir; bunu unutun, herşey kaybolur.”

Evet yazılımı tasarlarken ya da geliştirirken, fildişi kulelerde, her türlü şeyin düşünüldüğü, son derece formal ortamlarda çalışmıyoruz biz. Bakkal Hasan amcanın kendi ortamında bir problemi çözerken kullandığı araçlar ve yöntemlere benzer şeyler kullanıyoruz biz de. Durum Amerikan filmlerinde gördüğümüz şu cümleyle de güzel bir şekilde açıklanabilir: “It is not rocket science!”

Stroustrup’un yukarıdaki paragraftaki şu cümlesi bizim yazılıma sanki uzaydan gelme bir şeymiş, rocket sciencemış gibi davranmamızın sebebini açıklıyor sanırım: “Kullanılan programlama dilinin kendisi, insanın katkısını saklıyor.” Yani kullandığımız programlama dilleri, araçlar, sistemler vs. aşırı karmaşık ve matematiksel yapısından dolayı olayı yani yazılım geliştirmeyi, mistik, kaotik ve esoterik, sadece ehlinin anlayacağı bir iş, olarak görmemize, kurgulamamıza ve dışarıya yansıtmamıza sebep oluyor. Yani yazılımcılar olarak bizler sanki sabah akşam kapalı kapılar ardında, orta çağın büyücüleri gibi, başkalarının gördüğünde “vuuuuuuu, çok etkilendiiimmm” cinsinden laflar söyleyeceği işler yapıyoruz. Halbuki üstad diyor ki, bu bir yanlış anlamadır, kullandığımız dil vb. araçlar böyle bir algı oluşturabilir ama bu yanlıştır. Her insani faaliyet gibi yazılım geliştirme de son derece insanidir. Örneğin şunu diyor Stroustrup:

“…

–  There are no ‘‘cookbook’’ methods that can replace intelligence, experience, and good taste in design and programming.

–  Experimentation is essential for all nontrivial software development.

…

It is easy –  and typically expensive –  to underestimate any of these points. It is hard to transform the abstract ideas they embody into practice. The need for experience should be noted. Like boat building, bicycling, and programming, design is not a skill that can be mastered through theoretical study alone.”

Yani

“…

–  Tasarım ve programlamada insan zekası, tecrübesi ve estetiğinin yerine geçebilecek hiç bir reçete metot yoktur.

–  Deneme – yanılma, basit olmayan her yazılım projesi için asıldır.

…

Bu noktaları gözden kaçırmak kolaydır ve sıklıkla pahalıdır. Soyut fikirleri pratiğe dökmek zordur. Tecrübeye olan ihtiyacımıza dikkat edilmelidir. Gemi inşa etme, bisiklete binme ve programlama gibi tasarım da sadece teorik çalışmayla elde edilebilecek bir yetkinlik değildir.”

Peki neden durup dururken bunlardan bahsediyorum ki? Yazılım ile ilgili olarak çalışırken, tasarlarken ya da programlarken sıklıkla, bağlamımızı aşırı soyut tuttuğumuzu ve bu durumun da problemi anlamakta dolayısıyla da doğru düzgün bir çözüm üretmekte bize sıkıntı çıkardığını görüyorum. Eğer problemimizi bir insani durumun sonucu olarak ele alıp, daha anlaşılır bir ifadeyle, problemimizi yeryüzüne indirip, tamamen günlük hayattan figürlerle ifade edemediğimizde, durumu anlamakta ciddi bir sıkıntıya girdiğimizi hatta doğrudan problemi ıskaladığımızı düşünüyorum.

Ne demek istediğimi size bir örnekle açıklayayım: Yazılımla alakalı kavramları ya da teknikleri anlatırken, bu kavram ve teknikleri ne kadar örneğin benimle çevremdeki insanlar arasındaki ilişkiler ya da iyi bilinen bir filmde resmedilmiş ve akılda kalmış sahne cinsinden ifade edebilirsem, insanların beni o kadar rahat anladıklarını görüyorum. Daha anlaşılır şekilde örneğin, sıklıkla tasarım kalıplarını (design patterns) hem anlatma hem de uygulama durumunda kalıyorum, eğitimlerde ya da danışmanlıklarda. Proxy (vekil) tasarım kalıbını ele alalım mesela. Bu kalıbı, tamamen yazılım kavramları üzerinden anlatmaya çalıştığımda, insanların, yazılımcıların yani, anlar gibi görünmelerine rağmen, gerçekte anlamadıklarını farkediyorum. Nasıl anlıyorum bunu? Onlara bir problem verip bunu az önce anlattığım proxy kalıbıyla çözmelerini istediğimde, yazılımcıların yarısından fazlası çözmekte zorlanıyor. Ama aynı kalıbı buradaki örnekte olduğu gibi, başbakan ve vatandaşlar cinsinden anlattığımda ise aynı kişilerin daha başarılı bir şekilde bu çözümü yeni durumlara uygulayabildiklerini farkettim. Bu durum Stroustrup’un şu cümlesiyle daha rahat anlaşılabilir: “Soyut fikirleri pratiğe dökmek zordur. Tecrübeye olan ihtiyacımıza dikkat edilmelidir. Gemi inşa etme, bisiklete binme ve programlama gibi tasarım da sadece teorik çalışmayla elde edilebilecek bir yetkinlik değildir.”

Evet yazılım soyuttur ama neticede bu dünyadandır ve zihnimizin “benzerlikler üzerinden çalışma” yeteneğinden faydalanarak, soyut olan yapıları somut, elle tutulan ve gözle görülenler cinsinden ifade ederek, daha insani boyuta indirgeyebiliriz. Çünkü proxy tasarım kalıbının çözdüğü şey ile bir insanın bir başka insana örneğin bir avukata vekalet vererek çözdüğü aslında aynı şeydir, aynı problemdir. Tıpkı, visitor (ziyaretçi) kalıbının çözdüğü problemin, örneğin bir evdeki kişilerin hepsinin ayrı ayrı terziye giderek ölçü verip elbise diktirmeye kalkmalarının yarattığı enerji kaybı ve bürokrasiyi ortadan kaldırmak amacıyla, terziyi eve çağırmalarıyla aynı olması gibi.

Tüm bu “insani” yaklaşımlar, problemin kendisini anlamaya yönelik çalışmalardır. Yazılımın soyut bir yapıda olması, yazılımı anlamak ve çözümlemek için tamamen soyut yapılardan hareket etmemizi gerektirmez. En azından problemi tanımlayıncaya ve ona her boyutuyla hakim oluncaya kadar, problemi soyut düzlemden somut ve insani düzleme çekebiliriz. Böyle bir yaklaşım bize daha aşina olduğumuz bir zeminde hareket etme kabiliyeti vereceği gibi “Deneme – yanılma, basit olmayan her yazılım projesi için asıldır.” şeklindeki prensipleri, hem yazılıcıların hem de yöneticilerinin anlamalarını sağlayacaktır.

Üstadlardan öğreneceğimiz çok şey var.

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

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

1 2