SOLID Prensipleri Nedir Ne Değildir?

Merhabalar,

Solid prensipleri hemen hemen her mülakatta sorulan standart sorulardan biri değildir elbette.Bunu özellikle sormalarının bir sebebi olmalı.Benim kendimi geliştirme ve güncel tutma yöntemlerimden biri de bu tip yazılım mülakatlarında sorulan soruları, iş ilanlarında istenen teknolojileri takip edip öğrenmektir.Bunu da yeri gelmişken söylemiş olayım.

Solid prensiplerini de bundan seneler önce bu şekilde araştırıp öğrenmiş olabilirim emin değilim.

Solid prensipleri dünya üzerinde nesne temelli yazılım geliştirirken standartlaşmış tekniklerdir.Bu teknikler dünyanın her yerinde geçerli olmakla birlikte, sağlıklı okunabilir geliştirilebilir kısacası düzgün kod yazmak istiyorsak uygulamamız gereken teknikler de diyebiliriz.Spagetti kod yazmaya alışmış yazılımcılar zaten bu teknikleri uygulamaz ve önemsemezler.

Solid prensipleri nelerdir diyecek olursak; ilk olarak

SOLID’in S si- Single Responsibility(Tek Sorumluluk) Prensibi:Nesneye yönelik programlamanın kalbinde sınıflar bulunur.Bu sınıflar işleri daha yönetilebilir kılar.Yönetim demişken bu yönetimi en sağlıklı şekilde yapmak adına her sınıfa yalnızca bir sorumluluk vermek gerekir.Bu gerekliliğin adı da “tek sorumluluk” prensibi olarak karşımıza çıkar.

Bunun amacı hem binlerce satırdan oluşan sınıflarla uğraşmamak, hemde kodu daha yönetilebilir ve takip edebilir bir hale getirmektir.Gerçek hayattan örnekleyecek olursak, insan kaynaklarından sorumlu bir müdür var.Bu müdüre bir de satış sorumluluğu verirsek işler çığırından çıkacaktır.O müdürün sorumlu olduğu alan tek olmalıdır.

SOLID’in O su- Open Close(Açık Kapalı) Prensibi: Yazılımda değişiklik kaçınılmazdır.Hem ilk yazılan aşamada, hemde daha sonra belki 2 belki 5 belki 10 yıl sonra değişen teknolojilere de ayak uydurmak zorunda olduğumuzu düşünürsek gerçekten de değişime ayak uyduracak kodlar yazmak zorundayız.

Aslında bu prensip tanım olarak değişime kapalı, gelişime açık diye aktarılır.Benim üstte bahsettiğim şey de aslında gelişime açık olması gerekliliğidir.Gelişim derken şöyle ki,

Bir proje düşünelim.DataAccess layerımız var ve repository pattern uygulamışız.Orm olarakta entity framework kullanmışız.Daha sonra Entity Framework ihtiyaçları karşılayamaz hale gelmiş ve bizden orm olarak Dapper’a geçmemiz istenmiş.Bu tür durumlarda, diğer katmanlara hiçbir müdahalede bulunmadan, sadece DataAccess katmanını değiştirerek basit bir şekilde orm change yapmak istiyorsak bu prensibi göz önünde bulundurarak kodlarımızı yazmak zorundayız.Bu prensibin getirdiği kolaylık, zaman maliyetini minimize etmesi gerçekten de projelerde çok işe yaramaktadır.

SOLID’in L si- Liskov’s Subtitution(Liskov’un Yerine Geçme) Prensibi: Bu prensibin temel amacı projede oluşabilecek dummy kodları engellemektir.Şöyle ki; bir sınıf, türediği sınıftan gelen tüm özellikleri gerçeklemelidir.Yani üst sınıf ile alt sınıf arasında hiçbir fark olmamalı, birbirlerinin yerlerine kullanılabilmelidirler.

Gerçek hayattan örnek verecek olursak, bir araca bir arabaya klima tuşu koyup, o tuşu işlevsiz bırakırsak bu prensibe aykırı hareket etmiş oluruz.Dummy code da tam olarak bu şekilde oluşur.

SOLID’in I si- Interface Segregation(Arayüz Ayrım) Prensibi:Bu prensip için, tek sorumluluk prensibinin arayüz tarafı diyebiliriz.Özellikle “dependency injection” için yani bağımlılıkları azaltmak için arayüzler(interface) kullanırız.Bu interface lerede çok fazla sorumluluk yüklemek, bu interfaceleri gerçekleyecek olan sınıflar için sorun oluşturabilir.

Şöyle ki; yine solid prensiplerinden liskov’un yerine geçme prensibine gidecek olursak, klima tuşu olan ama işlevi olmayan araçlar yapmış oluruz.Bir sınıfta içi boş olan hiçbir işlevi olmayan metotlar bulundurmak bu prensibe aykırı olmakla beraber sağlıklı düzgün bir kod olmaz.

Kısacası, arayüzleri oluştururken de tek sorumluluk ilkesine göz önünde bulundurarak bir arayüze çok fazla yetenek yüklenmemelidir.

SOLID’in D si- Dependency Inversion(Bağımlılığın Ters Çevrilmesi) Prensibi:Bu prensip üst sınıfların, alt sınıflarda yapılacak değişikliklerden etkilenmemesi için uygulanır.Alt seviye ve üst seviye işlem yapan metotların birbirine bağlı olması kodların tekrar kullanılabilirliğine engel olur.Örneğin; üst seviye metotlardan birinde yapılacak bir değişiklik, bu metoda bağımlı olan diğer bütün metotlarında değişmesini gerektiriyorsa, bu metotlar birbirine çok sıkı bağlıdır.Bu kadar sıkı bağlılıkta projelerde her zaman sorunlara yol açar.

Böyle bir sorunu aşmak için soyutlama yöntemi kullanılır.Soyutlama yöntemi içinde arayüzler(interface).Eğer arayüzleri kullanarak bu metotların birbirlerine olan bağlılıklarını soyutlarsak, birbirlerinde yapılacak olan değişikliklerden etkilenmelerini engeller ve yeniden kullanılabilirlik sağlamış oluruz.

SOLID prensipleri, projelerinizi daha sağlıklı esnek, sorunsuz, takım halinde rahatça geliştirebilir kılar.Tabiki projenin büyüklüğü, ne amaçla yazıldığı, kapsamı gibi konular göz önüne alınmalıdır.Yoksa basit, tek bir arkadaşın geliştireceği ufak bir uygulama için bu kadar teferruata gerek yoktur.

Bu prensipleri orta ve büyük ölçekli her projede uygulamakta fayda vardır.Ben kendi adıma her zaman hızlı değil, sağlam ve düzgün kod yazılmasından yanayım.Bu sebeple bu prensiplerden mümkün olduğunca taviz vermeden kod yazmaya özen gösteriyorum.Zaman zaman özellikle çalıştığınız yerlerde yazılan projeler ve gidişat yüzünden uygulayamadığımız da oluyor tabiki.Sektörde bu tip şeylere önem veren, uygulayan bir yazılımcı olmak sizi bir adım öne çıkaracak ve önde tutacaktır.

Mutlu kodlamalar.