Kalıp

Kod Analizi: Kurucu Kullanımı

Java , , , ,

Danışmanlık verdiğim yerlerde her zaman farklı yaklaşımlarla yazılmış kodlar görüyorum. Bu tür kodların ufkumu açtığında şüphe yok. Ama açıkçası her ufuk açmanın iyiye ve güzele doğru olduğunu söylemek zor.

Aşağıdaki kod da bu şekilde karşılaştığım kodlardan. Tabi ki ciddi miktarda kamufle edilmiş isimler içeriyor. Ama koddaki yaklaşım, arka taraftaki düşünce vs. tamamen korunmuş durumda. Kod şöyle:

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

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

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

	user.setStatus(JTConstants.PENDING);

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

    return user;
}

Bu metodu analiz etmek istersek, hem nesne-merkezli programlama hem de temiz kod gibi noktalardan inceleyebiliriz. Önce şekilden başlayıp sonra kodu yazanların sahip oldukları, en azından koda yansıttıkları anlayışa doğru gidebiliriz. Bu yüzden önce isimlerden başlayalım.

Mekanı kullanma

Yukarıdaki kodda düzgün olan nedir diye sorsam, olsa olsa “sadece paragraflar” denebilir çünkü isimlendirme bile problemli. Ama açıkçası bir kodun paragraflandırılmış olması, yani bir geliştirme aracının iki-üç tuşa basımlık bir işini meziyet olarak ortaya koymak mümkün değil. Öte taraftan JTUser kurucu ve insert metot çağrılarının, kodda hüküm süren yaklaşımdan dolayı mekanı zorunlu olarak iyi kullanamadıkları da bir gerçek.

İsimlendirme

Çoğu zaman kodu yazanların kafalarındaki karmaşıklığı verdikleri isimlerden çıkarabilirsiniz. Bu kod parçasında da execute ve executeInner metotları, bu metotları yazanların kafalarındaki karmaşıklığa bir örnektir. Biraz empati yapıp, execute metodunun Command tasarım kalıbından esinlendiği düşünülebilir. Bu durumda daha geniş bağlama bakıp hakikatten bu kalıbın kullanıp kullanılmadığına karar verilebilir. Diyelim ki Command kalıbı kullanıldı ve bu metodun bulunduğu sınıf, kalıptaki arayüzü gerçekleştiriyor ve bu yüzden metodun ismi, Command kalıbının geleneğine bağlı kalınarak execute olarak verilmiş olsun. Peki executeInner‘ı ne yapacağız? executeInner metodunun içinden çağrılan metotların isimlerini tahmin edebilir miyiz? executeIpInner, executeDahaDaInner ya da executeInner2 diye gidebilir 🙂  Bu kadar kötü ve ezbere bir isimlendirme olursa, daha fazla düşünce ve tecrübe gerektiren, daha zorlu algoritmik ve modelleme problemlerinde nasıl bir yaklaşım olabilir, tahmin etmek zor değil.

Bir diğer isimlendirme problemi de authenticateFastRegisterUser metodu için söz konusu. Bu metot hali hazırda sisteme kayıtlı olan kullanıcının hızlı olarak sisteme girmesini sağlıyor gibi duruyor. Bu durumda metot isminin authenticateFastRegisteredUser olması gerekirdi.

Yaklaşım

Bu kod parçasında temelde JTUser oluşturulup executeInner‘a geçiliyor ve dönen değer true olduğunda göre  audit bilgisi AuditLog nesnesi olarak oluşturulup, veri tabanına gönderiliyor ve user sisteme dahil ediliyor. Bu işler olurken kodda göze batan iki yer var, iki nesnenin oluşturulması. Bu iki nesne için tabi olarak ikş kurucu çağrısı yapılıyor ve bu çağrılar o kadar kötü kurgulanmış ki insan hayret ediyor. Şu çağrıya bakın örneğin:

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

Bir kurucuya neden nesneyi doğrudan geçmek yerine parçalarını ayrı ayrı geçersiniz ki? Bu kurucuya form nesnesinin email, name, surname ve welcomeMessage alanları ayrı ayrı geçiliyor. Aslen sadece form nesnesinin geçilmesi gerekirdi. Bu durum nesne-merkezli programlamanın pek özümsenmediğini açıkça gösteriyor.

Öte taraftan, bir metoda neden new Date() ile o anki zamanı geçersiniz? İki şeyden dolayı, ya geçilen yerde o anki zamana ulaşamıyorsunuzdur,  yani kurucuda new Date() yazamıyorsunuzdur :), ya da o kadar ince hesaplarla çalışıyorsunuzdur ki, önemli olan execute metodundaki zamandır, bir nano saniye sonra JTUser kurucusundaki an işinize yaramıyordur 🙂 Açık ki burada bu iki durum da söz konusu değildir.

Başka ne gibi problemler var bu kurucu çağrısında? null geçilmesi problemdir. Üç parametre null olarak geçiliyor ve muhtemelen başka yerlerdeki aynı kurucu çağrısında null geçilmiyordur. Bu durumda da kurucuda devamlı null kontrolü yapılmalıdır. Aslen hep null geçiliyorsa bu daha büyük bir problemdir çünkü bu o nesnenin zaten bu kurucuya hiç geçilmemesi gerektiğini gösterir. Yok ilk durum geçerliyse yani bazen null geçiliyor bazen de değer geçiliyorsa bu zaten sıkıntılı bir yapı ortaya koyar çünkü null geçmek ya da null döndürmek hataya sebebiyet verir.

Kurucuya geçilen diğer üç parametre yani uid, salt, accountId, de geçilmemelidir çünkü bu üç değer zaten Utils sınıfından statik metotlarla alınabilir. Ne farkeder ki, ha orada ha burada demeyin, en az parametre geçecek şekilde kod yazmamız gerekli. Aksi taktirde bağımlılıkları gereksiz yere arttırmış oluyoruz.

Geriye bu kurucuya geçilen yedi tane true parametresi kalıyor. Bu parametreler belli ki JTUser nesnesinin belli bir durumda (state) oluşmasını sağlıyorlar. Ama bir nesnenin durumunda yedi tane boolean değişken yer alması biraz garip değil mi? Bu yedi değişken toplamda 2^7 = 128 farklı durumu temsil eder. Bu durumda JTUser nesnesinin en az 128 farklı hali var demektir. Örneğin yeni kayıt olmuş ama henüz teyit edilmemiş kullanıcı, yeni kayıt olmuş ve teyit edilmiş kullanıcı, vs. diye gidebilir. Problem şu: Her ne kadar biz metotları, onlara az parametre geçilecek şekilde tasarlayalım desek de kurucularda böyle yapmak imkansızdır. Yani kurucular nihayetinde oluşturdukları nesnelerin durumlarından sorumlu oldukları için genelde çok sayıda parametre alırlar. Bu türden kuruculara, parametrelerden dolayı uzun olduklarını ifade etmek için “teleskopik” denir. Biz yukarıda saydığımız sıkıntıları giderecek şekilde kodu tekrar yazsak bile kurucular hala çok parametre alır halde kalırlar. Örneğin JTUser kurucusunun 20 olan parametre sayısını 8’e indirmiş oluruz, ve bu hale gelir:

	JTUser user = new JTUser(form, true, true, true, true, true, true, true);

Garip değil mi? Garip olan şey bu kurucu metodun uzunluğu değil, çağrılmasındaki zorluk. Yedi tane arka arkaya gelen boolean parametrenin hangisinin ne olduğunu ve ne işe yaradığını bilmeniz gerekli. Muhtemelen bu kurucu metot şöyle tanımlanmıştır:

...

public JTUser(Form form, boolean verified, boolean authorized, boolean authenticated, ...){
   ...
}

...

Çok fazla sayıda parametre içeren metot yazmanın kaçınılmaz sonuçlarından birisidir bu durum. Normal metotlarda, metotları bölüp parçalayarak, sadece br işe odaklar hale getirip  bu durumdan kaçınabiliriz. Fakat metotların ismi olmasına karşın kurucuların ayırt edici isimleri yoktur. Ve özellikle de karmaşık nesnelerde hem pek çok kurucu vardır ama hangisinin, hem de kurucuların kendileri uzundur. Dolayısıyla hangi kurucunun çağrılacağı ve hangi parametrelerin geçileceği, zaman alan bir kodlama gerektirir ve hataya çok açıktır. Öyleyse kurucularda bu durumdan nasıl kaçınılabilinir?

Aslında bunun bir kaç yöntemi var. Örneğin yaratımsal (creational) kalıpları kullanmak. Ama nasıl bir çözüm önerilirse önerilsin yapılması gereken en temel şey, geçilen boolean parametreleri ortadan kaldırıp ya da en azından azaltıp, parametrenin rolünü metodun isminde ifade edecek şekilde kurgulanmış isimlere sahip, nesne oluşturan, gerekirse uzun isimli ama anlamlı metotlar yazmak. Eğer bu metotları ayrı bir sınıfta yazarsanız üretici metot (factory method) kalıbına varırsınız. Bu durumda bu sınıf şöyle olacaktır:

public class JTUserFactory{
	
	public JTUser produceVerifiedJTUser(...){ ... }

	public JTUser produceVerifiedJTUserUsingForm(Form form, ...){ ... }

	public JTUser produceVerifiedAndAuthorizedJTUserUsingForm(Form form, ...){ ... }

	...
}

(Üretici metot (factory method ) kalıbı için buraya bakabilirsiniz.)

Benzer ama bir başka çözüm, J. Bloch “Effective Java 2nd Ed.” isimli kitabının ilk maddesinde ifade edilmiştir. Burada tekli edilen şey, sınıfta kurucu kullanmak yerine statik factory metotlarının kullanılmasıdır. Yani yukarıdaki metotların statik olarak JTUser sınıfında olduğu durumdur. Ayrıca gerekirse bu metotları kullanmak için JTUser‘ın tüm kurucuları private yapılabilir.

Böyle bir yol izlendiğinde yukarıdaki kodumuz şu hale gelecektir:

public void authenticateUser(RegistrationForm registrationForm, 
                             HttpServletRequest request, 
                             Locale locale) throws JVTException {

   JVTUser user = JVTUser.createUnauthenticatedUser(registrationForm);

   if(authenticateUserUsingForm(registrationForm, locale, user)){
           
      authenticateFastRegisterUser(registrationForm, request);    
      
      mailSender.sendMail(user, locale);

      auditLogDao.insert(
          AuditLog.createAuditLogForUserAuthentication(user));
   }
}

Bu kodda, JTUser ve AuditLog sınıfları statik üretici metotlara sahip olacak şekilde kurgulandıklarından, nesnelerini oluşturmak createUnauthenticatedUser ya da createAuditLogForUserAuthentication gibi metotlarla çok daha rahat hale gelmiştir.

Kodun ilk halinin en berbat tarafı, sadece kötü yazılmış olması değildir. Çoğu zaman bu kodun sadece böyle yazılmış olmasına odaklanır esas problemi gözden kaçırırız. İlk haldeki gibi yazılmış karmaşık kodlar, copy-paste ile her yere dağılır. Her JTUser nesnesine ihtiyacı olan bu ve buna benzer kurucu çağrılarını, çağrıyı yapmak zor olduğundan, haklı olarak copy-paste ile alıp kullanma eğiliminde olur. Bu da bakımı çok zor bir kod yapısına götürür. Eğer bu çağrıyı yapmak için copy-paste’e başvuracak kişi, biraz akıllıca davranıp, yukarıda bahsedilen yollardan birisiyle, cut-paste kullanarak bu kodu iyileştirse (refactoring) idi çok güzel bir şey yapmış olurdu ve bu kod yapısı da iyileşerek büyürdü.

Burada kurucular üzerinden bir kod analizi yaparak nasıl daha temiz, nesne-merkezli ve bakımlanabilecek kod yazılabileceğini ele aldık. Ve yine temiz kod için iyileştirmeye (refactoring) ihtiyacımız oldu.

Rahat bakımlanabilir kodlar yazmak dileğiyle 🙂

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

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

“Java Kodunuzun Nesne Merkezli Olmadıgının 10 İşareti” Seminerinin Videosu

Java, Kültür, Bilgi ve Düşünce, Yazılım Modelleme , , ,

24 Ekim 2014’de Netaş’ta verdiğim “Java Kodunuzun Nesne Merkezli Olmadıgının 10 İşareti” seminerinin amatörce çektiğim videosuna buradan ulaşabilirsiniz. Bu seminerin sunumuna da buradan ulaşabilirsiniz. Beğenmenizi umuyor, yorumlarınızı da bekliyorum..

Malum ben bu türden seminerleri davet üzerine ve bedelsiz olarak veriyorum. 2 saati geçmeyecek şekilde, hem bilgilendirici hem de eğlendirici tarzda hazırlayıp verdiğim bu seminerlerle ilgili bilgilere blogumdaki “Seminerler” sayfasından ulaşabilirsiniz.

İyi seyirler.

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

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

1 2