Tek Sorumluluk İlkesi

Tek Sorumluluk İlkesi (Single Responsibility Principle - SRP), Robert C. Martin tarafından tanımlanan ve bir sınıfın değişmesi için yalnızca tek bir neden olması gerektiğini savunan temel bir yazılım tasarım kuralıdır. Bu ilke, bir sınıfın veya modülün işlevselliğinin dar, iyi tanımlanmış ve tutarlı bir sorumluluk etrafında yoğunlaşmasını gerektirir. Prensibin odak noktası, yüksek bağlanırlık (high cohesion) ve düşük bağımlılık (low coupling) hedeflerine ulaşmaktır. İhlal edildiğinde, sistemler kırılgan, katı ve anlaşılması zor hale gelir.

Sorumluluk, bir değişiklik için bir "neden" olarak tanımlanabilir. Bir sınıfın birden fazla sorumluluğu birleştirmesi, bu sorumluluklardan herhangi birinde meydana gelen bir değişikliğin, sınıfın diğer, ilgisiz sorumluluklarını etkileme riskini doğurur. Bu durum, değişiklik yapmayı zorlaştırır ve yan etkilerin ortaya çıkmasına neden olur. Örneğin, bir `Kullanıcı` sınıfının hem kullanıcı verilerini yönetme (iş mantığı) hem de bu verileri bir veritabanına kaydetme (kalıcılık/veri erişim katmanı) görevini üstlenmesi, SRP'nin tipik bir ihlalidir. Veritabanı teknolojisi değiştiğinde veya kullanıcı doğrulama kuralları güncellendiğinde, aynı sınıf değiştirilmek zorunda kalır.

Sınıf Türü SRP'ye Uygun Sorumluluk SRP İhlali İçeren Sorumluluk
RaporSınıfı Rapor verilerini hesaplamak. Raporu hesaplamak, HTML'ye biçimlendirmek ve bir dosyaya yazmak.
SiparişSınıfı Sipariş durumunu ve öğelerini yönetmek. Siparişi yönetmek, fatura oluşturmak ve envanteri güncellemek.
Veriİşleyici Ham veriyi belirli bir kurala göre dönüştürmek. Veriyi dönüştürmek, bir web servisine göndermek ve hataları loglamak.

SRP'nin uygulanması, daha küçük, odaklanmış ve test edilebilir sınıfların oluşmasına yol açar. Her sınıf, kendi görevinde bir uzman haline gelir. Bu da birim testlerinin yazılmasını kolaylaştırır, kodun yeniden kullanılabilirliğini artırır ve sistemin genel bakım maliyetini önemli ölçüde düşürür. İlke, modülerliği teşvik eder ve değişiklik yalıtımı sağlar, böylece bir alandaki bir değişikliğin sistemin diğer kısımlarını etkileme olasılığı azalır.

Açık-Kapalı İlkesi

Açık-Kapalı İlkesi (Open-Closed Principle - OCP), yazılım varlıklarının (sınıflar, modüller, fonksiyonlar) genişletmeye açık, ancak değişikliğe kapalı olması gerektiğini belirtir. Bertrand Meyer tarafından ortaya atılan bu ilke, mevcut ve test edilmiş kod tabanını değiştirmek yerine, yeni işlevselliğin yeni kod eklenerek (miras alma, arayüz uygulama, kompozisyon) elde edilmesini savunur. Temel amaç, mevcut kodun istikrarını korurken sistemin davranışını değiştirebilmektir.

OCP'nin pratikte uygulanması, soyutlamalar (abstract class'lar veya interface'ler) kullanarak değişen davranışları soyutlamaktan geçer. Katı, somut implementasyonlara bağımlılık, kaçınılması gereken bir durumdur. Bunun yerine, istemci kodu soyut bir tipe bağlı olmalıdır. Yeni bir davranış gerektiğinde, bu soyut türden türetilmiş yeni bir sınıf oluşturulur. Bu yaklaşım, mevcut kodda hiçbir değişiklik yapılmadan sistemi genişletmemize olanak tanır. Örneğin, bir ödeme işlemi sistmi, `ÖdemeYöntemi` adında bir arayüzle tasarlanabilir. `KrediKartı` ve `PayPal` sınıfları bu arayüzü uygular. Sisteme `KriptoPara` ödeme yöntemi eklenmek istendiğinde, sadece yeni bir sınıf oluşturulur; mevcut ödeme işleme mantığı değiştirilmez.

OCP Uygulanmamış Yaklaşım OCP Uygulanmış Yaklaşım Kazanım
Bir `AlanHesaplayici` sınıfında `if (şekil == "daire") {...} else if (şekil == "kare") {...}` gibi kontrol yapıları. `Şekil` arayüzü ve `AlanHesapla()` metodu. `Daire` ve `Kare` sınıfları bu arayüzü uygular. Hesaplayıcı, `Şekil` tipindeki nesnelerle çalışır. Yeni bir şekil eklemek için mevcut koda dokunulmaz, sadece yeni bir sınıf eklenir.
`Rapor` sınıfının içinde `PDFYazdir()`, `HTMLYazdir()` gibi somut metodlar. `RaporYazici` arayüzü ve `PdfYazici`, `HtmlYazici` implementasyonları. Rapor oluşturucu, yazıcı türüne bağlı değildir. Yeni bir çıktı formatı, sistemin geri kalanını etkilemeden entegre edilir.
`Filtrele` metodunda belirli özelliklere göre (`renk`, `boyut`) sabit kodlanmış filtreleme. `Şart` (Specification) arayüzü ve bunu uygulayan sınıflar. Filtreleme metodu `Şart` tipindeki nesnelere göre çalışır. Yeni bir filtreleme kriteri, yeni bir `Şart` sınıfı eklenerek kolayca desteklenir.

Bu prensip, tasarımın esnekliğini ve gelecekteki değişikliklere karşı direncini önemli ölçüde artırır. OCP'ye uygun sistemler, değişen gereksinimlere karşı daha dayanıklıdır ve genişletme maliyetleri düşüktür. Soyutlamalara dayalı bu yapı, Strateji (Strategy) veya Dekoratör (Decorator) gibi davranışsal tasarım kalıplarının da temelini oluşturur. İlkenin başarılı bir şekilde uygulanması, kod tabanının sürdürülebilir ölçeklenmesini sağlar.

Liskov Yerine Geçme İlkesi

Liskov Yerine Geçme İlkesi (Liskov Substitution Principle - LSP), Barbara Liskov tarafından 1987'de formüle edilen ve nesne yönelimli programlamanın davranışsal alt tip ilişkisini tanımlayan temel bir ilkedir. İlke, bir T tipine ait herhangi bir nesnenin, bir S tipi nesnesi ile değiştirilebilmesi durumunda, programın doğruluğunu bozmadan S tipinin T tipinin bir alt türü olabileceğini belirtir. Basitçe, üst sınıf nesnelerinin referanslarının, alt sınıf nesneleriyle değiştirilmesi durumunda programın beklenen şekilde çalışmaya devam etmesi gerektiğini söyler.

LSP, sadece sözdizimsel (syntax) uyumluluktan ziyade, davranışsal uyumluluğu vurgular. Bir alt sınıf, üst sınıfının tüm davranışlarını korumalı, beklenen sözleşmeyi (contract) bozmamalıdır. Bu sözleşme, metodların ön koşullarını (preconditions), son koşullarını (postconditions) ve değişmez yapılarını (invariants) içerir. İlkenin ihlali, genellikle türetilmiş sınıfların, taban sınıfın metodlarını anlamsız şekilde ezmesi veya beklenmeyen istisnalar fırlatmasıyla ortaya çıkar. Örneğin, `Dikdortgen` sınıfından kalıtım alan bir `Kare` sınıfı, `setEn` ve `setBoy` metodlarını ezerek her iki tarafı da eşit ayarlarsa, geometrik bir doğruluk sağlansa da `Dikdortgen` beklenen davranışı (en ve boyun bağımsız ayarlanabilmesi) bozulmuş olur.

  • Ön Koşulları Zayıflatma Kuralı: Alt sınıf, üst sınıf metodunun gerektirdiği ön koşullardan daha fazlasını talep edemez, ancak daha azını talep edebilir (zayıflatabilir).
  • Son Koşulları Güçlendirme Kuralı: Alt sınıf, üst sınıf metodunun garanti ettiği son koşullardan daha azını garanti edemez, ancak daha fazlasını garanti edebilir (güçlendirebilir).
  • Değişmez Yapıları Koruma Kuralı: Alt sınıf, üst sınıf tarafından korunan tüm değişmez yapıları (örneğin, bir nesnenin durumuyla ilgili kısıtlamalar) korumalıdır.

LSP ihlallerinin pratikteki sonuçları ciddidir. Çalışma zamanında tip kontrolüne (type checking) ihtiyaç duyulmasına, `instanceof` gibi operatörlerin kullanılmasına ve kodda beklenmeyen hataların ortaya çıkmasına neden olur. Bu durum, açık-kapalı ilkesini de dolaylı olarak ihlal eder, çünkü her yeni alt tip eklenmesi, istemci kodunun bu yeni tipi tanıyacak şekilde değiştirilmesi riskini taşır. Doğru bir şekilde uygulandığında ise LSP, polimorfizmin gücünden tam olarak yararlanmamızı sağlar. İstemci kodu, soyut temel türlerle çalışır ve somut alt tiplerden tamamen habersiz kalır, bu da sistemin esnek ve genişletilebilir kalmasını sağlar.

Arayüz Ayrımı İlkesi

Arayüz Ayrımı İlkesi (Interface Segregation Principle - ISP), istemcilerin (sınıflar) kullanmadıkları arayüzlere bağımlı olmaya zorlanmaması gerektiğini öne sürer. Büyük, monolitik arayüzler yerine, daha küçük, daha özel ve istemciye özgü arayüzlerin oluşturulmasını teşvik eder. Bu ilke, bir arayüzün, onu uygulayan tüm sınıfların ihtiyaç duyduğu tüm metodları içermek zorunda olduğu varsayımını kırarak, daha temiz bir bağımlılık yönetimi sunar.

ISP'nin temel motivasyonu, "ağır" arayüzlerin neden olduğu sorunları ortadan kaldırmaktır. Bir sınıf, kendisine sağlanan bir arayüzü uygulamak zorunda kaldığında, arayüzdki tüm metodları implemente etmelidir. Eğer bu metodlardan bazıları o sınıf için anlamsız veya geçersiz ise, sınıf ya bu metodları boş bırakmak (null implementation) ya da istisna fırlatmak gibi hatalı yaklaşımlara başvurmak zorunda kalır. Bu durum, kod kirliliğine, beklenmeyen çalışma zamanı hatalarına ve sınıfın sorumluluklarının bulanıklaşmasına yol açar.

Örneğin, `ÇokAmaçlıYazıcı` arayüzü `Yazdır()`, `TaramaYap()`, `FaksGönder()` ve `FotokopiÇek()` metodlarını içerebilir. Eski bir tarayıcı modeli için `EskiTarayici` sınıfı yazıldığında, bu sınıf kullanmadığı `Yazdır()`, `FaksGönder()` ve `FotokopiÇek()` metodlarını da uygulamak zorunda kalır. Bu, prensibin açık bir ihlalidir. ISP'ye uygun çözüm, tek, büyük arayüzü, `Yazıcı`, `Tarayici`, `FaksMakinesi` ve `FotokopiMakinesi` gibi daha küçük ve özelleşmiş arayüzlere bölmektir.

  • Yüksek Bağlanırlık (High Cohesion): Her arayüz, birbiriyle yakından ilişkili metodları gruplar, tek bir tutarlı sorumluluk tanımlar.
  • Zayıf Bağımlılık (Loose Coupling): İstemci sınıflar, yalnızca gerçekten ihtiyaç duydukları metodlara sahip arayüzlere bağlı hale gelir.
  • Kod Temizliği: "NotImplementedException" gibi geçici çözümler veya boş metod implementasyonları ortadan kalkar.

Bu prensibin uygulanması, sistemdeki gereksiz bağımlılıkları ortadan kaldırarak modüllerin birbirinden daha bağımsız hale gelmesini sağlar. Değişiklikler daha iyi izole edilir; örneğin, faks gönderme protokolündeki bir değişiklik, sadece `FaksMakinesi` arayüzünü uygulayan sınıfları etkiler, yazıcı veya tarayıcı sınıflarını etkilemez. ISP, özellikle büyük ölçekli sistemlerde ve harici API'ların tasarımında kritik bir rol oynar ve sürdürülebilir bir yazılım mimarisi oluşturmanın temel taşlarından biridir.

Bağımlılıkların Ters Çevrilmesi

Bağımlılıkların Ters Çevrilmesi İlkesi (Dependency Inversion Principle - DIP), üst seviye modüllerin alt seviye modüllere bağlı olmaması gerektiğini, her ikisinin de soyutlamalara bağlı olması gerektiğini belirtir. Aynı zamanda, soyutlamaların ayrıntılara değil, ayrıntıların soyutlamalara bağlı olması gerektiğini vurgular. Bu ilke, geleneksel katmanlı mimarideki "yukarıdan aşağıya" bağımlılık akışını tersine çevirerek, sistemin merkezine soyutlamaları yerleştirir.

DIP'nin amacı, yazılım modülleri arasındaki sıkı bağlanmışlığı (tight coupling) azaltmak ve esnek, test edilebilir ve değişime dirençli sistemler oluşturmaktır. Üst seviye modüller (iş mantığı politikaları), alt seviye modüllere (veritabanı erişimi, dosya sistemi işlemleri, harici servis çağrıları gibi uygulama ayrıntıları) doğrudan referans verdiğinde, bu ayrıntılardaki bir değişiklik, iş mantığını da etkilemek zorunda kalır. Bu, açık-kapalı ilkesinin ihlalidir. DIP, bu bağımlılığı keserek, her iki seviyenin de paylaşılan bir soyutlamaya (interface veya abstract class) bağlı olmasını sağlar.

Pratikte DIP, genellikle Bağımlılık Enjeksiyonu (Dependency Injection - DI) deseni ile birlikte uygulanır. İstemci sınıf, ihtiyaç duyduğu bağımlılıkların somut sınıflarını kendisi oluşturmak (`new` operatörü ile) yerine, bu bağımlılıkların soyut tiplerini constructor, metod parametresi veya setter üzerinden dışarıdan alır. Bu sayede, istemci sınıfın hangi somut implementasyonla çalışacağına karar verme sorumluluğu, sınıfın dışına (bir "composer" katmanına veya bir IoC konteynerine) taşınır. 

// DIP Uygulanmamış - Üst Seviye Modül, Alt Seviye Modüle Doğrudan Bağımlı
class OrderService {
    constructor() {
        this.repository = new MySqlOrderRepository(); // Somut bağımlılık
    }
    // ... iş mantığı
}

// DIP Uygulanmış - Her İkisi de Soyutlamaya Bağlı
class OrderService {
    constructor(orderRepository) { // Soyut bağımlılık (interface/abstract class)
        this.repository = orderRepository;
    }
    // ... iş mantığı (değişmedi)
}
// OrderRepository bir interface'dir.
// MySqlOrderRepository ve MongoOrderRepository onu uygular.
// Bağımlılık, uygulama kökünde (composition root) enjekte edilir.
Katman Geleneksel Bağımlılık DIP ile Ters Çevrilmiş Bağımlılık
İş Mantığı (Üst Seviye) `OrderService` → `MySqlOrderRepository` (Somut) `OrderService` → `IOrderRepository` (Soyut) ← `MySqlOrderRepository` (Somut)
Veri Erişim (Alt Seviye) `MySqlOrderRepository` → `MySqlConnection` `MySqlOrderRepository` → `IDatabaseConnection` (Soyut)
Test Edilebilirlik Zor. `MySqlOrderRepository`'yi mock'lamak zordur. Kolay. `IOrderRepository` için bir mock/sahte nesne enjekte edilebilir.

Bu ilkenin uygulanması, yazılım mimarisinde derin bir esneklik sağlar. Alt seviye modüller (örneğin, veritabanı erişim katmanı, harici API client'ları), üst seviye iş kurallarından bağımsız olarak değiştirilebilir veya tamamen yeniden yazılabilir. Bu, teknoloji yığını değişikliklerini (örneğin, SQL'den NoSQL'e geçiş) büyük ölçüde kolaylaştırır. Ayrıca, birim testlerde gerçek alt seviye modüller yerine sahte (mock) nesnelerin kullanılmasını mümkün kılarak, test süreçlerini hızlandırır ve izole eder.

Prensiplerin Sentezi ve Önemi

SOLID prensipleri, bireysel olarak değerli olsalar da, asıl güçlerini birbirini tamamlayan bir bütün olarak ortaya koyarlar. Bu prensipler, nesne yönelimli tasarımın (OOD) felsefesini oluşturur ve birbirleriyle diyalektik bir ilişki içindedir. Örneğin, Tek Sorumluluk İlkesi (SRP) ile bölünmüş sınıflar, doğal olarak daha küçük ve daha özelleşmiş arayüzlere (ISP) yol açar. Bu arayüzler, Açık-Kapalı İlkesi (OCP) ve Liskov Yerine Geçme İlkesi (LSP) sayesinde güvenle genişletilebilir ve birbirinin yerine kllanılabilir. Nihayetinde, Bağımlılıkların Ters Çevrilmesi İlkesi (DIP), bu soyut ve kararlı yapıları sistemin merkezine alarak, somut ve değişken uygulama detaylarına olan bağımlılığı koparır.

Bu sentezin pratik çıktısı, yüksek düzeyde bakım yapılabilir (maintainable), test edilebilir (testable) ve ölçeklenebilir (scalable) yazılım sistemleridir. SOLID'e uygun bir tasarım, değişen iş gereksinimlerine hızlı ve düşük riskle yanıt verebilme kabiliyeti sağlar. Kod tabanı, yeni özellikler eklenirken veya mevcut özellikler değiştirilirken, kırılganlık (fragility) ve katılık (rigidity) göstermez. Ayrıca, anlaşılır (understandability) ve yeniden kullanılabilir (reusability) modüller sunar, bu da geliştirme ekibinin üretkenliğini ve işbirliğini artırır.

SOLID prensiplerinin tam olarak anlaşılması ve uygulanması, modern yazılım mimarisi pratiklerinin (Mikroservisler, Domain-Driven Design, Onion/Clean/Hexagonal Architecture) temelini oluşturur. Bu mimariler, karmaşık sistemleri yönetilebilir parçalara bölmek için SOLID'i bir kılavuz ilkeler bütünü olarak kullanır. Örneğin, Clean Architecture'daki "Dependency Rule", doğrudan DIP'nin bir tezahürüdür ve tüm bağımlılık oklarının iç katmanlardan (iş kuralları) dış katmanlara (altyapı, UI) doğru olmasını sağlar.

Tasarım Problemi İlgili SOLID Prensibi Sağlanan Çözüm / Kazanım
Bir sınıfın birden fazla nedenden dolayı sık değişmesi. Tek Sorumluluk (SRP) Sorumlulukları ayırarak değişimi yalıtır, bağlanırlığı yükseltir.
Yeni bir özellik eklemek için mevcut kodu değiştirme zorunluluğu. Açık-Kapalı (OCP) & Liskov (LSP) Soyutlamalar ile genişletmeye izin verir, mevcut kodu korur.
Bir sınıfın kullanmadığı metodları implemente etmek zorunda kalması. Arayüz Ayrımı (ISP) İnce taneli, istemciye özel arayüzler tanımlayarak bağımlılığı azaltır.
İş mantığının veritabanı/UI gibi detaylara sıkı bağlanması. Bağımlılıkların Ters Çevrilmesi (DIP) Soyutlamalara bağımlılığı merkeze alarak detaylardan bağımsızlık sağlar.

SOLID prensipleri, yazılım mühendisliğinde kaliteyi ve sürdürülebilirliği sağlamak için vazgeçilmez bir araç setidir. İlk başta soyut ve teorik görünseler de, pratikte uygulanmaları, uzun vadeli proje maliyetlerini düşürür, teknik borcu (technical debt) azaltır ve yazılımın yaşam döngüsünü uzatır. Bu prensiplere hakim olmak, bir geliştiriciden bir mimar ve tasarımcı seviyesine geçişin en önemli basamaklarından biridir.