Solid Yazılım Prensibleri
Solid yazılım prensibleri ilk olarak Michael Feathers tarafından ortaya atıldı ve sonrasında Robert C. Martin tarfından S.O.L.I.D kısaltması olarak isimlendirildi.
Solid yazılım prensibleri nesne yönelimli programlama ve tasarım için ortaya çıkmış 5 adet ilkeden oluşan bir bağımlılık yönetim (dependency management) biçimidir.
Solid prensibleri amacı nedir ?
Geliştirilen yazılımın esnek, yeniden kullanılabilir, sürdürülebilir ve anlaşılır olmasını sağlayan, kod tekrarını önleyen prensipler bütünüdür.
- Geliştirdiğimiz yazılımın gelecekte gereksinimlere kolayca adapte olması,
- Yeni özellikleri kodda bir değişikliğe gerek kalmadan kolayca ekleyebileceğimiz
- Yeni gereksinimlere karşın kodun üzerinde en az değişimi sağlaması,
- Kod üzerinde sürekli düzeltme hatta yeniden yazma gibi sorunların yol açtığı zaman kaybını da minimuma indirmektir.
1-Single-Responsibility Principle(Tek Sorumluluk Prensibi)
Bu prensib özetle her sınıf veya fonksiyonun tek bir iş yapması gerektiğini savunmaktadır. Örneğin;
Alışveriş sitesine yeni bir kullanıcı eklenirken bir fonksiyon içinde hem rolleri hem de kişisel bilgilerini ekleyen bir kısım olduğunu varsayarsak prensibimize uymadığını görmüş oluruz. Çünkü bir fonksiyon bir iş yapmalısı gerektiğidir.
Olması gereken kullanıcının bilgileri kaydeden foksiyon ile rollerini kaydeden fonsiyon ayrı yazılmalıdır.
2-Open-Closed Principle(Açık Kapalı Prensibi)
Bu prensip, sürdürülebilir ve tekrar kullanılabilir yapıda kod yazmanın temelini oluşturur.
Open Sınıf için yeni davranışlar eklenebilmesini sağlar. Gereksinimler değiştiğinde, yeni gereksinimlerin karşılanabilmesi için bir sınıfa yeni veya farklı davranışlar eklenebilir olmasıdır.
Closed Bir sınıf temel özelliklerinin değişimi ise mümkün olmamalıdır.
Geliştirdiğimiz yazılıma/sınıfa varolan kodu değiştirmeden, yeni kod yazılarak yeni özellikler eklenebilmelidir. Yeni bir gereksinim geldiğinde mevcut kod üzerinde herhangi bir değişiklik yapıyorsanız, open/closed prensibine ters düşüp düşmediğinizi kontrol etmenizde yarar var. Yazılımı geliştirirken gelecekte oluşabilecek özellikler ve geliştirmeleri her şeyiyle öngöremeyiz. O yüzden oluşabileceğini düşündüğümüz kodlarıda şimdiden geliştirmemeliyiz. Yeni gelecek özellikler için varolan kodu değiştirmeden, varolan yapıyı bozmadan esnek bir geliştirme modeli uygulayarak, önü açık ve gelecekten gereksinimlere kolayca adapte olup, ayak uydurabilen bir model uygulamalıyız.
3-Liskov Substitution Principle ( Liskov’un Yerine geçme Prensibi)
Türeyen sınıf yani alt sınıflar ana(üst) sınıfın tüm özelliklerini ve metotlarını aynı işlevi gösterecek şekilde kullanabilme ve kendine ait yeni özellikler barındırabilmelidir.
Yani türeyen sınıf türetildiği sınıfın tüm özelliklerini kullanmak zorundadır. Aynı zamanda türeyen sınıf kendine özgü yeni özellikler ekleyebilir.
Örneğin; Dörtgenler Üst sınıf ve kare alt sınıf olsun. dörtgen sınıfında tanımlı boyut değiştir metodu uzun kenarı 300 ve kısa kenarı 100 yapsın. Kare sınıfını bunun yerine geçirdiğiniz zaman(Kare de bir dörtgendir) karenin tüm kenarları eşit olduğu için bu metodu karşılayamaz ve bu yüzünden bu prensibe uymaz.
4- Interface Segregation Principle ( Arayüz Ayrımı Prensibi)
Tek bir interface yerine kullanımlarına göre parçalanmış birden fazla interface ile işlemleri yürütmeliyiz. Yani her farklı sorumluluğun kendine özgü bir arayüzü olması gerekmektedir. Böylece interface’i kullanan kişide sadece ihtiyacı olanlarla ilgilenmiş olur. Birden fazla amaç için yalnızca bir arayüzümüz var ise buna gerektiğinden fazla method ya da özellik ekliyoruz demektir, bu da IS prensibine aykırı davrandığınız anlamına gelir.
Örneğin; Yarış oyunu tasarlarken arabaları, otobüsleri ve motosikletlerin hızlandığı method aynı interface de olursa bu prensibimize aykırı bir durum olacaktır. Onun yerine her bir aracın interface ayrı olursa kullanıcı hangisini kullanıyorsa onu kullanarak prensibe uyumlu olduğu anlamına gelmektedir.
5- Dependency Inversion Principle ( Bağımlılıkların Terslenmesi Prensibi)
Bir sınıfın, metodun ya da özelliğin, onu kullanan diğer sınıflara karşı olan bağımlılığı en aza indirgenmelidir. Bir alt sınıfta yapılan değişiklikler üst sınıfları etkilememelidir.
Yüksek seviye sınıflarda bir davranış değiştiğinde, alt seviye davranışların bu değişime uyum sağlaması gerekir. Ancak, düşük seviye sınıflarda bir davranış değiştiğinde, üst seviye sınıfların davranışında bir bozulma meydana gelmemelidir.
