October 27

Uzaklar Hiç Yakın Olmadı Bu Kadar

Düzen içinde yaşıyoruz. Kainatın her bir zerresi kocaman bir yapbozun birer parçası hükmünde. Bütünün güzelliği kendisini oluşturan bu küçük parçaların bir araya gelmesiyle görülebiliyor… Hayır! Vazgeçtim. Bu laf bile anlatmıyor hayran bırakan bu yapıyı. Her bir parça kendi içinde ayrı bir mükemmellik ve bütünlük içeriyor. Kısacası herşey kendisini oluşturan parçalarının güzelliklerini gösterdiği gibi kendisinin içinde olduğu ayrı bir bütünlüğünde güzelliğini ve muhteşemliğini haykırıyor aleme. Belki şimdi biraz daha fazla yaklaşmış olabiliriz anlatılamayana. Her bir zerre öyle özenle konmuşturki hem kral olmuştur hemde köle bu düzende.Hayran edici hesaplamaların bir parçasıyız ve insanın hayret edip iç aleminin buna kayıtsız kalması için ruhunu ve zihnini saran gaflet perdelerinin ummanlar kadar olması lazım. Sebeplerin acziyet dünyasında hayatta hiç görmeyeceğimiz milyar ışık yılı ötede bir yıldızın en ufak bir tozu “Ben yoksam sizde yoksunuz!” diye haykırıyor ötelerden. Bu sesi duyanların ruhlarında varlığa hayat üfleyen o kutsi Nefes beliriyor tüm ihtişamı ile. Hal dilleri daha bir gür bağırıyor susmak bilmeyen ağızlardan çıkan nidalardan.

Bu kadar grift herşey herşeyin içinde. Sadece varlıklar değil parçası bu kocaman yapbozun. Davranışlarda var. Yaptıklarımızın etrafında tavaf ediyor kainat tüm azameti ile. Birde bu acz içinde kainatı tavaf ettiren bir Halık-ı Mutlak kapıyor benlik kokan çeneleri. Bunca bulmacalar içinde insan soruyor kendine: Kainatta yaptığım ufak bir şey ya nice infiallere sebep olduysa?

Paylaş herkes duysun!Share on Google+Share on LinkedInTweet about this on TwitterShare on Facebook
October 25

S.O.L.I.D Üzerine Düşünceler (Part 2)

Daha önceden başladığım SOLID üzerine düşünceler ilgili serimin ikinci kısmına geldik. Eğer 1. kısmı okumadıysanız o zaman önce onu okumanızı tavsiye ederim. Bu makalede ise Open Closed Principle’i üzerinden devam edeceğiz. İdeal dünyada yazmış olduğumuz kodu asla değiştirmek zorunda kalmamış olmamız gerekiyor. Tabi böyle bir dünya yok ama en azından buna benzer bir dünyayı oluşturmak için bir prensip var ve buda Open Closed Principle. Kısacası öyle bir kod yazmalıyım ki daha önce yazdığım kodu değiştirmeden onun daha iyileştirebilmeliyim şeklinde tanımlayabiliriz. Daha resmi tabiri ile bir sınıf değişiklik için kapalı ama genişletilmek için açık olmalıdır. Tamam bu resmi olan tanımlama çok da bir mana ifade etmiyor gibi eğer daha önce Open/Closed Prensibi hakkında bir çalışmada bulunmadıysanız. Başka bir açıdan bakınca da yazmış olduğunuz sınıf yani classı asla değiştirmememilisiniz. Bir kere yazılınca artık o sınıf için değişim bitmiştir. Onun yerine o class’ı başka bir şekilde extend etmeniz yani genişletmeniz gerekiyor eğer gereksinimler değişirse. Open/Closed Prensibini uygulayabilmek için birden fazla yöntem var:

  1. Basit kalıtım. Yani bildiğimiz basit bir sınıfı kalıtım alarak onun methodlarını override etmek yada yeni methodlar eklemek şeklinde yapılan bir genişletme.
  2. abstract yada interface kullanarak kalıtım. Bu biraz daha göze ve mantığa hoş duran bir yaklaşım. Polymorphism burada çok yardımcı oluyor.
  3. Tasarım Desenleri yani Design Patterns kullanmak. Bunu çok yerde duymamış olabilirsiniz. Ama üzerinde düşününce OCP için gayet uygun patternlar var mesela Strategy Pattern, Decorator gibi. Bunlar var olan sınıfların içine dokunmadan yeni özellikler eklenmesini sağlıyorlar. Şahsen bunları diğer ikisine tercih ederdim. Çünkü compositon, inheritancedan daha güzel bir concept. Daha çok kod kullanabilirliği sağlıyor. Ama konumuz inheritance ve composition arasında ki farklar olmadığında es geçiyorum.

Şimdi basit bir koda bakalım:

Ben bu kodu C# ile yazdım ama prensip olarak başka dillerde kullanabilirsiniz. Şimdi PersonProcessor diye bir sınıfım var. Bu sınıfımın ne yaptığını açıklamay gerek yok ama bu sınıfı bir kez yazdıktan sonra artık bununla işim bitmiştir. GetAge method’u şuan database’den person nesnesini alıyor ama diyelim ki yeni bir gereksinim geldi ve bu sefer başka bir web server’dan person nesnesini almamız gerekti. Şimdi akla şu fikir gelebilir. Hemen GetAge method’unun içeriğini değiştiririm ve database’den almasını siler onun yerine web service’dan almasını sağlarım. Eğer böyle yaparsanız Open Closed Principle’ını (OCP) ihlal etmiş olursunuz. Bu arada bundan sonra kısaltması olan OCP’yi kullanacağım. Bu sorunu aşağıda tanımladığımz yöntemler ile aşmak mümkün.

Basit Kalıtım Yöntemi ile OCP

Başka bir sınıf oluşturursunuz ve bunun PersonProcessor ‘i extend etmesini sağlayabilir ve GetAge methodunu override edersiniz. Aşağıda ki kod buna bir örnektir:

Yukarıda görülen kod örneğini için çok açıklama yapmaya gerek yok diyerek geçiyorum. Burada değinmek istediğim iki şey var. Diyebilirsiniz ki MyClass içinde ki GetAge methodunu değiştirdin aslında. virtual eklemişsin ona. Doğru ve yaptığım normalde OCP ye göre yanlış. Ama dediğim gibi ben bu prensipleri önemli görsemde dogmatik olmak isteyen bir insan değilim. Pragmatik olarak yaklaşmak lazım. Eğer virtual kullanmasam override edemeyecektim ve virtual kullanmak bana zarar vermiyor ve hatta işime yarıyorsada kullanırım. Java gibi değil maalesef. Javada tüm methodlar default olarak virtual olduklarından dolayı virtual keyword’u kullanmaya gerek kalmadan override edebilirsiniz. Ama yok illada dogmatik yaklaşmak yani prensip içinde tanımlanan adımların ve kuralların dışına çıkmak istemiyorum diyorsanız o zaman da MyClass sınıfını tanımlarken hangi method’u virtual hangisini de sealed yapmak istediğinize karar vermek zorundasınız burası ayrı. Diğer bir mesele ise şimdi rahatlıkla MyClass sınıfını bozmadan onun yerine WebServerMyClass tipini kullanacak olmam. Ama açıkcası kabul edelim bu yöntem çok da güzel durmuyor. Zaten Meyer yöntemi deniyor yukarıda kullandığım kalıtım şekline. Meyer şahsın soy adı ve herhalde onun olduğu zamanlarda diller çok gelişmediğindenmidir nedir daha ilkel bir çözüm gibi duruyor. Ama prensip olarak bakarsak güzel bir prensip.

Abstract ve Interface Kullanarak Kalıtım

Şimdi başka yöntemlerde var bunu başarmak için. Burada dikkat edilmesi gereken şey prensibinin kendisi. Siz daha farklı kod yapıları ile bu prensibe uyuyorsanız illada yukarıda ki kod yapısını takip etmek zorunda değilsiniz. Mesela abstract bir sınıf kullanabilirsiniz, yada bir interface ve bunların kalıtım alınmalarını zorunlu hale getirebilirsiniz. Öyle olunca eğer sınıfınız istediğinizi karşılamaz ise hemen başka bir sınıf oluşturup yolunuza devam edebilirsiniz. Basit bir kod örneği olması açısında yukarıda ki örnekleri biraz değiştirdim:

Böyle olunca WebserverClass ‘ı değiştirmek yerine IMyClass ‘dan hemen inherit alıp başka bir sınıf oluşturabilir ve artık onu kullanabilirsiniz.

Tasarım Desenleri ile OCP

Hatta eğer yukarıda ki örneklerden farklı şekilde tasarım desenleri yani Design Pattern’ları da kullanabilirsiniz. Mesela Strategy ve Decorator vs. gibi pattern’lar var olan sınıfların içeriklerini değiştirmeden onları üzerinde bir genişletme yapmanızı sağlıyorlar. Bence bunlar daha mantıklı olabilir çoğu durum için. Aşağıda ki örnek kendisini açık bir şekilde açıklıyor onun için ben açıklamasına girmeyeceğim ama Strategy Pattern nasıl çalışıyor diye bakmak isterseniz eğer:

Yukarıda ki kod örneğini http://www.dofactory.com/net/strategy-design-pattern adresinden aldım. Bu pattern’i daha iyi anlamak istiyorsanız o adrese bakabilirsiniz.

Faydaları

Şimdi bunca bilgiden sonra OCP’nin ne yararı var diye sorabilirsiniz. Kısaca açıklarsak OCP ile var olan kodları değiştirirek başka bug’lara sebep olmayı önlemek istenmiş. En azından bu prensibin kurucu Bertrand Meyer bu şekilde düşünmüş. Tabi her hali ile mükemmel bir prensib mi bu tartışılabilinir ama sonuçta ortaya çıkış amacında faydalı bir hedefi var ve mümkün mertebe kullanılmasında bence gayet faydalı olacaktır. Ama şimdi Unit Test denilen testing framework’ları var. Yani test yazdıktan sonra var olan sınıflarınızı değiştirseniz bile bu testler sayesinde yeni bir hataya meydan verip vermediğiniz daha hızlı bir şekilde anlaşılabilinir çoğu zaman. Ama risk her zaman vardır unit test kullanıyor olsanız bile. Onun için prensib biraz daha eğer çalışıyorsa dokunma! mantığı üzerine kurulu.

Bu prensiblerin başka bir faydasıda insanı tembel bir programcı olmaktan kurtarıyor olmaları. Yazdıkları kod üzerinde düşünen bir programcı olmanız için bu tarz prensibler size yol gösterecektir. Çok uzun bir makale oldu şimdiden herkesten özür dilerim.

Bu arada makalede yanlışlıklar olmuş olabilir yada eksikler. Ara sıra gözüme çarpınca düzeltmeye çalışıyorum.

 

 

Paylaş herkes duysun!Share on Google+Share on LinkedInTweet about this on TwitterShare on Facebook
October 24

JSP ile Servlet Arasında ki Fark

İş yerinde JSP kullanmaya başladığımı söylemiştim. Java ile Android üzerinde tecrübem oldu. Ama JSP üzerinde daha önce çalışma şansım olmamıştı. Onun için bazı şeyleri araştırmam gerekti diyebilirim. Ama servlet ile JSP arasında kalmışken bunları aralarında ki farkın ne olduğunu anlamak için yaptığım araştırmalar genelde hep eksik sonuçlar dönderdi. Aralarında ki farkı anlatan makale ve cevaplar en temel meseleleri eksik geçiyorlardı. Bende bu temel meseleleride hesaba katarak bu aralarında ki farkdan bahsedeceğim.

Servlet

Öncelikle servlet nedir diye araştırdığınızda genelde abartılı ifadeler ile anlatıldığını göreceksiniz. Hatta Java Programming Interface diye abartarak anlatan makaleler gördüm devamlı. Kısacası servlet denilen şey bir class. Evet sadece bir class. Ama uzantısı .class olan dosyadan bahsetmiyorum. Hoş compile edildikten sonra .java uzantılı dosyalarda .class uzantılı byte code içeren dosyalar hale geliyorlar. Ama benim burada bahsettiğim class ise .java uzantılı dosyada bulunan public class MyServlet  şeklinde olan class’lar. Ama bir fark var, o da HttpServlet  denilen ve abstract  olan bir sınıfı extend yani kalıtım almaları. Evet servlet dediğimiz şey bu kadar basit. Eğer C# dan gelen insanlar iseniz aslında Asp.NET MVC içinde bulunan Controller  sınıflarına çok benziyorlar. Java’da Annotation’lar var. Bunlar C# da Attribute’lar ile aynı işi yapıyorlar. Bu neden dedim çünkü mesela www.mywebsite.com/helloworld isimli bir adrese gittiğinizde burada helloworld’un HelloServlet  isimli dosyaya gitmesini istiyorsanız o zaman aşağıda ki koda benzer bir kod yazmanız gerekecek:

Burada @WebServlet  kodu annotation. Ama dikkat ederseniz urlPatterns  diye bir parametre alıyor. İşte bu parametrede belirttiğimiz ise URL kımsında yazdığımız adres. Kodun diğer kısımları anlışılır olsa gerek. Çünkü servletlari baştan aşağı anlatmaya kalksam herhalde bir makale bu işe yetmeyecektir ki daha JSP kısmınıda anlatacağım. Kısacası servlet denilen şey işte bu yukarıda ki kod. doGet  methodu gözünüze çarpmıştır. O da GET request’ini handle etmek için daha önceden tanımlanmış bir method ve HttpServlet  super yada base class’ından geliyor ve override ediliyor. Herhalde temel olarak servlet denilen şey anlaşılmıştır.

JSP

Şimdi gelelim JSP denilen ve dosya uzantıları .jsp ile biten meseleye. JSP aslında daha özelleşmiş bir servlet. Yani uzantısı farklı olsada aslında .jsp dosyaları kullandığınız servlet container (bunuda izah edeceğim sonlara doğru) tarafından bildiğiniz .java uzantılı class’lara dönüştürülüyor ve dönüştürülen bu sınıflarda HttpServlet super class’ını extend ediyor. Olay bu kadar basit. Sonra bu dönüştürülen class’larda (yani .java uzantısı ile biten dosyalar) compile ediliyor ve .class uzantılı hale geliyorlar. Ve yukarıda servlet için anlattığım aynı processden geçiyorlar. Aşağıda JSP nasıl gözüküyor onu görebilirsiniz:

Fark aslında bu dosyalar içinde bulunan kod ve bu dosyalarda kullanabileceğiniz hazır sınıflar vs. Servlet denilince daha çok java sınıfı akla geliyor ama doğru olanı ise JSP de bir servlettir ama genelde JSP ile Servlet farklı olsun diye birbirlerinden farklı kullanılır. Şimdi kısacası şunu görüyoruz JSP: HTML kodu içinde Java kodu kullanılmasıdır. Servlet: Java kodu içinde HTML kodu kullanılmasıdır. JSP daha kolay bir tasarım şansı veriyor aslında. Hani Asp.NET Web Forms’a benziyor. Aynı HTML tasarımını servlet içinde yapmak bayağı uğraştırırdı. Aşağıda ki kod ise yukarıda ki JSP dosyasının .java hale çevrilmiş halinden alınmış küçük bir parça:

Evet görüldüğü gibi hiçte iç açıcı bir kod gözükmüyor yukarıda ki JSP kodunu .java dosyası içinde java kodu ile yazmış olsaydık. JSP bu noktada bazı özel tagler kullanmanıza yardımcı oluyor. Bunlar sayesinde daha dynamic HTML kodunuz olmuş oluyor. HTML içinde Java kodu çalıştırmış oluyorsunuz. Asp.NET Web Forms’da da aynı şey oluyordu. Yani sizi .aspx dosyalarınızda aynı şekilde compile edilirlerdi ve bildiğimiz class halini alırlardı.

Web Server, Application Server, Servlet Container

Şimdi başka önemli konuya gelmeden önce biraz da web server kısımlarından bahsedelim. Çok karmaşık olmasın diye bazı yerleri atlayabilirim. Servlet meselesinde web server kısmında iki mesele var. Bunlar Web Server ve Application Server. Örneğin Apache Httpd bir web server. Yani daha genel çalışan bir server, IIS gibi aynı. IIS de mesela static content yani .js yada .css gibi dosyaları rahatlıkla server edebilir ama daha dynamic content mesela Asp.NET gibi dosyaları serve edebilmesi için bu dosyaları anlayacak ve çalıştıracak başka modullere ihtiyaç duyar. Siz mesela bir Asp.NET dosyasını request ettiğinizde IIS bunu .NET’e gönderir çalıştırır ve sonucunu geriye dönderir. Java dünyasında ise bunu yapmak için Apache Httpd ve Tomcat kullanılır. Başkalarınıda kullanabilirsiniz. Ama ben örnek olarak bu ikisinden bahsedeceğim.

Apache Httpd dediğim gibi bir web server. Apache denilidiğinde Apache Httpd anlaşılır genelde. Eğer Java ile ilgili bir request gelirse bunu kendisine tanıttırılmış olan Tomcat’e yönlendirir. Tomcat ise bir Application Server ve servlet’leri çalıştırmak ve sonucu döndermeyi sağlar. Onun için Tomcat’e Servlet Container’de denir. Yani servlet’ları alır onları compile edilmesini sağlar, eğer istenilen adres bir JSP dosyasına gidiyorsa onun .java dosyasına transform edilmesini sonrada compile edilip .class dosyası olmasını sağlar. Buradan kısa bir not olarak illada Apache Httpd server’ına ihtiyacınız yok. Tomcat tek başınada yeterli olabilir ama okuduğum kadarı ile Tomcat Httpd kadar güçlü değil. Onun için Tomcat’i sadece Application Server yani Servlet’lerin çalıştırılması ve server edilmesi için kullanmayı tavsiye edenler var ama denemek lazım tabikide. Neyse devam edelim. Tomcat Instance’ları oluşturulmuş bu servlet’ların hayatlarını kontrol eder ve bunları çalıştırıp sonucu gerisin geri web server’a oradan da kullanıcıya döndürülmesini sağlar. Bu konu daha derin olabilir ama çok da fazla derine girmek istemiyorum. Son olarak ta Request ve Response nesnelerini oluşturulmasını ve bunların servlet’e parametre olarak gönderilimesini sağlar.

Bu meseleyi anlamak için Wikipedia sitesinden aldığım aşağıda ki resim yardımcı olacaktır:

JSPLife

 

Yukarıda ki resim bir JSP dosyasının hayat döngüsünden bahsediyor. Yukarıda anlattıklarım ile aynı. Ama burada bir fark var o da eğer JSP yada Servlet daha önce compile yani derlenmiş ise o zaman direk derlenmiş hali kullanılır. Bu sayede tekrardan derlenmek zorunda kalmaz. Ama eğer bu kaynak kod dosyalarında bir değişiklik olmuş ise bu değişiklikleri yansıması için derleme en başından yeniden yapılır.

Daha nice farklılıklar vardır. Ama benim amacım daha çok genel bir yaklaşım sunmak ve bu meseleye yeni başlayan kişiler için benim geçtiğim sıkıntıları yaşamamaları adına bir ön bilgi sunmak idi. Eğer bu işi ciddi olarak öğrenmek istiyorsanız o zaman yolun başındasınız demektir. Bende hala öğrenme sürecindeyim. Öğrendiklerimi sizler ile paylaşmaya devam edeceğim. Şimdiden herkese kolay gelsin.

 

Paylaş herkes duysun!Share on Google+Share on LinkedInTweet about this on TwitterShare on Facebook
October 23

Seçen ve Seçilen Münasebeti ve Toplumsal Doku

karakter1-2

Bir toplumda seçen ve seçilen insanlar arasında ki münasebet seçmek ve seçilmek meselesinden çok daha ötedir bence. Kısaca özetlemek gerekirse seçilen insanlar genelde seçen insanların ahlaki izdüşümleridir. Eğer bir toplumu anlamak isterseniz onları yöneten insanları anlamaya çalışarak başlamak en kestirme yollardan bir tanesidir. Bir toplumda yalan, iftira ve daha nice insanı kendisine bahşedilen makamdan daha aşağılara düşüren sıfatlar ve fiiller varsa, o toplumun seçilenleride kısacası siyasi yöneticilerinde de bu sorunların olması çoğu zaman kaçınılmazdır. Çünkü bu seçilen insanlarda aynı toplum içinden çıkmış ve bu toplumu şekillendiren sosyal etkiler altında büyümüşlerdir. Eğer siyasi bir lideri rahat bir şekilde devletin malını yerken görüyorsanız o toplumda aynı şeyi arzulayan çok insan rahatlıkla bulabilirsiniz. Maalesef dini yada evrensel insani değerler gibi ilkeleri olmayan siyasi liderler devlet malını kendi çıkarları için kullanıp keyiflerine baktıkları zaman genelde başlarında oldukları toplumun hayallerini yaşarlar. O toplumda bende başbakan olsam keşke diyerek hayallar kuran insanlar görebilirsiniz. Tabi bu hayal hizmet etme manasını taşımayan daha çok o makamın şan, şöhret ve rahatlık gibi zehirli meyvelerinin yemek istendiği bir hayalden başka bir şey değil.

Maalesef asıl derdi topluma bir şeyler kazandırmak olan dürüst insanlar çoğu zaman yöneticilik sevdası içinde bulunmazlar. Bulunmazlar çünkü içlerinde ki hakkaniyet duygusu yöneticilik makamının  kişisel zaaflara kurban edilemeyecek kadar büyük ve ağır olduğu bilincini taşıyordur. Eğer dindar bir insansanız o zaman ahirette vereceğiniz hesaptan dolayı korkar ve bunca insanın hakkına girme potansiyeli olan bir makamın acısını her daim yaşarsınız. Eğer evrensel insani değerlere sahip ve saygılı bir insansanız o zaman da mahşeri vicdan da nasıl bir konumda olacağınız endişesi kaplar sizi.

Olayı biraz dağıtmak adına başımdan geçen bir olayı anlatayım. Geçen yaz Türkiye ye ziyarete gittim. Bulunduğum şehirde — iç anadolu şehirlerden bir tanesindeydim — cuma namazını kılmaya gittiğim camide ne zamandır duymadığım tarzda bir vaaz duydum. Evet bu sefer bir özeleştiri vardı. Konu yalan üzerine idi. Vaiz Efendi toplum olarak yalana nasıl müptela olduğumuzu hatta günlük hayatımızın bir parçası olduğu acı gerçeğinden bahsediyordu. Çocuklarınıza yalan söylettiriyorsunuz, onlara da yalanı öğretiyorsunuz diye sitemkar bir şekilde konuştu. Kapınızı çalan birisi için çocuğunuza beni sorarlarsa evde yok dersin diyerek o çocuğa yalanı gayet normal birşeymiş gibi gösteriyorsunuz dedi. Açıkcası bu hassasiyeti ne zamandır duymuyordum insanlardan. Çok hoşuma gitmişti. Evet yalanlar ve gıybetler ile kaplanmış zahirde güneşin doğduğunu zannettiğimiz ama iç alemlerimizde kapkaranlık bir dünya oluşturmuş olabiliriz kendimize.

Gıybetin ve yalanın olduğu yerlerde toplumsal bir paranoya kaçınılmazdır. Eğer en basitinden bir misafirlikten ayrıldıktan sonra arkanızdan şimdi ne konuşacaklar diye merak ediyor ve rahatsız oluyorsanız, yaşadığınız toplumda ve şahsi dünyanızda değişmesi gereken bazı temel sıkıntılar var demektir. Bunların dışında eğer siz menfaatiniz için yalan söylemekten kaçınmıyorsanız, başınıza atadığınız insanın da size menfaati olduğunu düşündüğünüz yalanlarına ses çıkarmazsınız. Bu yalanlar ne zaman size zarar verirde eğer o zaman başlarsanız feryad-u figana, bence oturun ve iç dünyanızı bir sorgulayın derim. Çünkü hakkaniyet ve adalet yalanın kime söylendiğine bakmaz, yalan söylenip söylenmediğine bakar. Gıybet meselesinden öncede kısaca iftira meselesine değinmek istersek o zaman şunu demekte fayda var. İftira yalanın farklı bir boyutta ki tezahürüdür. Yalan artık kin ve nefret ile buluşmuş ve ruhunu kapladığı şahıs yada şahısların nefislerini tatmin etmek ve kinleri kusturmak için masumlara atılan iftira suretine bürünmüştür. İftira aslında farkında olmadan da toplumda yapılabilen birşeydir. Eğer bir insanın arkasından doğru ama çirkin şeyler söylüyorsanız buna gıybet denir. Çirkin olmanın ölçüsü ise konuştuğunuz kişi eğer laflarınızdan alınacak ve üzülecekse düsturudur. Yok eğer doğruları söylemiyorsanız bunada iftira deniyor. Yani iftira arkadan konuşma ve yalanın bir birleşimi. Peki bu ikisinide günlük hayatında devamlı yapan ve bunu normal bir şeymiş gören insanların çoğunluğunu oluşturduğu bir toplumda nasıl bir lider ortaya çıkabilir bunu gelin hep beraber düşünelim.

Toplumu oluşturan sosyal yapı görüldüğünden daha etkili ve canlıdır. Bunun farkına şahsi olarak varmak zor ama dışarıdan biraz bakabilirsek o zaman bu sosyal dokuyu görmek biraz daha mümkün. İnsanları birbirine bağlayan ağların neler olduğunu görebilirsiniz. Bu kimileri için vicdan kimileri için menfaat kimileri için adalet vs. Ama en nihayetinde bu sosyal dokuyu oluşturan insanlardır. İnsanların fikirleri ve yaşayışları bu dokuyu bir dantale gibi örer. Sosyal yapı aslında bir açıdan da çok ilginçtir. Demin dediğim gibi sosyal dokuyu onu oluşturan insanlar oluştururlarken sonra bu doku bir hayat bulmuşcasına tam tersi istikametde bu sefer kendisini oluşturan insanları şekillendirmeye başlar. Aslında burada bir döngüden bahsetmek mümkün. Eğer bu doku içinde yukarıda bahsettiğimiz bozuk fiiller varsa, bu fiiller zamanla hem gelecek nesili kirlettiği gibi, var olan neslide daha da yozlaştıracaktır. Kısacası toplumsal olarak ne ekerseniz onu biçersiniz.

Daha ne kadar yazılır bilmiyorum. Aslında konu çok açık ve ortada. Nasılsanız öyle yönetilirsiniz.

Paylaş herkes duysun!Share on Google+Share on LinkedInTweet about this on TwitterShare on Facebook
October 23

SOLID Prensipleri Üzerine Düşünceler (Part 1)

Öncelikle bazı meseleleri açığa kavuşturmak faydalı olacaktır kanaatindeyim. Yazılımda devamlı bahsedilen kaliteli kod denilen şey aslında iki anad68b4d505a12x512.png prensip üzerine kurulmuştur. Bunlar daha az ama daha anlaşılır kod yazmak. Mesele tamamiyle bundan ibaret. Hani o her yerde görülen ismini bile telaffuz etmede zorlandığımız nice prensipler sonuç itibari ile bu iki ana temel üzerinde şekillenirler. Eğer design pattern kullanacağım diyerek kodunuzu okunmaz hale getiriyorsanız bence bırakın design pattern vs. kullanmayı ve kodunuzu daha basit ve anlaşılır nasıl yazarım onun derdinde olun. SOLID denilen prensipler ve Design Pattern diye bildiğimiz tasarım kalıpları tamamiyle daha anlaşılır ve daha az kod yazmak için geliştirilmiş tekniklerdir. Daha az kod yazmak içinde var olan kodları daha verimli kullanmak gerekir. Ama kodları yeniden kullanmaya çalışmak asla kodunuzu zor anlaşılır bir hale getirmemelidir. Bu prensipler DRY yani Don’t Repeat Yourself ve KISS yani Keep It Simple and Stupid denilen prensipler olarakta bilinirler. Burası anlaşıldı sanırım. O zaman gerçek meselemiz olan SOLID prensiplerine başlayabiliriz.

Bu makale birden fazla parçadan oluşacak. S.O.L.I.D hakkında yeterince kaynak bulmak mümkün ama ben bu makalemde SOLID in ne olduğundan ve nasıl kullanabileceğimizden bahsederken aynı zamanda kendi düşüncelerimide aktarmaya çalışacağım. Katılmayacağınız noktalar olacaktır. Bu noktaları yorum olarak bu postun altına yazarsanız sevinirim. Kendi düşüncelerim dedim çünkü genelde insanlar bu prensipleri mutlak doğru şeklinde görüyorlar. SOLID in önemli olmadığını söylemiyorum bilakis önemli olduğunu söylemek ile beraber bunların dışında SOLID yeterli mi, yanlış anlaşılan taraflar olabilir mi, yanlış olan kısımları olabilir mi, kısacası yazarken aklıma gelen soruları sizler ile birlikte tartışmaya çalışacağım. Bazılarınız farkında olmadan bu prensipleri zaten kullanıyorlar olabilirler ama sadece ismini bilmiyor olabilirler.Hani böyle insanlarda yok değil.

Bu meseleye ışık tutması açısından beğendiğim bir söz ile başlamak istiyorum: “In theory, there is no difference between theory and practice. But, in practice, there is.” yada Türkçesi ile “Teorik olarak teori ile pratik arasında fark yoktur. Ama pratik olarak bakıldığında ise fark vardır.”. Türkçeye çevirirken biraz daha dilimize uygun olması açısından bir kaç kelime daha ekledim. Neyse…

SOLID aslında 5 tane prensibin baş harflerinden oluşuyor. Bunları kısacası aşağıda ki gibi sıralayabiliriz. Ben yanlarına türkçelerinide yazmaya çalışacağım. Direk çevirileri çok mantıklığı gelmediğinden biraz kendimdende daha mantıklı durması için eklemeler yaptım diyebilirim.

  1. Single Responsibility Principle: Tek sorumluluk prensibi.
  2. Open/Closed Principle: Açık ve Kapalılık Prensibi.
  3. Liskov’s Substitution Principle: Liskov’un Yerine Geçme Prensibi.
  4. Interface Segregation Principle: Arayüz Ayırma Prensibi
  5. Dependency Inversion Principle: Bağımlılığı Tersine Çevirme Prensibi.

Şimdi ilk olarak malumunuz odur ki Single Responsibility Principle’dan bahsedeceğim. İsminden de anlaşılacağı gibi tek sorumluluğun olmasından bahsediyor.  Burada bahsettiği şey ise program içinde ki entity’ler. Kısaca özetlemek gerekirse bir method yada class sadece bir şey için değiştirilecek şekilde tasarlanmalı. Yada diğer bir tabirle bir class sadece bir işi yapmalı ve bir tane sorumluluğu olmalı. Bir class hem bir websayfasını download ediyor ve onu bir dosyaya kaydediyorsa burada bu prensibi ihlal ediyor demektir. Burada iki tane class yazmak daha doğrudur. Birincisi sadece verilen adresi download eder ve string olarak return eder diyelim. Diğeri ise sadece kendisine verilen string bilgisini bir dosyaya kaydeder.

Bu prensipte genelde class’lar daha çok bahsediliyor ama siz bunlara methodlarıda dahil edebilirsiniz. Çünkü methodlarında normal şartlar altında sadece bir iş yapmaları gerekiyor.

Şimdi bu meseleyi buraya kadar anladıysanız burada bahsedilen iş yada sorumluluğun sınırları ve tam manasıyla tanımları nedir, çizgiyi nereye koyuyoruz şeklinde sorularınızın olması gayet normal. Bu aslında duruma göre değişiyor. Bazıları bir unit işi bir requirement yani gereksinim şeklinde tanımlıyor. Bazılarına göre ise parçalanamaz kadar ufatılmış bir iş olarak görüyorlar. Bu noktada kesin çizgiler yok gibi. Daha çok size kalıyor. Mesela bir tane downloader uygulaması yazıyorsanız birden fazla requirement yani gereksinimler vardır. Requirement bu arada yazılım mühendisliğinden kullanılan bir terim. Bir yazılımın tamamlanması için istenen gereksinimler vardır. Bu gereksinimler dosyanın indirilmesi, ve kaydedilmesi şeklinde olabilir. Şimdi siz bu durumda HttpDownloader  diye bir sınıf yazabilirsiniz. Bunun görevi verilen adrese bağlanmak ve dosyayı indirmek olabilir. Duruma göre FtpDownloader  ve daha başka sınıflarda yazabilirsiniz. Bu size indirdiği dosyayı belki bir stream olarak yada byte array olarak verebilir. HttpDownloader  bundan başka bir görev ifa etmez. Sadece indirmek işinden sorumludur ve bu indirilen dosyayı kim istiyor ve onunla ne yapacak bunlar bu sınıfın sorumluluğu içinde değildir. Bundan sonra siz FileSaver  şeklinde bir sınıf yazarsınız. Bunun görevide kendisine verilen Stream  yada Byte array tipinden değerleride kaydetmek olur. Bunun dışında kendisine bu bilgiler verenin kim olduğunu umursamaz. Tek görevi verilen bilgiyi kaydetmektir. Dikkat ederseniz her iki sınıfında sadece bir tane sorumluluğu var. Başka işlere pek karışmıyorlar. Postacı gibi. Onun görevi sadece postayı getirmektir. Postanın içinde ne yazıyor ve kimi ilgilendiriyor ve postayı alan adam posta ile ne yapacak bunlar postacının sorumluluğu içinde olmaz.

Bu prensip için hangi programlama dilini kullandığınız önemli değil. Bunun faydalarından bir tanesi ve belkide en önemlisi yazdığınız kodun daha anlaşılır hale gelmesini sağlamak. Sadece bir tane iş yapan bir sınıfı okumak ve anlamak çok daha kolaydır. Her ne kadar isim olarak tasvip etmesemde God Class denilen yada Türkçe tabiri ile Tanrı Sınıfları diyebileceğimiz sınıflar vardır ki bunlar artık o kadar çok code içerirler ki her şeyi yapmaya çalışırlar Bu tarz sınıfların tam olarak ne yaptığını anlamak artık çok zor bir hale gelmiştir. Eski çalıştığım yerde project manager’ım yazdığı bir method vardı.Görevi pdf dosyaları okumak ve parse etmek gibi birşeydi. Gibi birşeydi diyorum çünkü 2000 satırlık bir method idi ve iş yerinde o methodu anlayan kimseyi bulamamıştım. Sonuç olarak bende anlamadım ve method’un çalıştığına güvenerek bende kendi kodumu onun üzerine bina ettim. Ama kodu incelemek için baktığımda sadece PDF değilde çok daha ilginç şeylerde yaptığını görmüştüm. Ama SRP sayesinde bu sorun bir nebze olsun aşılabilir diyebiliriz. Bunun dışında daha ufak sınıflar kod reusability yani var olan kodların yeniden kullanılabilirliğini arttırır. Bu önemlidir. Benzer kodu devamlı farklı yerlerde yazmak yerine yazdığınız bir kodu başka yerlerde yeniden kullanmak daha az kod yazmaya ve ileride kod bakımının daha kolay olmasına yardımcı olabileceği gibi yeni bir şey eklemek istediğinizde sadece bir yere eklemek suretiyle bu yeni değişiklikleri her yerde rahatlıkla görmeniz mümkün.

Şunu da hatırdan çıkarmamak gerekiyor bence. Projeler aslında organik canlılar gibidir ve zamanla büyürler ve değişirler. Bizler yazılımcılar olarak her ne kadar bizi ileride rahat ettirecek kodlar yazmak istesekte mükemmel kod yazmak hemen hemen imkansızdır. Onun için kodlarımız zamanla refactoring denilen bir process’e tabi tutulur. Yani kodumuzun daha da kaliteli olması adına zamanla gördüğümüz ama başlangıçta düşünmediğimiz yada başka sebeplerden dolayı özen gösteremediğimiz sorunları çözmek adına bu işlemi daha baştan kabul etmek ve planlarımızı buna göre hazırlamak gerekiyor. İş yerinde bizim yazdığımız proje şirketin içindekod tasarımı olarak herkesin gıpta ile baktığı ve övdüğü bir proje ama bu projede bile nice refactoring yaptık çünkü yapmamız gerekiyordu. Her yeni gelen kodun sistem içerisinde daha iyi entegre olması için refactoring çoğu zaman kaçınılmaz oluyor ve bizde kaçmadık.

Bu makalemizim birinci kısmı idi. İkinci kısmında Open/Closed Principle ‘dan bahsedeceğim. Tek sorumluluk prensibi diğer SOLID içinde ki diğer prensiplere bir temel teşkil edeceğinden anlaşılması önemli. Herkese şimdiden kolay gelsin.

Paylaş herkes duysun!Share on Google+Share on LinkedInTweet about this on TwitterShare on Facebook