Abstract Class ve Interface: OOP Dünyasında Derin Bir Yolculuk

Hem abstract class'lar hem de interface'ler, OOP'de soyut kavramları veya tamamlanmamış şablonları temsil ederler. Bu nedenle, new anahtar kelimesi kullanılarak doğrudan bir abstract class veya interface örneği oluşturulamaz. Derleyici bu tür bir girişime izin vermez (örneğin, C#'ta "CS0144: Cannot create an instance of the abstract class or interface 'TypeName'" hatası alınır).

Neden Örneklenemezler?

• Abstract Class'lar: Genellikle en az bir abstract (yani gövdesiz) üye içerirler. Bu üyelerin implementasyonu türetilmiş sınıflara bırakılmıştır. Gövdesi olmayan bir metodun nasıl çağrılacağı belirsiz olduğundan, bu tür "eksik" bir sınıftan nesne yaratmak mantıksal olarak mümkün değildir. Tüm üyeleri somut olsa bile, eğer sınıf abstract olarak işaretlenmişse, tasarımcının niyetinin ondan doğrudan nesne yaratılmaması, sadece bir temel (base) olarak kullanılması olduğu anlaşılır.
• Interface'ler: Geleneksel olarak (C# 8 öncesi), interface'ler hiçbir implementasyon içermezler; sadece metot imzaları, property'ler, event'ler ve indexer'lar gibi bir "sözleşme" tanımlarlar. İçinde hiçbir davranışsal mantık barındırmayan bir yapıdan nesne oluşturmanın bir anlamı yoktur. C# 8 ile gelen default metotlar implementasyon içerse de, interface'in temel amacı hala bir sözleşme tanımlamaktır ve doğrudan örneklenememe kuralı devam eder.

Abstract class ve interface arasındaki en temel ve belirleyici farklardan biri, bir sınıfın onlardan nasıl kalıtım alabildiğidir. Bu fark, tasarım esnekliği açısından ciddi sonuçlar doğurur.

Abstract Class: Tek Sınıf Kalıtımı (Single Class Inheritance)

• C# ve Java gibi birçok popüler OOP dili, bir sınıfın yalnızca bir başka sınıftan (abstract veya concrete) doğrudan kalıtım almasına izin verir. Bu kural, "tekli sınıf kalıtımı" olarak bilinir.
• Neden Tek Kalıtım? Bu kısıtlamanın temel nedeni, "Elmas Problemi" (Diamond Problem) olarak bilinen potansiyel bir belirsizliği önlemektir. Eğer bir sınıf, aynı metodu farklı şekillerde implemente eden iki ayrı sınıftan kalıtım alabilseydi, derleyici veya çalışma zamanı hangi implementasyonun kullanılacağını bilemezdi. Bu durum karmaşıklığa ve öngörülemez davranışlara yol açardı. Tekli sınıf kalıtımı bu belirsizliği ortadan kaldırır.
• Sonuçları: Bir sınıf hiyerarşisi tasarlarken, bir sınıfın temel kimliğini ("is-a" ilişkisi) en iyi temsil eden tek bir abstract (veya concrete) sınıfı seçmeniz gerekir. Örneğin, bir Kopek sınıfı Hayvan abstract sınıfından kalıtım alabilir, ancak aynı anda hem Hayvan hem de Oyuncak sınıfından kalıtım alamaz (eğer ikisi de sınıf ise). Bu, tasarımda bazen kısıtlayıcı olabilir.

Interface: Çoklu Arayüz Implementasyonu (Multiple Interface Implementation)

• Aynı diller (C#, Java vb.), bir sınıfın birden fazla interface'i aynı anda implemente etmesine izin verir.
• Neden Çoklu Implementasyon? Geleneksel olarak interface'ler implementasyon içermediği için (sadece metot imzaları), Elmas Problemi burada ortaya çıkmaz. Bir sınıf, farklı interface'lerden gelen aynı imzaya sahip metotları implemente etmek zorunda kalsa bile, implementasyonun kendisi o sınıfa aittir ve bir belirsizlik oluşmaz. (C# 8 default metotları bu durumu biraz karmaşıklaştırsa da, çözümler mevcuttur, örneğin explicit interface implementation).
• Sonuçları: Interface'ler, bir sınıfa farklı "yetenekler" veya "roller" kazandırmak için son derece esnek bir mekanizma sunar. Bir sınıfın ne "olduğu" (abstract class ile tanımlanan kimlik) dışında, ne "yapabildiğini" (interface'ler ile tanımlanan yetenekler) de tanımlayabiliriz. Örneğin, bir AkilliTelefon sınıfı Hayvan sınıfından türeyemez ama ICallable (aranabilir), IBrowsable (gezilebilir), ITakePicture (fotoğraf çekebilir), IPlayMusic (müzik çalabilir) gibi birden fazla interface'i implemente ederek çok yönlü bir nesne haline gelebilir. Bu, yeteneklerin kompozisyonuna olanak tanır ve daha modüler tasarımlar sağlar.

Bu temel fark, genellikle "Abstract class 'is-a' (bir türüdür) ilişkisini, interface 'can-do' (yapabilir) veya 'has-a' (sahiptir) ilişkisini modeller" şeklinde özetlenir. Bir Kopek bir Hayvan'dır (is-a), ama aynı zamanda IKuyrukSallayabilir (can-do) yeteneğine de sahip olabilir.

İki yapı arasındaki bir diğer kritik ayrım, içerebilecekleri üye türleri ve bu üyelerin implementasyon durumlarıdır.

Interface: Sözleşme Odaklı Üyeler

• Geleneksel (C# 8 Öncesi): Interface'ler sadece üye imzalarını tanımlayabilirdi:
  • Metot imzaları (gövdesiz)
  • Property imzaları (get/set blokları gövdesiz)
  • Event imzaları
  • Indexer imzaları
  Kesinlikle implementasyon (metot gövdesi, property'ler için otomatik veya özel get/set mantığı) içeremezlerdi. Alanlar (fields), yani sınıfın durumunu tutan değişkenler, asla tanımlanamazdı. Tüm üyeler varsayılan olarak public kabul edilir ve erişim belirleyici yazılamazdı.
• Modern (C# 8 ve Sonrası): C# 8 ile birlikte interface'lere önemli yenilikler geldi:
  • Default Implementations (Varsayılan Uygulamalar): Interface'ler artık metotlar ve property'ler için varsayılan (gövdeli) implementasyonlar içerebilir. Bu, bir interface'e yeni bir üye eklendiğinde, mevcut tüm implemente eden sınıfların kırılmasını önlemek amacıyla eklenmiştir. Eğer implemente eden sınıf bu yeni metodu override etmezse, default implementasyon kullanılır.
  • Static Üyeler: Interface'ler artık static metotlar, property'ler, event'ler ve hatta static constructor'lar içerebilir. Bu, yardımcı metotları veya fabrika desenlerini doğrudan interface içinde tanımlamayı sağlar.
  • Erişim Belirleyiciler (Kısıtlı): Default implementasyonlar ve static üyeler için public, private, protected, internal gibi erişim belirleyiciler kullanılabilir. Ancak, geleneksel sözleşme üyeleri (gövdesiz olanlar) hala public kabul edilir.
  Bu yenilikler interface'leri daha güçlü hale getirse de, temel amacının hala bir "sözleşme" tanımlamak olduğu unutulmamalıdır. Durum (state), yani alanlar (fields), hala interface'lerde doğrudan tanımlanamaz.

Abstract Class: Esnek Üye Tanımları ve Kısmi Uygulama

• Abstract class'lar, üye tanımlama konusunda çok daha fazla esneklik sunar:
  • Abstract Üyeler: abstract anahtar kelimesi ile işaretlenmiş, gövdesi olmayan üyeler (metotlar, property'ler, event'ler, indexer'lar). Bunlar, türetilmiş sınıflar tarafından zorunlu olarak implemente edilmelidir (override edilmelidir).
  • Concrete (Somut) Üyeler: Gövdesi olan, normal metotlar ve property'ler. Bunlar türetilmiş sınıflar tarafından doğrudan kullanılabilir.
  • Virtual Üyeler: virtual anahtar kelimesi ile işaretlenmiş, gövdesi olan üyeler. Türetilmiş sınıflar bu üyeleri isteğe bağlı olarak override ederek davranışlarını değiştirebilirler. Eğer override edilmezse, temel sınıftaki implementasyon kullanılır.
  • Alanlar (Fields): Abstract class'lar, sınıfın durumunu tutmak için normal alanlar (instance veya static değişkenler) tanımlayabilir. Bu, interface'lerin yapamadığı önemli bir özelliktir.
  • Constructor'lar: Abstract class'lar constructor (yapıcı metot) tanımlayabilir. Bu constructor'lar doğrudan new ile çağrılamasa da, türetilmiş sınıfların constructor'ları tarafından base() anahtar kelimesi ile çağrılarak temel sınıfın başlatılması için kullanılır.
  • Erişim Belirleyiciler: Abstract class üyeleri, standart sınıf üyeleri gibi public, protected, internal, private gibi tüm erişim belirleyicileri kullanabilir. Bu, kapsüllemeyi (encapsulation) daha detaylı kontrol etme imkanı sunar.
• Sonuçları: Abstract class'lar, bir sınıf hiyerarşisi için ortak bir temel oluşturmak, paylaşılan kod ve durumu (state) yönetmek ve türetilmiş sınıflara belirli implementasyonları zorunlu kılarken bazılarını isteğe bağlı bırakmak için idealdir. Bir nevi "kısmen doldurulmuş bir şablon" görevi görürler.

Implementasyon Zorunluluğu Farkı Özeti:

• Bir sınıf bir interface'i implemente ettiğinde, interface'deki tüm (varsayılan implementasyonu olmayan) üyeleri implemente etmek zorundadır.
• Bir sınıf bir abstract class'tan türediğinde, sadece temel sınıftaki abstract olarak işaretlenmiş üyeleri implemente etmek (override etmek) zorundadır. virtual üyeleri isteğe bağlı olarak override edebilir, somut üyeleri ise doğrudan kullanabilir.

Teknik farklılıkların ötesinde, iki yapının felsefi olarak temsil ettiği amaçlar da farklıdır:

Interface: Sözleşme (Contract) ve Yetenek (Capability) Tanımı

• Interface'in birincil amacı, bir sınıfın dış dünyaya karşı uyması gereken bir sözleşmeyi tanımlamaktır. Bu sözleşme, sınıfın belirli metotları, property'leri veya event'leri sağlayacağını garanti eder.
• Interface'ler, bir nesnenin belirli bir yeteneğe sahip olduğunu belirtmek için kullanılır. Örneğin, IEnumerable interface'i bir nesnenin elemanlarının döngüyle gezilebileceğini, IDisposable bir nesnenin yönetilmeyen kaynakları serbest bırakmak için bir mekanizmaya sahip olduğunu, IComparable ise bir nesnenin başka bir nesneyle karşılaştırılabileceğini belirtir.
• Bu "yetenek" odaklı yaklaşım, farklı hiyerarşilerden gelen sınıfların ortak bir davranışı paylaşmasını sağlar. Bir Dosya sınıfı da, bir VeritabaniBaglantisi sınıfı da IDisposable olabilir, ancak aralarında "is-a" ilişkisi yoktur.
• Interface'ler, sistemin farklı parçaları arasında gevşek bağlılığı (loose coupling) teşvik eder. Bileşenler, somut sınıflara değil, interface'lere bağımlı olarak tasarlandığında, implementasyon detayları kolayca değiştirilebilir veya farklı implementasyonlar takılabilir (Dependency Inversion Principle ile yakından ilişkilidir).

Abstract Class: Kimlik (Identity) ve Şablon (Template) Tanımı

• Abstract class, genellikle bir grup ilgili sınıf için ortak bir kimlik veya temel tür (base type) tanımlamak amacıyla kullanılır. Bu, güçlü bir "is-a" ilişkisini temsil eder. Kedi ve Kopek sınıfları, Hayvan abstract sınıfından türeyerek birer "Hayvan" olduklarını belirtirler.
• Ortak özellikleri (alanlar) ve davranışları (somut veya virtual metotlar) barındırarak türetilmiş sınıflar için bir şablon görevi görür. Bu, kod tekrarını (DRY prensibi) azaltır ve ortak mantığı tek bir yerde toplar.
• abstract metotlar aracılığıyla, şablonun belirli kısımlarının türetilmiş sınıflar tarafından doldurulmasını zorunlu kılar. Bu, "Template Method" tasarım deseninin uygulanmasını kolaylaştırır; temel sınıf genel algoritmanın iskeletini tanımlar, alt sınıflar ise algoritmanın belirli adımlarını özelleştirir.
• Abstract class'lar, durum (state) bilgisi taşıyabildikleri için, ortak özelliklere sahip nesneler modellemek için daha uygundur.

Özetle, "Bu nesne ne yapabilir?" sorusuna cevap arıyorsanız interface, "Bu nesne nedir ve temel ortak özellikleri/davranışları nelerdir?" sorusuna cevap arıyorsanız abstract class daha uygun bir başlangıç noktasıdır.

Nedir? C# 8'den itibaren, interface'ler içerisinde metotlar, property'ler, indexer'lar ve event'ler için varsayılan (gövdeli) implementasyonlar tanımlanabilir. Bu, abstract olmayan bir metodu bir interface içine yazabilmek anlamına gelir.

Neden Getirildi? Bu özelliğin temel motivasyonu, API evrimini kolaylaştırmaktır. Bir interface yaygın olarak kullanılıyorsa (örneğin, .NET Base Class Library'deki gibi), bu interface'e yeni bir metot eklemek, onu implemente eden mevcut tüm sınıfların kodunu kırar (çünkü yeni metodu implemente etmeleri gerekir). Default implementasyon sayesinde, interface'e yeni bir metot varsayılan bir gövdeyle eklenebilir. Mevcut sınıflar bu metodu implemente etmezse, varsayılan implementasyon kullanılır ve kodları kırılmaz. Bu, özellikle kütüphane geliştiricileri için büyük bir avantajdır. Ayrıca, Java'daki default methods veya Swift'teki protocol extensions gibi diğer dillerdeki benzer mekanizmalara uyum sağlama amacı da taşır ve "Traits" benzeri bir yapıya olanak tanır.

Sonuçları ve Tartışmalar:

• Abstract Class Benzerliği: Implementasyon içerebilme yeteneği, interface'leri abstract class'lara daha çok yaklaştırmıştır. Artık interface'ler de bir miktar davranışsal kod barındırabilir.
• Elmas Problemi Riski?: Bir sınıf, aynı default metodu farklı şekillerde implemente eden iki interface'i implemente ederse ne olur? C# bu durumu yönetmek için kurallar getirmiştir. Sınıf, çakışan metodu kendisi override etmek zorundadır, aksi takdirde derleme hatası alınır. Bu, Elmas Problemi'nin kontrol altında tutulmasını sağlar.
• Tasarım Felsefesi: Bazı geliştiriciler, bu özelliğin interface'lerin temel "sözleşme" felsefesini zayıflattığını ve kötüye kullanıma açık olduğunu savunur. Interface'lerin implementasyon detaylarından mümkün olduğunca uzak durması gerektiği düşüncesi hakimdir.
• Ne Zaman Kullanılmalı? Default metotlar, öncelikle API versiyonlama ve geriye uyumluluk sorunlarını çözmek için düşünülmelidir. İkincil olarak, bir grup ilgili interface metodu için ortak, basit bir varsayılan davranış sağlamak amacıyla kullanılabilir. Ancak, karmaşık mantık veya durum yönetimi içeren implementasyonlar için hala abstract class'lar daha uygun bir seçenektir.

C# 8 ile gelen diğer bir yenilik, interface'lerin static üyeler (metotlar, property'ler vb.) içerebilmesidir. Bu, genellikle interface ile ilgili yardımcı (utility) metotları veya fabrika (factory) metotlarını doğrudan interface'in kendisi üzerinde tanımlamak için kullanışlıdır. Örneğin, IParsable.Parse(string s) gibi bir static metot, string'i ilgili tipe parse etmek için standart bir yol sunabilir.

Ayrıca, default implementasyonlar ve static üyeler için public, private, protected gibi erişim belirleyiciler de kullanılabilir hale gelmiştir. private static metotlar, default implementasyonlar için yardımcı fonksiyonlar olarak kullanılabilirken, protected üyeler (henüz C# tarafından tam desteklenmese de gelecek versiyonlarda düşünülebilir) kalıtım senaryolarında rol oynayabilir. Bu, interface'lerin kapsülleme yeteneklerini bir miktar artırır, ancak yine de temel amaç sözleşme tanımıdır.

Önemli Not: Bu modern özelliklere rağmen, interface'ler hala doğrudan instance alanları (fields) tanımlayamazlar. Yani, nesnenin durumunu (state) doğrudan tutamazlar. Bu, abstract class'larla aralarındaki en önemli yapısal farklardan biri olarak kalmaya devam etmektedir.

• Farklı Hiyerarşilerde Ortak Yetenek Tanımlama: Birbirleriyle doğrudan "is-a" ilişkisi olmayan, farklı sınıf hiyerarşilerinden gelen nesnelere ortak bir yetenek (capability) veya rol kazandırmak istediğinizde interface idealdir. Örneğin, hem FileStream hem de NetworkStream IDisposable olabilir; hem Button hem de MenuItem IClickable olabilir; hem Customer hem de Product ISearchable olabilir.
• Çoklu "Tür" Kalıtımı İhtiyacı: Bir sınıfın birden fazla sözleşmeye uyması veya birden fazla rolü üstlenmesi gerektiğinde, çoklu interface implementasyonu tek seçenektir (çünkü tekli sınıf kalıtımı kuralı vardır). Bir ReportGenerator sınıfı hem IGeneratePdf hem de IGenerateExcel interface'lerini implemente edebilir.
• Maksimum Gevşek Bağlılık (Loose Coupling) Hedefi: Sistem bileşenleri arasındaki bağımlılıkları en aza indirmek ve implementasyon detaylarını soyutlamak istediğinizde interface'ler tercih edilir. Bileşenler birbirleriyle sadece interface sözleşmeleri üzerinden iletişim kurduğunda, bir bileşenin iç implementasyonunu değiştirmek diğerlerini etkilemez (Dependency Inversion Principle). Bu, özellikle büyük, modüler sistemlerde ve birim testlerinde (mocking/stubbing için) çok önemlidir.
• API Sözleşmesi Tanımlama: Bir kütüphanenin, framework'ün veya servisin dış dünyaya açılan public API'sini tanımlarken interface'ler standart bir yöntemdir. Bu, API'yi kullananların belirli bir implementasyona değil, kararlı bir sözleşmeye bağlanmasını sağlar.
• Değer Türleri (Structs) İçin Sözleşme: Struct'lar (değer türleri) sınıflardan kalıtım alamazlar ama interface'leri implemente edebilirler. Bu sayede struct'lara da belirli yetenekler kazandırılabilir (örneğin, IEquatable veya IComparable).
• Durum (State) Paylaşımı Gerekmediğinde: Eğer türetilmiş sınıflar arasında ortak veri veya durum paylaşımı ihtiyacı yoksa, sadece davranışsal bir sözleşme yeterliyse interface genellikle daha temiz bir çözümdür.

• Yakından İlişkili Sınıflar İçin Ortak Temel Oluşturma: Bir grup sınıf arasında net bir "is-a" ilişkisi varsa ve bu sınıflar önemli ölçüde ortak kod (metot implementasyonları) veya ortak durum (alanlar/fields) paylaşıyorsa, abstract class kod tekrarını önlemek ve ortak yapıyı merkezileştirmek için idealdir. Örneğin, Shape (Şekil) abstract sınıfı, Circle (Daire), Rectangle (Dikdörtgen) gibi sınıflar için ortak bir Color property'si veya Move(x, y) metodu sağlayabilir.
• Kısmi (Varsayılan) Implementasyon Sağlama: Türetilmiş sınıflara bazı metotlar için varsayılan bir davranış sunmak, ancak bazılarını (abstract olanları) implemente etmeye zorlamak istediğinizde abstract class kullanılır. Bu, bir algoritmanın veya sürecin genel iskeletini tanımlayıp belirli adımları alt sınıflara bırakan Template Method tasarım deseni için mükemmeldir.
• Durum (State) Yönetimi Gerektiğinde: Türetilmiş sınıfların paylaşması gereken ortak alanlar (instance variables) varsa, abstract class bunları tanımlayabilir. Interface'ler instance alanı tanımlayamaz.
• Non-public Üyelere İhtiyaç Duyulduğunda: Temel sınıfın implementasyon detaylarını gizlemek veya türetilmiş sınıflara özel yardımcı metotlar (protected) sağlamak istediğinizde abstract class'ların erişim belirleyici esnekliği avantaj sağlar. Interface üyeleri (sözleşme kısmı) genellikle public'tir.
• Versiyonlama ve Evrim Kolaylığı (Kısmen): Bir abstract class'a yeni bir somut (concrete) veya virtual metot eklemek, mevcut türetilmiş sınıfları genellikle kırmaz (çünkü implementasyon zorunluluğu getirmez). Bu, C# 8 öncesi interface'lere göre bir avantajdı. (Ancak C# 8 default metotları bu farkı azaltmıştır).
• Constructor Kontrolü: Türetilmiş sınıfların nasıl başlatılacağını kontrol etmek için constructor'lar (belki protected yapılarak) kullanılabilir.

Çoğu zaman en iyi tasarım, abstract class ve interface'lerin birlikte kullanılmasını içerir. Bir sınıf, temel kimliğini ve ortak davranışlarını bir abstract class'tan alırken, ek yetenekler veya farklı roller için bir veya daha fazla interface'i implemente edebilir.

Örnek: Bir VeritabaniLogger sınıfı, loglama mekanizmasının temel yapısını ve belki bazı ortak yardımcı metotları sağlayan bir BaseLogger abstract sınıfından türeyebilir. Aynı zamanda, tüm logger'ların uyması gereken genel loglama sözleşmesini tanımlayan ILogger interface'ini implemente edebilir. Hatta log mesajlarını formatlama yeteneği için IMessageFormatter gibi başka bir interface'i de implemente edebilir.

public abstract class BaseLogger : ILogger 
{ 
    // Ortak loglama mantığı veya yardımcı metotlar
    protected abstract void WriteLog(string message); // Alt sınıflar bunu implemente etmeli
    // ILogger'dan gelen metotların bazılarını burada implemente edebilir.
    public virtual void Log(string message) 
    {
        // belki ön işlem
        WriteLog(message);
        // belki son işlem
    }
}

public class VeritabaniLogger : BaseLogger, IMessageFormatter 
{ 
    public override void Log(string message) // BaseLogger'daki virtual metodu override ediyor
    {
        string formattedMessage = FormatMessage(message); // IMessageFormatter'dan
        WriteLog(formattedMessage); // BaseLogger'daki abstract metodu çağırıyor
    }

    protected override void WriteLog(string message) 
    { 
        Console.WriteLine($"Veritabanına yazılıyor: {message}"); 
    } 

    public string FormatMessage(string message)
    {
        return $"[{DateTime.Now}] - {message.ToUpper()}";
    }
}
                     

Bu hibrit yaklaşım, hem kod tekrarını önleme ve ortak yapı sağlama (abstract class avantajı) hem de esnek sözleşmeler ve yetenek kompozisyonu (interface avantajı) sunar.

1. "is-a" ilişkisi mi, "can-do" ilişkisi mi? Eğer sınıflar arasında güçlü bir "türüdür" ilişkisi ve ortak temel varsa -> Abstract Class düşünün. Eğer sadece bir "yeteneği yapabilir" durumu varsa -> Interface düşünün.
2. Birden fazla "tür" mü gerekiyor? Evet ise -> Interface kullanmak zorundasınız (veya kompozisyon gibi başka desenler).
3. Ortak implementasyon kodu veya durum (state) paylaşımı gerekiyor mu? Evet ise -> Abstract Class daha uygun olabilir. Hayır ise -> Interface genellikle daha iyidir.
4. Gelecekte çok farklı implementasyonlar mı bekleniyor? Evet ise -> Interface daha fazla esneklik sunar.
5. Değer türleri (structs) mi implemente edecek? Evet ise -> Interface kullanmalısınız.

Unutmayın ki bunlar katı kurallar değil, yol gösterici ilkelerdir. Bazen gri alanlar olabilir ve en iyi seçim, projenin özel bağlamına ve hedeflerine bağlıdır.

Geçmişte, interface metot çağrılarının (interface dispatch) virtual metot çağrılarına (virtual dispatch) göre küçük bir performans ek yükü olduğu konuşulurdu. Bunun nedeni, çalışma zamanının doğru interface implementasyonunu bulmak için ek bir arama yapması gerekebilmesiydi. Ancak, modern .NET (ve Java) çalışma zamanları (CLR/JVM) bu konuda oldukça optimize edilmiştir. Just-In-Time (JIT) derleyicileri, birçok durumda interface çağrılarını doğrudan veya virtual çağrılar kadar verimli hale getirebilen optimizasyonlar (örneğin, devirtualization) yapar.

Sonuç: Çoğu uygulama için abstract class ve interface arasındaki potansiyel performans farkı ihmal edilebilir düzeydedir. Performansın aşırı kritik olduğu çok nadir senaryolar dışında (örneğin, ultra düşük gecikmeli sistemler, oyun motorlarının en iç döngüleri), performans kaygısıyla interface yerine abstract class seçmek genellikle yanlış bir optimizasyondur. Tasarımın doğruluğu, esnekliği ve sürdürülebilirliği çok daha önemlidir. Performans sorunları yaşanıyorsa, bunun nedeni genellikle algoritma seçimi, veritabanı erişimi, ağ gecikmesi gibi daha büyük faktörlerdir ve bu darboğazlar profil araçlarıyla tespit edilip giderilmelidir.

Bir kütüphane veya API geliştirirken, zamanla bu API'yi geliştirme ve yeni özellikler ekleme ihtiyacı doğar. Bu noktada abstract class ve interface'lerin versiyonlama davranışları farklılık gösterir:

• Abstract Class'a Yeni Metot Ekleme: Eğer abstract class'a yeni bir somut (concrete) veya virtual metot eklerseniz, bu genellikle mevcut türetilmiş sınıfları kırmaz. Türetilmiş sınıflar bu yeni metodu implemente etmek zorunda değildir (isterlerse override edebilirler). Ancak, yeni bir abstract metot eklerseniz, mevcut tüm türetilmiş sınıfların bu metodu implemente etmesi gerekir ve bu bir "breaking change" (kırılma yaratan değişiklik) olur.
• Interface'e Yeni Metot Ekleme (C# 8 Öncesi): Geleneksel olarak, bir interface'e yeni bir metot eklemek, o interface'i implemente eden mevcut tüm sınıfların kodunu kırardı, çünkü hepsi yeni metodu implemente etmek zorunda kalırdı. Bu, interface'lerin evrimini zorlaştıran önemli bir sorundu.
• Interface'e Yeni Metot Ekleme (C# 8 ve Sonrası): Default interface methods bu sorunu çözmek için getirildi. Artık bir interface'e varsayılan bir implementasyonla yeni bir metot ekleyebilirsiniz. Mevcut sınıflar bu metodu implemente etmezse, varsayılan implementasyon kullanılır ve kodları kırılmaz. Bu, interface'lerin versiyonlanmasını çok daha kolay hale getirmiştir.

Sonuç olarak, C# 8 ve sonrası için interface'ler de versiyonlama açısından abstract class'lar kadar (hatta bazen daha) esnek hale gelmiştir. Ancak yine de, API tasarımı yaparken gelecekteki olası değişiklikleri öngörmek ve arayüzleri dikkatli tasarlamak önemlidir (örneğin, ISP'ye uymak).

Bu bölümde, abstract class ve interface kullanımını gösteren bazı C# kod örnekleri ve bunların açıklamalarını bulabilirsiniz.

Örnek 1: IPerson Arayüzü ve Person Soyut Sınıfı

// IPerson.cs - Sadece sözleşmeyi tanımlar
public interface IPerson
{
    string Name { get; set; }
    int Age { get; set; }
    string GetDetails(); // Tüm implemente eden sınıflar bunu sağlamalı
}

// Person.cs - Ortak temel ve kısmi implementasyon
public abstract class Person : IPerson
{
    public string Name { get; set; }
    public int Age { get; set; }

    // Constructor
    protected Person(string name, int age)
    {
        Name = name;
        Age = age;
    }

    // Somut metot (tüm Person türevleri için ortak)
    public virtual string Greet() // virtual: override edilebilir
    {
        return $"Merhaba, benim adım {Name}.";
    }

    // Soyut metot (IPerson'dan gelen ve türevlerin sağlaması gereken)
    public abstract string GetDetails(); 
}
                    

Burada IPerson, bir kişinin sahip olması gereken temel özellikleri (Name, Age) ve bir metodu (GetDetails) tanımlayan bir sözleşmedir. Person ise bu sözleşmeyi (kısmen) uygulayan ve aynı zamanda kendi somut (Greet) ve soyut (GetDetails) üyelerini barındıran bir temel sınıftır. Greet metodu virtual olduğu için türetilmiş sınıflar tarafından isteğe bağlı olarak ezilebilir.

Örnek 2: Employee ve Student Sınıfları

public class Employee : Person
{
    public string Department { get; set; }

    public Employee(string name, int age, string department) 
        : base(name, age) // Temel sınıfın constructor'ını çağırır
    {
        Department = department;
    }

    // Person'daki abstract GetDetails metodunun zorunlu implementasyonu
    public override string GetDetails()
    {
        return $"Çalışan: {Name}, Yaş: {Age}, Departman: {Department}";
    }

    // Person'daki virtual Greet metodunun isteğe bağlı override'ı
    public override string Greet()
    {
        return base.Greet() + $" {Department} bölümünde çalışıyorum.";
    }
}

public class Student : Person, IStudentCommands // Hem Person'dan türer hem de IStudentCommands implemente eder
{
    public string Major { get; set; }

    public Student(string name, int age, string major) : base(name, age)
    {
        Major = major;
    }

    public override string GetDetails()
    {
        return $"Öğrenci: {Name}, Yaş: {Age}, Bölüm: {Major}";
    }

    // IStudentCommands'den gelen metot
    public void Study()
    {
        Console.WriteLine($"{Name} ders çalışıyor...");
    }
}

// Ek bir yetenek için interface
public interface IStudentCommands 
{
    void Study();
}
                    

Employee ve Student, Person abstract sınıfından türemiştir, bu da onların birer "Person" olduğunu belirtir. Her ikisi de GetDetails abstract metodunu override etmek zorundadır. Employee, Greet metodunu da override ederek davranışını özelleştirmiştir. Student sınıfı ayrıca IStudentCommands interface'ini implemente ederek ek bir "Study" yeteneği kazanmıştır. Bu, hibrit kullanıma iyi bir örnektir.

Kullanım Örneği:

// Program.cs
static void Main(string[] args)
{
    IPerson emp = new Employee("Ali Veli", 30, "IT");
    IPerson std = new Student("Ayşe Kaya", 20, "Bilgisayar Müh.");

    Console.WriteLine(emp.GetDetails()); // Çalışan: Ali Veli, Yaş: 30, Departman: IT
    Console.WriteLine(emp.Greet());      // Merhaba, benim adım Ali Veli. IT bölümünde çalışıyorum.

    Console.WriteLine(std.GetDetails()); // Öğrenci: Ayşe Kaya, Yaş: 20, Bölüm: Bilgisayar Müh.
    Console.WriteLine(std.Greet());      // Merhaba, benim adım Ayşe Kaya. (Temel sınıfın Greet'i)

    if (std is IStudentCommands studentCommands)
    {
        studentCommands.Study(); // Ayşe Kaya ders çalışıyor...
    }

    // Default Interface Method Örneği (C# 8+)
    IShape circle = new Circle { Radius = 5 };
    Console.WriteLine($"Daire Alanı: {circle.CalculateArea()}");
    circle.PrintDescription(); // Default implementasyon çağrılır
}

// C# 8+ Default Interface Method örneği
public interface IShape
{
    double CalculateArea(); // Abstract-like
    void PrintDescription() // Default implementation
    {
        Console.WriteLine("Bu bir geometrik şekildir.");
    }
}
public class Circle : IShape
{
    public double Radius { get; set; }
    public double CalculateArea() => Math.PI * Radius * Radius;
    // PrintDescription'ı implemente etmek zorunda değil, default olanı kullanabilir.
    // İsterse override edebilir: public void PrintDescription() { Console.WriteLine("Bu bir dairedir."); }
}
                    

Bu örnekler, abstract class ve interface'in farklı senaryolarda nasıl kullanılabileceğini ve birlikte çalışarak esnek ve güçlü tasarımlar oluşturulabileceğini göstermektedir.