Yazılımda detaylı tasarım adımı – 3 (Sonuç ve değerlendirme)

Yazılımda detaylı tasarım adımı-1 ve 2 yayınlarının devamı ve serinin son yayınıdır.

Yüksek yakınlık ve Düşük bağımlılık prensiplerini uygularken dengeli bir yaklaşım takip edilir. Metotlar birbirine yakın olacak diye, 1 metotlu onlarca sınıf olmasına da izin vermemelidir. Sınıf sayısı çok arttığında, bağımlılıkların da artacağı düşünülmelidir. Bir sınıf üzerinden birkaç işini görebilecek iken, her bir iş için farklı sınıfa müracaat edilmesi gerekecektir. Diğer taraftan, düşük bağımlılık sağlamak içinde çok fazla soyutlama (Abstraction) yapmaya gerek yoktur. Tasarım aşamasındaki herhangi bir bölümde, bir davranışın çeşitlilik (değişkenlik) gösterdiğini tespit ediyorsak, soyutlama sağlarız. Bugün için bir davranış şekli olabilir. İleride muhtemelen başka davranış şekilleri olabileceği bilgisine sahip isek, yine de soyutlama sağlayabiliriz. Soyutlama sağlamak, tasarımımızın esnek olmasını sağlar. Değişikliklere kapalı, yeni geliştirmelere açık oluruz.(Open-Closed Principle)

Yazılım Mühendisliğinin en önemli hedefi; tekrar kullanılabilir, esnek ve sürdürülebilir yazılımlar geliştirmektir. Bu prensipler, bu hedeflere önemli katkı sunmaktadır.

Not : Bu prensipleri, yazılım paketlerini de uygulayabiliriz.(JAR,DLL)

Yazılımda detaylı tasarım adımı – 2

Yazılımda detaylı tasarım adımı-1 yayınının devamıdır.

Diğer prensibimiz, Düşük bağımlılık (Low/Weak/Loose Coupling) prensibidir. Bir sınıfın, diğer bir sınıfa referansı olması ve değişikliklerden etkilenme seviyesi, bağımlılık olarak adlandırılır.Diğer sınıfa kendi tipi üzerinden(concrete) referans veriyorsa, bağımlılık yüksektir.(Tight Coupling) Bu sınıfın, açık olarak sunduğu tüm özelliklerini kullanır. Referans verilen bu sınıfta olabilecek değişiklikler, referans veren tüm sınıfları en üst düzeyde etkileyecektir. Hedefimiz, bağımlılığın düşürülmesi olmalıdır. Bunun için, somut(concrete) sınıf referansı yerine, soyut (abstraction) referans tercih edilmelidir. Her sınıf için soyutlama yapamayacağımız için, mümkün olan durumlarda kaydını koymalıyız.

Diğer bir bağımlılığın düşürülmesi yaklaşımı ise, direkt bağımlılığın kaldırılarak, dolaylı bağımlılık verilmesidir.(Decoupling) Örneğin; A sınıfı, sadece B sınıfı ile çalışır. (Tight Coupling) A sınıfı, B ailesindeki (B1,B2,B3) her hangi bir sınıf ile çalışabilir. (Loose Coupling) B sınıfı, C sınıfı ile çalışır.A sınıfı ve C sınıfının bağımlılığı kaldırılmıştır. (Decoupling) A ve C arasında dolaylı yoldan bir bağımlılık olduğu için, yine düşük bağımlılık olarak adlandırılır.

Yazılımda detaylı tasarım adımı – 1

Sistem alt sistemlere ayrıştırıldıktan sonra, detaylı tasarım aşaması gerçekleştirilir. Sistemin aldığı sorumluluklar, bu sorumluluğu gerçekleştirecek sınıflara atanır. İyi bir sınıf tasarımı için, yüksek yakınlık (High Cohesion) ve düşük bağımlılık (Loose Coupling) prensipleri takip edilir. Sınıflar, fonksiyonel olarak birbirine yakın metotları içermelidir. Metotlarda yakınlık, sorumluluğu da tek yapmaktadır. (Single Responsibility Principle) Yani, bu sınıfa sadece bir işlem grubu (sorumluluklar) için müracaat ederiz. İçinde, farklı sorumluluklar olmamalıdır. Sınıflarımız, sadece bir tip değişiklikten etkilenmelidir. Bu değişiklikten dolayı, tekrar teste tabi tutulur. Farklı sorumluluklar sebebiyle, farklı değişiklikler yapılması gerekecektir. Asıl sorumluluğu dışında yüklenen diğer sorumluluklar sebebiyle, çok defa test yapılması gerekecektir.

Çözüm olarak, sorumlulukları dağıtır ve sadece ilgili sınıfın değişiklikten etkilenmesini sağlayabiliriz. Sınıflara sorumluluklar dağıtıldığında, sınıflar arası bağımlılıklar gündeme gelir.

Yazılım tasarımında en öncelikli verilmesi gereken karar

Sistemin, alt sistemlere ayrıştırılmasıdır. (Subsystem decomposition) Alt sistemleri geliştirmek ve yönetmek daha kolaydır. Bu yaklaşım, diğer mühendislik ilimlerinde de öncelikli takip edilir. Sistemin sorumlulukları, alt sistemlere dağıtılır. Her sistem, kendi işini iyi yapar. (Single Responsibility) İhtiyacı olan diğer işler için, diğer sistemlerden istekte bulunur. Kendisine gelen bazı istekleri, diğer sistemlere yönlendirebilir. Tüm işi yapmaya mecbur olmamalıdır. (Delegasyon) Sistemler arası etkileşim, standartlar üzerinden gerçekleştirilmelidir. Bu sayede, sistemlerin değiştirilmesi de kolay olacaktır. Tüm sistemi yeniden yazmak veya başka bir sistem ile değiştirmek, artık geride kalmıştır.

Yazılımda tekrar kullanılabilirlik seviyeleri

1. Seviye : Birbiri ile ilişkili bir grup ifade, bir metot olarak düzenlenebilir.

2. Seviye : Birbiri ile ilişkili ve bağımlı metotlar, bir sınıf olarak düzenlenebilir.

3. Seviye : Birbiri ile ilişkili ve bağımlı sınıflar, bir paket olarak düzenlenebilir.

Üst Seviye : Birbiri ile ilişkili ve bağımlı paketler, bir yazılım alt yapı bileşeni (Framework) olarak düzenlenebilir.