SOLID Prensipleri Nedir?
SOLID kavramını ilk olarak üniversitede duymuştum. Udemy’de aldığım kurslarda, girdiğim iş mülakatlarında hep bu kavramla karşılaştım. Profesyonel iş hayatına adım atmamla birlikte SOLID prensiplerinin önemini, neden bu prensipleri iyi bir şekilde öğrenmem gerektiğini daha iyi anladım.
SOLID prensipleri ilk olarak Robert C. Martin tarafından makalesinde tanıtıldı. Bu makalede yer alan ilkelerin amacı yazdığımız kodun okunabilir, anlaşılabilir ve geliştirilebilir hale getirmektir. SOLID kelimesi ise makalede yer alan 5 temel prensipin baş harflerinin bir araya gelmesiyle oluşmuştur.
- Single Responsibility Principle
- Open-Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
Single Responsibility Principle
Tek sorumluluk prensibi, bir sınıfın ya da fonksiyonun tek bir görevi olmasını belirtir. Örnek olarak veritabanı işlemi yapan bir fonksiyonun aynı zamanda loglama yapması bu ilkeye aykırıdır.
Open-Closed Principle
Açık-Kapalı prensibi, sınıfların genişletilmeye açık ve değişikliğe kapalı olmasını belirtir. Bu ilkede sınıfdaki mevcut koda dokunmadan yeni işlevler kazandırılabilmesinden bahsediliyor. Mevcut kodu değiştirdiğinizde farkında olmadan farklı bir yeri etkilemiş olma riskiniz olabiliyor.
Aşağıdaki örnekte basit bir şekilde çalışanları modelledim. Bu yapıda çalışanlar Employee protokolünden türüyor. Developer ve TeamLeader sınıflarında bulunan getDetails fonksiyonu özelleştirilebilir yapıdadır. Yeni bir çalışan tipi geldiğinde ise Employee protokolünden türemiş bir sınıf oluşturarak sisteme dahil edilebilecektir.
Liskov Substitution Principle
Liskov Yerine geçme prensibi, alt sınıfların temel sınıflarının yerine geçmesi gerektiğini belirtir.
Aşağıdaki örnekte loglama için bir protocol yazılmıştır. TxtLogger ve DbLogger sınıfları LoggerService isimli protocol aracılığıyla türetilmiştir. Loglama yapacak olan Logger sınıfının log isimli metodu ise parametre olarak LoggerService tipinde bir parametre almaktadır. Loglama için hangi yöntemi kullanmak istiyorsak ilgili sınıfı parametre olarak vermemiz yeterli olacaktır. Liskov prensibini düşündüğümüzde alt sınıfların(TxtLogger veya DbLogger) temel sınıflarının(LoggerService) yerine geçtiğini daha net göreceksiniz.
Interface Segregation Principle
Arayüz ayırma prensibi, bir arayüze gereğinden fazla yetenek eklenmemesi gerektiğini belirtir.
Bu senaryomuzda bir banka düşünelim. Bireysel müşterileri A ve B kartlarını, Ticari müşterileri ise C kartını alabilsin. CreditCardApplication protokolü kullanılarak türetilecek bireysel ve ticari müşterilere ait sınıflarda kendinde olmaması gereken özellikler de yer almış olacak. Bireysel müşteri sınıfını IndividualCreditCardApplication protokolünden, ticari müşterileri ise CommercialCreditCardApplication protokolünden türettiğimizde daha okunabilir ve her biri kendi görevini yapan sınıflar oluşturabileceğiz.
Dependency Inversion Principle
Bağımlılığın ters çevrilmesi prensibi, sınıflar arası bağımlılığın en az inmesini, aralarındaki bağın soyut sınıflar üzerinden olması gerektiğini belirtir.
Bu senaryoyu incelediğimizde RestaurantA sınıfı TarhanaSoup sınıfına doğrudan bağımlı olduğunu görüyoruz. Bu durum kodun karışmasına ve yönetiminin zorlaşmasına sebep olacaktır. TarhanaSoup sınıfında bir değişiklik yapıldığında ya da yeni bir çorba tipi geldiğinde RestaurantA sınıfında değişiklik yapmamız gerekecek.
RestaurantB sınıfını ise Soup tipinde bir parametre alacak şekilde hazırlandı. LentilSoup sınıfında bir değişiklik yaptığımızda ya da yeni bir çorba tipi geldiğinde RestaurantB sınıfının hiçbirinden haberi olmayacak.
Bir sonraki yazımda görüşmek üzere..
