Yazılım Tasarımında Ustalık: SOLID'in Ötesindeki Kavramlar

• Static Metotlar: Sınıfın bir nesnesini gerektirmeden doğrudan çağrılabilen metotlardır (SinifAdi.StaticMetot()). Genellikle belirli bir nesnenin durumuna bağlı olmayan yardımcı (utility) fonksiyonlar veya fabrika (factory) metotları için kullanılırlar. Static metotlar, sınıfın static olmayan (instance) üyelerine doğrudan erişemezler.
• Static Alanlar/Özellikler: Sınıfın tüm nesneleri tarafından paylaşılan tek bir kopyası olan değişkenlerdir. Sabit değerleri veya sınıf genelinde tutulması gereken sayaç gibi durumları saklamak için kullanılabilirler.
• Static Sınıflar: Sadece static üyeler içeren ve nesnesi oluşturulamayan sınıflardır (Örn: C#'daki System.Math, System.Console).
• Static Yapıcı Metot (Static Constructor): Sınıfın static üyelerini başlatmak veya sınıf ilk kez kullanıldığında sadece bir kez çalıştırılması gereken işlemleri yapmak için kullanılır.

using System;

public static class MatematikYardimcisi // Static sınıf
{
    public static readonly double PI = 3.14159; // Static sabit benzeri özellik

    public static int KareAl(int sayi) // Static metot
    {
        return sayi * sayi;
    }
}

public class Oyuncu
{
    public string Ad { get; set; }
    public static int ToplamOyuncuSayisi { get; private set; } = 0; // Static alan

    static Oyuncu() // Static constructor
    {
        Console.WriteLine("Oyuncu sınıfı yükleniyor...");
    }

    public Oyuncu(string ad)
    {
        this.Ad = ad;
        ToplamOyuncuSayisi++;
        Console.WriteLine($"{ad} katıldı. Toplam oyuncu: {ToplamOyuncuSayisi}");
    }
}

// Kullanım:
Console.WriteLine($"Pi: {MatematikYardimcisi.PI}");
Console.WriteLine($"Kare(5): {MatematikYardimcisi.KareAl(5)}");

Oyuncu o1 = new Oyuncu("Can"); // Static constructor burada çalışır
Oyuncu o2 = new Oyuncu("Ece");
Console.WriteLine($"Toplam Oyuncu: {Oyuncu.ToplamOyuncuSayisi}"); // Static alana erişim
                    

Kullanım Senaryoları: Yardımcı fonksiyonlar (utility methods), sabit değerler (constants), fabrika metotları (factory methods), singleton deseni, sayaçlar gibi sınıfın geneline ait durumlar.

Dikkat Edilmesi Gerekenler:

• Global Durum Riski: Static değişkenler global değişkenler gibi davranabilir, bu da durumu takip etmeyi zorlaştırır ve yan etkilere yol açabilir.
• Test Edilebilirlik Zorluğu: Static bağımlılıkları mocklamak zordur, bu da birim testleri karmaşıklaştırır.
• OOP İhlali Potansiyeli: Aşırı kullanımı nesne yönelimli yaklaşımı zayıflatabilir.
• Thread Güvenliği: Birden fazla thread'in aynı anda static değişkenlere erişmesi durumunda ek senkronizasyon gerekebilir.

Static üyeler dikkatli kullanılmalı, mümkün olduğunca nesne örnekleri tercih edilmelidir.

Karmaşıklığı yönetmek, modülerlik sağlamak, yeniden kullanılabilirliği artırmak, bakım kolaylığı sağlamak, takım çalışmasını kolaylaştırmak ve test edilebilirliği iyileştirmektir.

• Katmanlı Mimari: En yaygın uygulamadır. Tipik katmanlar:
  • Sunum Katmanı (UI): Kullanıcı etkileşimi.
  • İş Mantığı Katmanı (BLL): Uygulama kuralları ve süreçleri.
  • Veri Erişim Katmanı (DAL): Veritabanı veya diğer veri kaynakları ile etkileşim.
  Bağımlılık genellikle tek yönlüdür (UI -> BLL -> DAL).
• MVC (Model-View-Controller): Web uygulamalarında yaygındır (Model: Veri/Mantık, View: Sunum, Controller: Akış Kontrolü).
• MVVM (Model-View-ViewModel): Özellikle UI geliştirmede kullanılır.
• Mikroservis Mimarisi: SoC'nin ileri düzey uygulamasıdır.
• Fonksiyon Seviyesi: Tek bir fonksiyonun tek bir iş yapması.

// Katmanlı Mimari Konsepti (Basit Örnek)

// --- Veri Erişim Katmanı (DAL) ---
public interface IKullaniciRepository
{
    Kullanici Getir(int id);
    void Kaydet(Kullanici k);
}
public class SqlKullaniciRepository : IKullaniciRepository // Somut DAL
{
    public Kullanici Getir(int id) { /* ... SQL ile kullanıcı getir ... */ return new Kullanici(); }
    public void Kaydet(Kullanici k) { /* ... SQL ile kullanıcı kaydet ... */ }
}

// --- İş Mantığı Katmanı (BLL) ---
public class KullaniciServisi
{
    private readonly IKullaniciRepository _repository;
    // DI ile DAL bağımlılığı alınır (SoC ve Gevşek Bağlılık)
    public KullaniciServisi(IKullaniciRepository repository) { _repository = repository; }

    public bool KayitOl(string ad, string email)
    {
        if (string.IsNullOrWhiteSpace(ad) || !email.Contains("@")) return false;
        // ... diğer iş kuralları ...
        Kullanici yeniKullanici = new Kullanici { Ad = ad, Email = email };
        _repository.Kaydet(yeniKullanici); // DAL'ı kullan
        return true;
    }
}

// --- Sunum Katmanı (UI - Örn: Web Controller) ---
public class HesapController // : Controller (ASP.NET Core)
{
    private readonly KullaniciServisi _servis;
    // DI ile BLL bağımlılığı alınır
    public HesapController(KullaniciServisi servis) { _servis = servis; }

    public string Kayit(string kullaniciAdi, string eposta) // Action Metodu
    {
        bool sonuc = _servis.KayitOl(kullaniciAdi, eposta); // BLL'yi kullan
        return sonuc ? "Kayıt Başarılı" : "Kayıt Başarısız"; // View döndürülür
    }
}

// Model Sınıfı
public class Kullanici { public int Id { get; set; } public string Ad { get; set; } public string Email { get; set; } }
                      

Bir sınıfın, ihtiyaç duyduğu nesneleri (bağımlılıkları) kendisi oluşturmak yerine, bu nesnelerin ona dışarıdan sağlanmasıdır. Amacı sınıflar arasındaki bağımlılıkları azaltmak (gevşek bağlılık), test edilebilirliği artırmak, esnekliği ve değiştirilebilirliği sağlamaktır.

1. Constructor Injection: En yaygın ve önerilen yöntem. Bağımlılıklar yapıcı metot parametresi olarak alınır. Nesnenin ihtiyaç duyduğu her şeyin başlangıçta sağlanmasını garanti eder.
2. Setter Injection: Bağımlılıklar public özellikler (properties) veya metotlar aracılığıyla nesne oluşturulduktan sonra atanır. İsteğe bağlı bağımlılıklar için kullanılır.
3. Interface Injection: Nesne, bağımlılıklarını alabilmek için özel bir arayüzü uygular. Daha az yaygındır.

Örnekler önceki bölümde (SoC örneği ve SOLID DIP örneği) verilmiştir.

Büyük uygulamalarda nesne oluşturma, bağımlılık çözümleme ve yaşam süresi yönetimi işini otomatikleştiren araçlardır.

Görevleri:

• Servis Kaydı (Registration): Arayüz-sınıf eşleştirmelerini ve yaşam sürelerini (Transient, Scoped, Singleton) tanımlama.
• Bağımlılık Çözümleme (Resolution): Bir nesne istendiğinde, gerekli tüm bağımlılıkları otomatik olarak oluşturup enjekte etme.
• Yaşam Süresi Yönetimi (Lifetime Management): Nesnelerin ne zaman oluşturulup yok edileceğini yönetme.

Örnekler: Microsoft.Extensions.DependencyInjection (ASP.NET Core yerleşik), Autofac, Ninject.

Bir sınıfın başka bir sınıfın üyelerini devralmasıdır. "Bir ...dır" ilişkisini modeller. Kod tekrarını azaltır ancak sınıflar arasında sıkı bağlılık yaratabilir.

Bir sınıfın başka sınıfların nesnelerini kendi içinde barındırmasıdır. "Bir ...a sahiptir" veya "... kullanır" ilişkisini modeller. Daha esnektir ve gevşek bağlılık sağlar.

Genel prensip, kalıtım yerine kompozisyonu tercih etmektir. Kompozisyon daha fazla esneklik sunar ve kalıtımın getirdiği sıkı bağlılık risklerini azaltır. Kalıtım, sadece gerçekten güçlü bir "is-a" ilişkisi olduğunda ve LSP'ye uyulduğunda düşünülmelidir.

# Kompozisyon Örneği (Python)
class YayinMotoru:
    def yayinla(self, mesaj): print(f"Yayınlanıyor: {mesaj}")

class Depolama:
    def kaydet(self, veri): print(f"Kaydediliyor: {veri}")

class BlogYazisi:
    def __init__(self, baslik, icerik):
        self.baslik = baslik
        self.icerik = icerik
        # Kompozisyon: BlogYazisi, yayinlama ve depolama işlevlerini
        # başka nesneleri kullanarak sağlar.
        self._yayinlayici = YayinMotoru()
        self._depolayici = Depolama()

    def yayinla(self):
        self._yayinlayici.yayinla(f"{self.baslik} - {self.icerik}")

    def kaydet(self):
        self._depolayici.kaydet(self.icerik)

# yazi = BlogYazisi("Yeni Başlık", "İçerik...")
# yazi.yayinla()
# yazi.kaydet()
# Kalıtım yerine (class BlogYazisi(YayinMotoru, Depolama): ...) kompozisyon kullanıldı.
                    

Modüller birbirlerinin iç detaylarına yakından bağımlıdır. Değişiklikler kolayca yayılır, yeniden kullanım ve test zorlaşır. Genellikle kaçınılması gereken bir durumdur.

Modüller birbirleri hakkında minimum bilgiye sahiptir ve etkileşimleri iyi tanımlanmış arayüzler üzerinden olur. Esneklik, bakım kolaylığı, yeniden kullanılabilirlik ve test edilebilirliği artırır. Hedeflenen durumdur. Arayüzler, DI, olaylar gibi tekniklerle sağlanır.

Daha önceki SoC ve DIP bölümlerindeki örnekler gevşek bağlılığın nasıl sağlandığını göstermektedir.

Kendini Tekrar Etme. Her bilginin (kod, mantık) tek, belirgin bir temsili olmalıdır. Kopyala-yapıştır'dan kaçının. Bakımı kolaylaştırır, hata riskini azaltır. Fonksiyonlar, sınıflar, modüllerle uygulanır.

Basit Tut Aptalca. Gereksiz karmaşıklıktan kaçının. En basit çözüm genellikle en iyisidir. Anlaşılabilirliği, bakımı ve hızı artırır, hata riskini azaltır.

Ona İhtiyacın Olmayacak. Şu anda gerçekten ihtiyaç duyulmayan işlevselliği eklemeyin. "Belki lazım olur" diyerek kod eklemekten kaçının. Gereksiz çabayı, karmaşıklığı önler ve odaklanmayı sağlar.

DIP bir tasarım prensibidir (soyutlamalara bağımlı ol), DI ise bu prensibi uygulamanın bir yoludur (bağımlılıkları dışarıdan verme). DI, DIP'yi hayata geçirerek gevşek bağlılık sağlar.

SoC daha genel ve mimari düzeydedir (sistemi ilgi alanlarına ayırma), SRP ise daha spesifik ve sınıf düzeyindedir (bir sınıfın tek sorumluluğu olması). İyi bir SoC uygulaması genellikle SRP'yi de teşvik eder. SRP, SoC'nin sınıf seviyesindeki bir yansımasıdır.

Birim Test: Yazılımın en küçük test edilebilir parçalarının (metot/sınıf) izole olarak test edilmesidir.

Prensiplerin Katkısı:

• SRP/SoC: Odaklı birimleri test etmek daha kolaydır.
• Gevşek Bağlılık (DIP/DI): Bağımlılıkları sahte (mock) nesnelerle değiştirmeyi kolaylaştırır, böylece birimler izole olarak test edilebilir. Testler harici sistemlere (veritabanı, ağ) bağımlı olmaz, daha hızlı ve güvenilir çalışır.
• LSP: Üst sınıf/arayüz üzerinden yapılan testlerin alt sınıflar için de geçerli olmasını sağlar (veya beklenir).
• ISP: Küçük arayüzler için sahte nesneler oluşturmak daha basittir.

İyi tasarlanmış (bu prensiplere uyan) kod, neredeyse her zaman daha kolay test edilebilir koddur.

// Önceki DI bölümündeki test örneği, prensiplerin
// test edilebilirliğe katkısını göstermektedir.
// Mock ve Mock kullanımı,
// SiparisIsleyici sınıfının gerçek veritabanı veya bildirim
// sistemine ihtiyaç duymadan test edilmesini sağlar.
// Bu, DI ve DIP sayesinde mümkün olmaktadır.