SOLID Prensipleri ve Sürdürülebilir Yazılım
Sürdürülebilir yazılım ile, rahat anlaşılabilen, güncellenebilen, iyileşen ama temelden değişime ihtiyacı olmayan bir yapıdan bahsediyoruz.
Solid yazılım geliştirme prensipleri, Robert C. Martin tarafından öne sürülen, esnek, yeniden kullanılabilir, sürdürülebilir yazılım geliştirme temelli kurallar bütünüdür.
Kuralların baş harflerinden oluşan S.O.L.I.D prensipler bütününü inceleyelim.
S- Single Responsibility Principle
Tek sorumluluk ilkesi, bir bilgisayar programındaki her modülün, sınıfın veya işlevin, o programın işlevselliğinin tek bir parçası üzerinde sorumluluğa sahip olması gerektiğini ve bu bölümü kapsaması gerektiğini belirtir.
Eğer geliştirdiğiniz sınıf ya da fonksiyon birden fazla amaca hizmet ediyorsa, bu SRP kuralına aykırı Bunu farkettiğinizde sorumlulukları parçalamanız gerekmektedir.
Gereksinimler arttığında veya değiştiğinde, yazılan kodda da güncellenmesi gereken kısımlar olacaktır. Bu da yazılan sınıfların, nesnelerin de değiştirilmesi anlamına gelir. Bir sınıf ne kadar fazla sorumluluk alırsa, o kadar fazla değişime uğramak zorunda kalır. Sorumluluğun azaltılması demek değişime daha kolay adapte olmak demektir.
O- Open/ Closed Principle
“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”
En net haili ili; Sınıflarımız, fonksiyonlarımız değişikliğe kapalı ancak geliştirmeye, genişletmeye açık olmalıdır. Mevcut kodu değiştirmeden yeni işlevler ekleyebilecek şekilde kod yazmak bu prensibin gereğidir. Bu, sınıflarınızdan birinde bir değişikliğin aynı zamanda tüm bağlı sınıfları uyarlamanızı gerektirdiği durumları da önler.
L- Liskov Substitution Principle
İlke, bir üst sınıfın nesnelerinin, uygulamayı bozmadan alt sınıflarının nesneleriyle değiştirilebileceğini tanımlar. Bu, alt sınıflarınızın nesnelerinin, üst sınıfınızın nesneleriyle aynı şekilde davranmasını gerektirir.
Görseldekilerin ikisi de ördek. İkisini de ördek sınıfı üzerinden türettiğimizde birinin yemek yeme gibi özellikleri varken diğerinin olmadığını farkediyoruz.Bu bize bunun doğru bir soyutlama örneği olmadığını gösteriyor.
I- Interface Segregation Principle
Sorumlulukların hepsini tek bir arayüz ile yönetmek yerine, özelleştirilmiş birden fazla ve kendi özelinde arayüzler oluşturmayı tercih etmemizi söyleyen prensiptir.
Nesneler asla ihtiyacı olmayan property/metot vs içeren interfaceleri implement etmeye zorlanmamalıdır.
Yukarıdaki görselde, ILog interfacinden direkt DBLog ve FileLog classlarını implement etmek yerine, IDBLog ve IFileLog olarak interface çeşitlendirilmiş.
D- Dependency Inversion Principle
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.
Üst seviye sınıflar, alt seviye sınıflara bağlı olmamalıdır. Her ikisi de soyutlamalara bağlı olmalıdır. Aynı zamanda soyutlamalar detaylara bağlı olmamalıdır. Detaylar soyutlamalara bağlı olmalıdır.
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.
Kaynaklar:
