Yazılım Prensipleri

1.Amaç
2.Giriş
3.SOLID Prensipleri
3.1 Single Responsibility Principle (SRP) – Tek Sorumluluk Prensibi

1.Amaç

Bu belgenin amacı okuyucuya yazılım prensiplerini anlatmaktır. Konuların daha iyi anlaşılması için C++ ile yazılmış örnekler bulunmaktadır. Hızlı ve anlaşılabilir olması amacıyla  kimi örneklerin senaryosu basit ya da gereksiz gelebilir. Okuyucunun senaryoyu sınamasından ziyade örneğin anlatılan prensip ile uygunluğunu ve uygulama biçimini anlamaya çalışmalıdır.

2.Giriş

İyi bir tasarım ya da kodun öncesinde iyi bir yazılımcı olma hedefi vardır/olmalıdır. Yazılımcı ile yazılım arasında hem Üretici-Ürün hem de Üretici-Bilim ilişkisi vardır. Tıpkı Doktor-Hasta ve Doktor-TIP Bilimi ilişkisi gibi düşünülebilir. Üretici-Ürün ilişkisinde yazılımcının çıktısı olarak ürün elde edilir. Yazılım ürünlerinin kalitesi ya da değeri diğer somut ürünler gibi sınanamaz. Çünkü hiç hata(bug) içermeyen ve görevini tam yapan bir yazılım ürünü iyi bir kalitede ya da değerdedir diyemeyiz. Çünkü madalyonun diğer tarafında modülerlik, genişletilebilirlik, bakım kolaylığı, taşınabilirlik, okunabilirlik gibi konular vardır. Yani madalyonun diğer tarafında Üretici-Bilim ilişkisi ortaya çıkar. Fark ettiniz mi bilmiyorum ama anlatımda “madalyonun diğer tarafı” diyerek anlatım yaptım. “Madalyonun arkası” demedim. Çünkü madalyonun parlak ve göz alan tarafında Üretici-Ürün mü yoksa Üretici-Bilim ilişkisinin olup olmadığı tartışmaya açık bir konudur. Ben Üretici-Bilim ilişkisini madalyonun işlenmiş, parlak tarafında olduğunu düşünüyorum. (Ama madalyonun önünde arkasının da altın olduğunu unutmamak lazım.) ve bir yazılımcının kod yazarken aklında sadece projeyi bitirmek olmamalıdır.

Proje gereksinimlerini karşılayan fakat koduna bakınca burada ne olmuş, bunlar nedir  dedirten birçok proje görmüşsünüzdür. Modülerliği olmayan, en ufak bir değişiklikte hata üzerine hata veren ya da bir nokta değiştirilmek istendiğinde projede dolaşılmayan dosya bırakmayan yazılımlar bu yazılımlara örnektir.  İşte böyle bir üründe gerçek başarıya ulaşılmıştır denilebilinir mi? Projeni bitip ürünün çıkması mı başarı? Böyle bir projede kendinizi yukarıdaki resmin içinde gibi hissedeceksiniz. 

İşte bu yüzden yazılımcının ana hedefi proje hedefleri değil yazılım bilimi olmalıdır. Çünkü tüm başarıyı getiren yazılım biliminin kendisidir. Projeler gelip geçicidir ama yazılımın bilimi kalıcıdır. 

Projelerde yazılım biliminin kural ve yöntemleri uygulayarak yazılımcı olma yolunda ilerleriz. Her farklı projede yazılımın farklı kural ve yöntemleri ile tanışılması kişinin yazılım kabiliyetini, başarısını ve yazılıma olan bakış açısını değiştirir, dolayısı ile de bu getiriler projelerine yansır. 

Yukarıda anlatılanlar doğrultusunda bu belgenin konusu olan Yazılım Prensipleri öğrenilmesi gerekmektedir. Bu prensipler uygulandığı takdirde yapı itibariyle esnek ve geliştirilmesi kolay projeler oluşturulabilir. Fakat sadece prensibi uygulamış olmak için yapılanlar karmaşık bir yapıyı doğurabilir. Amaç her zaman en basit yöntemler kullanılarak, sade ve esnek yapılar oluşturmak olmalıdır.

3.SOLID Prensipleri

Design Principles kavramı, kötü tasarımdan uzak durmak için belirlenmiş belli kurallardan oluşan bir kurallar zinciridir. 

Principles of Class Design kavramı ise sınıflar üzerindeki modellemede uymamız gereken prensipleri belirlemiştir. Bunun dışında ayrıca paketlerin nasıl tasarlanması gerektiğini belirten prensipler de vardır. Biz bu yazı belgede  sınıflar için belirlenmiş prensipleri tanıyacağız.

Sınıflar için uyulması gereken bu prensipler, kötü tasarıma neden olabilecek üç ana unsuru ortadan kaldırmak amacıyla geliştirilmiştir. Robert Martin bunları şöyle sıralamıştır;

Rigidity (Esnemezlik): Kullanılan tasarımın esnek olmadığını gösterir. Yani kullanılan tasarımın geliştirmeye ve plug‐in mimarisine uygun olmadığını gösterir.

Fragility (Kırılganlık): Sistemin bir yerinde yaptığınız bir değişikliğin, sistemin bir başka yerinde sorun çıkarmasıdır.

Immobility (Sabitlik): Geliştirdiğiniz bir modülün tekrar kullanılabilir olmadığını gösterir. 

Bu üç ana unsurun aslında ortak bir paydada buluştuğunu ve buna çözüm bulmak için prensipler geliştirildiğini söyleyebiliriz. Şöyleki; bu durumların her birinin ortaya çıktığı nokta bağımlılık seviyesi yüksek sınıflarda görülür. Sınıf tasarımları eğer birbirlerine sıkı sıkıya bağlı ise, bu tasarım ne esnek, ne sağlam ne de taşınabilir olur. Buradan şunu söyleyebiliriz, tüm prensiplerin çözüm ararken yapmaya çalıştığı şey, mümkün olduğu kadar sınıfların birbirlerine olan bağımlılıklarını azaltmaktır. Bunların nasıl yapılacağını yazı dizimizin sonraki bölümlerinde tek tek göreceğiz. Fakat bundan önce bu sorunları ortadan kaldırmak için uymamız gereken prensiplere çok kısa bir şekilde bakalım.

Single Responsibility Principle: Her modülün bir tek sorumluluğa sahip olmasını ve ilerde olası bir değişikliğinde tek bir nedene dayandırılması gerektiğini belirtir.

Open/Closed Principle: Genişlemelere açık, modifikasyonlara kapalı bir tasarım kullanılması gerektiğini belirtir.

Liskov’s Substitution Principle: Türeyen sınıfın üyeleri, temel sınıfın üyeleri ile tamamen yer değiştirebilir olmalıdır.

Interface Segregation Principle: Interface’lerin mümkün olduğu kadar birbirlerinden ayrıştırılması gerektiğini belirtir.

Dependency Inversion Principle: Yüksek seviye sınıfların, düşük seviye sınıflara direkt olarak bağımlı olmaması gerektiğini belirtir. Bunu da araya bir abstract sınıf veya Interface koyarak yaparız.

3.1 Single Responsibility Principle (SRP) – Tek Sorumluluk Prensibi

Bu linkten Tek Sorululuk Prensibini açıklayan yazımma ulaşabilirsiniz.

Yazılım Prensipleri yazı dizisinin tamamını buradan indirebilirsiniz.