Solid prensiplerindeki amaç ne?

Sürdürülebilir yazılım üretin. Tamam o zaman. Sürdürülebilir nedir?

Yazılımda sürekli bir değişiklik var ve buna ayak uydurmamız gerekiyor. Sürekli güncelleme, güncelleme, güncelleme ve patlama. Solid İlkelerini kullanmazsanız her şey spagetti gibi olur.

Kısacası kodun değişiklikler sonucu çok karmaşık hale gelmemesi için uymamız gereken ilkeler bunlardır. Yazılı kodu okuyan herkes tarafından yeterince anlaşılır kılmak gibi amaçları vardır.

S-Single Responsibility Principle

Function,class,library yalnızca bir görev yapmalıdır. Nasıl Yani?

Örneğin bir Ürün classının içerisinde müşteri ile ilgili database işlemleri yapılmamalıdır yada bir iş fonksiyonlara bölünmelidir ve her iş için ayrı fonksiyon yazılmalıdır bunun sebebi ise her yerden düzeltmenin zor olması ,düzeltsek bile hangi işin nerede kullanıldığını (özellikle kod karmaşıklaştıkça) bilinmememizdir.

public void Register(){if(user==”Customer”){//Customer Register process//Customer Register process}else{//Customer Register process//Customer Register process}

Bunu Yapmayın.❌ Unutmayın, bir fonksiyonun bir görevi vardır. Hadi doğrusunu yazalım.

public void Register(){if(user==”Customer”){
   RegisterCustomer();}else{
   RegisterCompany();}

Yeterince kaliteli olmadığını biliyorum ama diğer prensiplerle en iyisini yapacağız.

Başka bir hatalı class kullanım örneğine bakalım.

public class ProductManager{   int id;   String productName;   void add(){      //add operation
   }}

Field’ları ve operasyonları aynı yerde tutmak bir hatadır. Çünkü yeni bir nesne oluşturduğumuzda, operasyonlar için de bellekte yeniden yer ayrılır. Bazı durumlarda ise bu yapı, operasyonların tekrar oluşturulmasına ve veri kaybına neden olabilir. Bu da Single Responsibility Principle’a aykırı bir durumdur.

public class ProductManager{
void add(){
    //add operation
   }
}
class Product{
   int id;
   String productName;
}

Doğru kullanımı ise operasyonlar ile fieldları ayırmaktır.

Başka bir örneği inceleyecek olursak, veritabanı nesnelerine karşılık gelen entity’lerde validation işlemi yapmak bir Single Responsibility Principle ihlalidir. Örneğin, “kimlik numarası 11 haneli olmak zorunda” şeklinde entity içerisinde bir validation yaptığınızı düşünelim. Fakat farklı ülkelerde bu numara 12 haneli olabilir ve bu durum bizim için problem oluşturur.

Sonrasında kuralı “11 veya 12 haneli olabilir” şeklinde esnetmek zorunda kalırız. Bu da zamanla veritabanında, 12 karakter uzunluğunda Türk vatandaşlarına ait kayıtlar gibi veri tutarsızlıklarına neden olabilir.

Bunun yerine, “Türkiye vatandaşıysa 11 haneli, değilse 12 haneli olabilir” gibi kurallar business validation katmanında ele alınmalıdır.

O — Open/Closed Principle

Yeni bir özellik eklemek veya mevcut bir davranışı değiştirmek istediğimizde, mevcut kodlara dokunmadan yeni kodlar yazarak sistemi genişletebilmeliyiz. Yani uygulamalar ve nesneler geliştirmeye açık, değiştirilmeye kapalı olacak şekilde tasarlanmalıdır.

class Program{  static void Main(string[] args){  CustomerManager customerManager=new CustomerManager(new       MySqlDatabase());}}class CustomerManager{  private IDatabase _Database;  public CustomerManager(IDatabase database){  _Database=database;  }  void Add(){  _Database.Save();  }
}class MySqlDatabase:IDatabase{  void Save(){  System.Console.WriteLine("Saved to MySql db");  }
}

Örneğin, sisteme MS SQL’e kayıt özelliği eklemek istersek tek yapmamız gereken yeni bir class oluşturmak ve main tarafında bu class’ı sisteme vermektir. Böylece if-else gibi yapılar yazarak kodu karmaşık hâle getirmemize gerek kalmaz.

class MsSqlDatabase:IDatabase{  void Save(){  System.Console.WriteLine("Saved to MySql db");  }}
class Program{  static void Main(string[] args){  CustomerManager customerManager=new CustomerManager(new          MsSqlDatabase());  }
}

L-Liskov substitution principle

“Hepsi kullanıcı, o zaman tek bir tablo yapayım; zaten benziyorlar.” şeklindeki bir yaklaşım yanlış bir kullanımdır. Örneğin şirketlerin soyismi olmadığı için ilgili alanı nullable yapmak gerekir. Ancak bu durum zamanla, soyadı olmayan bireysel müşteriler veya soyadı olan şirketler gibi veri tutarsızlıklarına neden olabilir.

Bu yüzden sistem tasarımı yapılırken, domain yapısı en baştan doğru modellenmelidir.

I — Interface segregation principle

Tüm interface’leri tek bir interface altında toplamak yerine, gereksiz özelliklerin gelmesini engelleyecek şekilde daha küçük ve amaca yönelik interface’ler tasarlamayı savunan prensiptir. Bu yaklaşımda her sınıf yalnızca ihtiyaç duyduğu özellikleri içeren interface’leri uygular ve “her şeye uyan tek bir yapı” oluşturulmaz.

class ABank:IBank{  void GiveCredit(){  //Do  }  void CalculateInterest(){  //Do  }  void DepositMoney(){  //Not Exists  }}class BBank:IBank{  void GiveCredit(){  //Do  }  void CalculateInterest(){  //Not Exists  }  void DepositMoney(){
     //Do
   }}

ABank ve BBank’ın yalnızca “banka” oldukları için gereksiz özellikler içermesi, ilerleyen süreçte karışıklığa yol açabilir. Bunun yerine, her birine özel interface’ler tanımlanmalı ve bu interface’ler daha üst seviye bir ana interface altında birleştirilmelidir.

interface IBank{  void GiveCredit();
}interface IPrivateBank:IBank{  void CalculateInterest();}interface IPublicBank:IBank{  void DepositMoney();}class ABank:IPrivateBank{  void GiveCredit(){    //Do  }  void CalculateInterest(){    //Do  }}class BBank:IPublicBank{  void GiveCredit(){    //Do  }  void DepositMoney(){    //Do  }}

Kısaca Interface Segregation Principle’ı, interface’leri doğru ve amaca uygun şekilde küçük parçalara ayırmak olarak tanımlayabiliriz.

D-Dependency Inversion Principle

Dependency Inversion Principle ile bağımlılıkları en aza indirmek amaçlanır. Sınıflar, alt seviye sınıflara doğrudan bağımlı olmamalıdır. Buradaki amaç, değişiklikleri kolayca yapabilmek ve mevcut bir sınıfın yerine başka bir sınıf geldiğinde de kodu çalışır durumda tutabilmektir. Bu da ilk başta bahsettiğimiz gibi SOLID’in temel amacıdır.

private IDatabase _Database;public CustomerManager(IDatabase database){ _Database=database;}

Böyle bir örnekte, “MySqlDatabase sınıfı olacak” şeklinde bir bağımlılığımız yoktur. İstediğimiz herhangi bir veritabanı implementasyonunu, interface’e bağlı bir nesne olarak sisteme verebiliriz.

fikretcansel25@hotmail.com

— — — — — — — — -Github — — — — — — — —