Programcı Olmak ve Anlamak Üzerine

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

Bu blogda sıklıkla programlamanın ve yazılımın tabiatı üzerine bir şeyler yazıyor, üstatlardan alıntılar yapıyorum. Aslen vurguladığım şey, programcı olmak her şeyden önce, anlamaktır. Bunları bir araya toplamak istedim, elime geçtikçe buraya ekleyeceğim. Zevkle okuyun:

Martin Fowler, Refactoring isimli kitabında şöyle der:

Herhangi bir insan bilgisayarın anlayabileceği kod yazabilir. İyi programcılar ise insanların anlayabileceği kod yazarlar.

(Any fool can write code that a computer can understand. Good programmers write code that humans can understand.)

Max Kanat-Alexander, Code Simplicity isimli kitabına şu cümlelerle başlar:

İyi programcıyla kötü programcı arasındaki fark anlamadır. Yani kötü programcılar ne yaptıklarını anlamazlar, iyi programcılar ise anlarlar. İster inanın, ister inanmayın ama bu gerçekten bu kadar basittir.

(The difference between a bad programmer and a good programmer is understanding . That is, bad programmers don’t understand what they are doing, and good programmers do. Believe it or not, it really is that simple.)

Programlama dünyasının kurucularından Donald Knuth şöyle diyor:

Bir program yazdığınız zaman, onu aslen bir edebiyat eseri olarak düşünün. Çünkü, insanların okuyacağı bir şey yazmaya çalışıyorsunuz. Onu, bilgisayarın uygulayacağı bir şey olarak düşünmeyin. Programınızı okunur kılmakta ne kadar başarılı olursanız, programınız o kadar başarılı olacaktır: Programı, bugün anlayacakınız, önümüzdeki hafta anlayacakınız, ve o program üzerine çalışıp, onu değiştirecek olan, sizden sonra gelenler anlayacaklar.

(When you write a program, think of it primarily as a work of literature. You’re trying to write something that human beings are going to read. Don’t think of it primarily as something a computer is going to follow. The more effective you are at making your program readable, the more effective it’s going to be: You’ll understand it today, you’ll understand it next week, and your successors who are going to maintain and modify it will understand it.)

Devamlı, anladığımız ve etrafımızdakilerin anladığı programlar yazmak umuduyla.

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

Yazılım Nasıl Geliştirilir? Ekleyerek mi Çıkararak mı? – I

Yazılım Kalitesi ve Test, Yazılım Mühendisliği

Danışmanlık yaptığım yerlerin birinde var olan kod üzerinde çalışırken 979 tane metodu olan bir sınıf gördüm. Evet yanlış okumadınız, 979 metodu olan bir sınıf 🙂  Bu durumu yanımda oturan ve o projede çalışan bir yazılımcıya söylediğimde bana “Akın bey, o sınıf ilk yazılırken o kadar büyük değildi, sonradan eklene eklene bu hale geldi” dedi. Söylediği şey açıkçası bizim yazılım geliştirmeyle ilgili en temel yanlışlarımızdan birini ifade ediyordu. Biz yazılım geliştirmeyi sadece “eklemek”ten ibaret biliyoruz. Dolayısıyla işin başında belki 100 civarında metottan oluşan bu sınıf 2 senenin sonunda 979 metoda sahip hale gelmişti. Tabi ki bir sınıfın 100 metoda sahip olması da sorgulanacak bir durumdur ama benim bu yazıda vurgulamak istediğim şey, yazılımı geliştirmenin devamlı olarak ekleme yapmaktan ibaret olduğunu düşünmemizdir. Aslında yazılım satır sayısı olarak büyürken yazılımdaki soyutlamaların küçülmesini gereklidir.

Bence önce şunu belirtmemiz gerekli. Biz dilimizde yazılımı geliştirmekten ya da kod, program yazmaktan bahsederiz. “No Silver Bullet” isimli makalesinde F. Brooks, hayatı boyunca yazılımla alakalı olarak önceleri “writing” yani “yazma” kelimesini kullanırken 1958 yılında (!) bir arkadaşından duyarak “building” yani “bina etme, geliştirme” terimini kullanmaya başladığını, sonrasında ise, tecrübesine dayanarak bu durumu en iyi ifade eden kelimenin “growing” yani “büyüme” olduğuna karar verdiğini yazar. Dolayısıyla yazılım tabiatı icabı, aynen organizmalarda ya da mühendislik yapılarında olduğu gibi büyür ve büyütülür.

Yazılım, proje boyunca büyür. Sonrasında proje biter ama yazılım hala büyümeye devam eder. Muhtemelen yazılımlar, çöpe atılacağı tarihe kadar büyümeye devam ederler. Öte yandan, biliyoruz ki yazılım temelde soyutlamalardan oluşan bir yapıdır. Yazılımların büyümesi, o yazılımlardaki soyutlamaların da büyümesi anlamına gelir mi? Yoksa yazılımların büyümesi daha çok içindeki soyutlamaların sayıca artması ve çeşitlenmesi anlamına mı gelmelidir? Daha açık bir ifadeyle, projenin başında 20 metoda sahip olan bir sınıf, 2 sene sonra projenin sonunda kaç metoda sahip olması beklenmelidir? Hala 20 mi? 15 mi? yoksa 100 mü?

Benim gördüğüm, bir refactoring kültürünün olmadığı yazılım geliştirme ortamlarında ve takımlarında, yazılımın büyümesinin en temel şekli eklemektir. Yeni soyutlamalar eklenir ama var olan soyutlamalardan herhangi bir şey çıkarılmaz. Örneğin bir pakete yeni sınıflar ekleriz ya da bir sınıfa yeni metotlar ekleriz ya da var olan bir metoda yeni “if” blokları ekleriz. Tüm bu eklemeleri boşuna yapmıyoruz, sonuçta bir ihtiyacı gideriyoruz. Ama her ihtiyacın, var olan yazılıma sadece yeni kod eklemeyle giderilmesi, kod eklenirken herhangi bir düzenleme yapılmaması anlamına geliyor. Bu durumda da yerine getirilecek ihtiyacı gerçekleştirecek kod parçasının, var olan kod yapısına nasıl monte edileceği, yeni kodun neresinin var olan yazılımda nereye oturacağı, tüm bunlar için var olan soyutlamalarda herhangi bir düzenlemeye gidilip gidilmeyeceğini genelde es geçiyoruz. Bundan dolayı sadece ekliyoruz. Hatta çoğu zaman eklerken, var olan kodlardan bazı parçaları “copy” ile alıp “paste” ile yeni eklenen yere monte ediyoruz. Bu da kod tekrarlarına sebep oluyor. Aslında yapılması gereken sadece eklemek değildir, çünkü eklemek refactoringde çoğunlukla tek yapılan şey değildir, hatta ilk yapılan bile değildir. Aslolan yazılımı, önce çıkarıp sonra ekleyerek, yani organizasyonel değişikliklerle büyütmektir.

Önce çıkarmak sonra eklemek nasıl olur? Ekleme yapacağınız yer bir metodun içinde ise, en basitinden ekleme yapılacak parçayı ayrı bir metot olarak soyutlayabilirsiniz. Hatta bu şekilde metottan kod parçası çıkarıp ayrı bir metot olarak soyutlamak, benzer şekilde bazı metotları var oldukları sınıf ya da arayüzden, yeni yaratılan sınıf ya da arayüzlere taşımak gibi refactoring çalışmalarına da gidebilecektir.

Bir yazılıma yapılacak değişikliklerin doğrudan eklenmek yerine, refactoring yani yazılımın mimarisi ve kodunda iyileştirici düzenlemeler yaparak gerçekleştirilmesi için göz önünde bulundurulması gereken iki yaklaşım vardır: İlki tasarım kalıplarının kullanılması, ikincisi de bu konuda çok iyi bir eser olan Martin Fowler‘ın Refactoring isimli kitabının iyice okunması ve sindirilmesidir.

Tasarım şablonlarının ciddi bir kısmı, örneğin Strateji, State, Command ve Proxy, genelde bir metot içinde toplanan pek çok karar yapısını soyutlayıp, bir arayüzü yerine getiren sınıflara bölmek fikri üzerinedir. Bu sayede gittikçe sayıları artan karar mekanizmalarına sahip kocaman metotlar yerine, her bir kararın kendisine ait metotta ifade edildiği, odaklı, daha basit ve anlaşılır yapılar oluşur.

Martin Fowler ise Refactoring isimli kitabında, farklı durumların nasıl iyileştirileceğini pek çok örnekle sistematik olarak anlatır.

Bu şekilde çıkarıp eklemelerle, yeni organizasyonlarla ilerlemek, copy-paste yerine cut-paste kullanarak var olan kod parçalarını tekrar tekrar düzenleyerek, her yeniliğin sisteme nasıl girmesi gerektiğini düşünerek yazılımı büyütmek, yazılımdaki satır sayısını, sınıf, metot vb. soyutlamaların sayısını arttırırken, bu soyutlamaların daima makul büyüklükte kalmalarını da temin edecektir. Bu da yazılımın büyüse bile karmaşıklığının olabildiğince kontrol edilebilir düzeyde kalmasını sağlar.

Bu şekilde, yazılımlardaki soyutlamaların, proje süresince ve sonrasındaki bakım sürecinde, eklenerek büyümesi yerine, mitoz ve mayoz bölünmelerle küçülmesi, en azından çok büyümemesi sağlanır. İşte böyle bir refactoring algısına sahip olunmayan bir yerde proje ilerledikçe, bir sınıftaki metot sayısı 979lara kadar gelir. Çünkü bu sınıfın sorumluluklarıyla igili olarak hem yanlış bir algı dolayısıyla da soyutlama vardır çünkü 979 sayısına gelinmiştir, hem de o ortamda refactoring kültürü yoktur, çünkü bu sayıya zaman içinde, metot ekleyerek gelinmiştir. Nitekim ben 979 sayısını bulduktan yaklaşık 2 ay kadar sonra aynı sınıfa baktığımda metot sayısı 1000’i geçmişti 🙂

Eskiden bu yana çok sevdiğim bir sözü buraya almak istiyorum. Hem yazar, hem şair hem de bir pilot olan Fransız aristokrat Antoine de Saint-Exupery şöyle demiş:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Yani

Mükemmellik, eklenecek bir şey olmadığında değil, çıkarılacak bir şey olmadığında başarılır.

Mühendisler mükemmeli değil, uygun olanı ararlar. Dolayısıyla daha yumuşak bir şekilde, yazılım soyutlamalarımızı uygun karmaşıklık düzeyinde tutmak için onlara eklemeler yapmak yerine onlardan çıkarma yapmayı düşünmeliyiz.

Bu konudaki pratik örnekleri bir sonraki yazıya bırakalım.

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

Kararsızlar İçin Mac Klavuzu – Devam

Diğer , , , , ,

3 küsür sene önce Mac kullanmaya başladığımda açıkçası bu kadar memnun kalacağımı düşünmemiştim. Önce 13″, i5 işlemcili MacBook Pro ile başladım sonra 15″ i7 işlemcili Retina ekranlıya geçtim. Yaklaşık 2 sene bunu kullandıktan sonra Aralık ayında aynı makinanın yeni modelini aldım. Şimdi RAM’i 16 GB olan Mac’im oldu yani.

Burada daha önce “Karasızlar İçin Mac Kılavuzu” başlıklı bir yazı yazıp, Mac deneyimim hakkında görüşlerimi paylaşmıştım. Orada da bahsettiğim gibi açıkçası benim için kullanım rahatlığı birinci planda geliyor. Maliyet tabi olarak hemen ardından ikinci faktör. Makinamda çalışırken, herhangi bir pürüz hissetmeden, yapmak istediklerimi bir duraklama, bekleme olmadan yapabilmem benim için çok önemli. Açıkçası danışmanlık ve eğitmenlik yaparken çok da fazla vakit ve enerji kaybına tahammülüm de yok. Dolayısıyla hızlı ve güvenilir çalışan ve benim vaktimi almayan herhangi bir sistem benim için mükemmel. Bu anlamda bir sistem ya da marka takıntım yok.

Pürüzsüz çalışma derken ne kastettiğimi bir örnekle açıklayayım. Geçen ay eski Mac Book Pro makinamı satılığa çıkardım çünkü yeni modelini aldım. Tabi olarak her yeni makina geçişinde eski dosyalar, ayarlar ve programları, yeni makinada aynen tekrardan kurgulamak gibi bazen haftalarca süren bir iş sizi bekler. İki makina arasında dosyaları kopyala, yeni makinaya uygulamaları kur, eski makinadaki ayarları yeni makinaya aktar vs. Örneğin tarayıcı bookmarkları ya da email hesapları, vs. vs.

Ben evimde backup amaçlı 3 TB Apple Airport kullanıyorum. Dolayısıyla makinam sürekli kendini buraya yedekliyor. Hatta bu Airport, yakınımdaki Mac’lerin de yedek yeridir :), bana gelince yedeklenirler. Eve yeni makinamı getirince, eski makinamdaki yapının bu yeni makinaya aktarılmasıyla ilgili yaptığım tek şey, yeni makinanın Airport’u görünce bana buradaki yedekten neyi almak istersin şeklindeki soruya bir-iki tık atarak cevap vermem oldu. Dosyaların aktarılmasını ama uygulamaların aktarılmamasını istedim. Bu aktarma 12 saat kadar sürdü sanırım çünkü akşamdan sabaha kadar zaman aldı. Uygulamaları aktarmak istemedim çünkü seçmece olarak yeni sürümlerini kuracaktım. Ve ben bu dosya aktarımını yaptıktan sonra, yeni makinaya hangi uygulamayı kurduysam, bütün ayarları ve gerekli dosyaları hemen kullanıma hazırdı. Hatta tarayıcıların sakladığı cookieler ve kullanıcı adı ve şifre bilgileri bile, eski makinamda olduğu gibi burada geçerliydi. Yeni kurduğum uygulamaların lisansları zaten hazırdı, uygulamayı kurdum, lisans bilgilerini girecekken, baktım lisansı geçerli. Apple Store’dan indirdiğim uygulamaları da otomatik olarak indirdim makinama. Dolayısıyla aldığımın ertesi günü tüm emaillerim, dosyalarım ve uygulamalarımla makinamdaki ortam aynen eski makinamda olduğu gibi kullanıma hazır bir haldeydi. Profesyonel bir yazılımcı başka ne ister ki?

Bu arada müşterilerimdeki ortamlardan dolayı Windows, Unix ve Linux ile çalışmaya devam ediyorum. Unix ve Linux’de bir problem yok, onlar zaten son derece güvenilir bir şekilde davranmaya devam ediyorlar ama Windows hala problemli. O da açıkçası, alıştırdığı gibi, kör topal çalışmaya devam ediyor. Hatırlıyorum, geçen senenin başında i7 işlemcili 16 GB RAM’li Toshiba marka iyi bir laptop almıştım ve eve gelip de kurulumunu yaptıktan sonra IE’yi ilk açışımda crash olmuştu ve makinayı tekrardan başlatmam gerekmişti. Windows 8.1 çalıştıran bu makinadaki IE’yi çok kullanacağımdan değil, sadece hızlıca Chrome ve Firefox gibi tarayıcıları hemen indirmek isteğimden olmuştu tüm bunlar 🙂 Mac kullanmanın bence Windows kullanmaya göre, gerek günlük kullanımda gerek ise profesyonel kullanımda neresinden baksanız %20 ile %40 civarında üretkenlik farkı sağladığını düşünüyorum ben. Bunu herhangi bir ölçüme ya da analitik modele göre söylemiyorum tabi ki, sadece hissiyatım bu yönde.

Bu yazıyı okuyanlar muhtemelen Apple’ın çok aç gözlü olduğundan dem vuracaklar ve “her şey için para istiyor” şeklinde eleştirecekler. Haksız değiller, çünkü Apple bir kapitalizm kültürünün çocuğu. Bildiğimiz, aklınıza gelen bütün teknoloji şirketleri gibi, Microsoft gibi, Google gibi, Oracle gibi. Tüm bu şirketlerin kapitalizmin kurallarını uyguladıklarında bir şüphe yok, amaç öncelikle kazancı arttırmak. Bu noktada rekabette öne geçmek için farklılığı, kaliteyi ve maliyeti optimum yönetmeleri gerekli. Kimisi iyi yönetiyor kimisi kötü, ya da daha doğru ifadeyle, tamamen insan odaklı bir pazardan bahsettiğimize göre, ihtiyaçlarımızın çok sık değişmesi gerçeğini göz önüne alırsak kimisi bu stratejileri doğru kurguluyor bir t zamanında ama bir başka zamanda yani t1’de bu kurguyu olması gerektiği gibi eviremiyor, dolayısıyla kapitalist döngüde aşağılara kayıyor. Ben Mac kullanımımda 3 OS geçişi yaşadım, ilkine sanırım $10 gibi bir rakam ödemiştim, son ikisine hiç bir şey ödemedim, çünkü bedava geldi yeni OSler. Öte taraftan farklılığı pahalı sunmak bir stratejidir, pahalı arabalar, pahalı giyecekler, pahalı saatler vs. gibi. Her pahalı her zaman farklı ve kaliteli olmayabilir ama her farklı ve kaliteli muhakkak pahalıdır.

Bu noktada ben Apple’ın oluşturmuş olduğu eko sistemden son derece memnunum. Telefon olarak iPhone kullanıcısı olduğum gerçeği de göze alındığında, çocuklarıma ve sevdiklerime de benzer eko sistem kurmam, benim yakın çevremle olan irtibatımı, paylaşımımı ve onların bilişim altyapılarını yönetmemi çok kolaylaştırıyor. Örneğin, dönem arasından faydalanarak Türkiye’ye gelen kızım da bir Apple (iPhone ve Mac Air) kullanıcısı. Dolayısıyla onun sorularına cevap verebilmem, makina vs.sindeki sorunları hızlıca giderebilmem vs. hep aslında bu pahalı eko sistemin bana kazandırdıklarından başka bir şey değil.

Herkesin tercihine saygım sonsuz ama Mac düşünenleri çok rahat bir çalışma ortamı bekliyor.

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

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

«< 27 28 29 30 31 >»