Yusuf Bülbül

An Engineer

Yazılım Mimarileri

Üç, dört yıllık C++ tecrübeme binaen şunları söyleyebilirim ki; aslında en iyi program yazanın siz olduğunuzun fazla bir anlamı ve önemi yok. Hatta zekanın ve tecrübenin de fazla bir anlamı yok. Çünkü artık dünyada başarılacak işler, sadece bir insanın ömrünün ve kabiliyetinin yetebileceği kadar basit işler değil. İyi bir fikir üretebilirsiniz elbette, ama bu fikri hayata geçirecek olan yine sağlam bir ekiptir.  Yani eğer diğer insanlarla uyumlu ve aktif çalışamıyorsanız yaptığınız şeyler sadece küçük dünyanızda kalıyor ve ileriye gidemiyor maalesef. Konu yazılım mimarisi iken buraya nereden geldim? Aslında yazılım mimarisinin en temel prensibi budur. Yazılım ekibinin beraber çalışabilmesi, kodun başka bir programcı tarafından daha rahat anlaşılabilmesi, hatalarının kolay bir şekilde bulunabilmesi ve daha iyi geliştirilebilmesi gibi ardı ardına çok daha fazla şey sıralayabileceğimiz nedenlerden ötürü kodunuzu belirli tasarım desenleriyle tasarlamanız gerekiyor. Bu yazı dizisinde şu ana kadar en çok kullandığım 3 yazılım tasarım deseninden bahsedeceğim.

Yazılım mimarisi ile yazılım tasarım deseni arasıdaki fark şudur ki; yazılım desenlerinin bir ya da birden fazlasını kullanarak oluşturduğunuz şemaya yazılım mimarisi diyebiliriz. Yani yazdığınız yazılım büyük bir yazılımsa zaten mecburen bir çok yazılım deseni kullanmak zorunda kalıyorsunuz. Aslında büyük bir yazılım projesine başlanacağında ilk önce yazılımın nasıl bir mimariye sahip olacağı belirlenir ve nesne nesne bütün yazılım şematize edilir. Bir inşaat, yapımına başlanılmadan önce nasıl projelendirilirse yazılım da bu şekilde projelendirilir. Fakat buradaki işçiler, kalifiye yazılım geliştiricilerdir.

Öncelikle yazılım tasarım desenlerinin ne olduklarından ve ayrıldığı sınıflardan biraz bahsetmek istiyorum. Yazılım desenleri ihtiyaca göre en temelde üç ana bölüme ayrılıyor. Bunları detaylı bir şekilde bu adresten okuyabilirsiniz. Ben de bu yazı dizisinde, bu adresten bol bol alıntı yapacağım.   Bunları teker teker anlatmak yerine sadece şöyle özetleyebilirim.

  • Yaratıcı Tasarım Desenleri(Creational Design Patterns) 

Bu tasarım deseni daha çok yazılımdaki herhangi bir nesnenin yine aynı işi yapan ama farklı özelliğe sahip başka nesnelere dönüşebilmesi ve bu nesnelerin belirli bir ana başlık altına toplanması şeklindedir. Bu tip yazılım desenlerinin en bilineni Abstract Factory dir.

 

 

  • Yapısal Tasarım Desenleri(Structural Design Patterns)

Bu tarz tasarım deseninin başlıca özelliği nesnelerin hiyerarşik olmasıdır.  Her nesne kendi içerisinde alt modüllerden oluşur. Bu modüler yapısı yazılımı yapısal bir forma sokar. Bu tip mimariler arasında en çok bilineni facede tasarım desenidir.

 

 

 

  • Davranışsal Tasarım Desenleri(Behavioral Design Patterns) 

Bu tasarım deseni, yazılım kurgusunu tamamen bir olaya, bildirime ya da duruma dayalı hale getirir.  Aslında bu yazılım desenleri daha çok sinyal işleme, haberleşme gibi işlemleri yapan yazılımların kullandığı desenlerdir. Ben bu yazı dizisinde bu tarz yazılım mimarilerinden Observer yazılım mimarisini ele alacağım.

 

 

Aslında üst seviye dillerin orataya çıkarılmasındaki en büyük sebep yazılımı bu şekilde daha kolay projelendirebilmek ve somutlaştırabilmektir. Nesne yönelimli programlamanın da temel prensibi budur. Nesne yönelimli programlama tekniği sayesinde, yazılım dünyasının sunduğu olanaklar bu günkü seviyesine ulaşabildi.  Tasarım desenlerine ihtiyaç duyulmasının sebebi ise projelendirilen ve mimarisi orataya çıkarılan yazılımın herkes tarafından daha rahat anlaşılabilmesini sağlamak ve  yazılımın standartlaşmasını sağlamaktır.

“Her şeyi bu kadar standartlaştırmak ve kalıplaştırmak ne kadar iyi olabilir ki?” diye içinizden geçirebilirsiniz.  Fakat nasıl ki bir otomasyon firması için üretilen ürünün parçalarının standart olması işleri ne kadar kolaylaştırıyorsa, yazılım desenlerinin kalıplaşması ve mimarilerin de kalıplaşması yazılım dünyasında çok iş görür bir durumdur. Çünkü yazılım dünyası içinde biraz bulunmuş birisinin “Legacy Code” olarak isimlendirilen ve çok çok önceden yazılıp bitirilmiş ama kimsenin ne dokunabildiği ne de geliştirebildiği yazılımların ne kadar başa bela olduğunu bilir. En kötüsü de en büyük güvenlik açıklarının ve yazılım hatalarının olduğu kod parçaları da bunlardır.

Aslında projelendirmeyi yazılım süreci takip etse de son adım değildir. Sonraki aşama bundan daha önemli bir aşama olan test aşamasıdır.  Bu aşama yazılımın ürün haline gelebilmesi için en önemli aşamadır.  Çünkü yazılan hiç bir kod mükemmel değildir ve asla olmayacak. Testciler bu noktada yazılımın ortaya çıkan bir dolu hatasını bulurken yazılımcı da bu hataları nasıl düzelteceğini kara kara düşünür. İşte bu noktada projelendirilmesi iyi bir şekilde yapılıp mimarisi sağlam çizilmiş bir yazılımın diğer yazılımlara ne kadar büyük farklar attığını görebilirsiniz. Bu aşamada tasarım desenlerindeki standartaşmanın ne derece önemli ve hayati öneme sahip olduğunu anlıyorsunuz aslında. Şu ana kadar içinde bulunduğum bir çok proje sadece yazılım mimarisinin kötü olmasından dolayı bu aşamda takılıp kaldı.

Bu bir yazı dizisi olacak bir sonraki yazımda Yaratıcı tasarım desenini ve bu gruba ait “Abstract Factroy” desenini anlatacağım.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir