Merhaba arkadaşlar.

Zaman zaman ilk başlarda hepimizin kafasını karıştırdığına eminim bu ikilinin. 🙂 Ne zaman abstract kullanmalıyım, ne zaman interface kullanmalıyım vb. tarzı sorular.

Şimdi gelelim bu ikilinin ne olduklarına.

Bu ikili, nesne yönelimli programlamada (OOP) sınıfları soyutlamaya yarayan yöntemlerden ikisidir. Bu ikisinin ortak oldukları ve farklı oldukları yönler vardır.

Haydi bu yönlere bir göz atalım.

1) Abstract

Yazdığımız sınıflar arasında inheritance(kalıtım) uygularken kullanırız. Alt sınıflar abstract sınıfı inherit alırlar. Abstract class içindeki implement edilmiş tüm method’lar diğer class’da da geçerlidir.

Abstract classdan implement ettiğimiz bir class içerisinde, sadece abstract class içerisinde abstract olarak tanımlanmış method, property gibi vb.lerini implement etmek mecburidir. Diğer method’lar zaten tanımlıdır ve implement edilmesi mecburi değildir.

Abstract sınıflar genelde is-a ilişkilerinde kullanılır.
Örnek vermek gerekirse;

+Ferrari is-a Araba

Ferrari bir arabadır ve arabanın sahip olduğu tüm özelliklere sahiptir.

Hemen bir örnekle pekişmesini sağlayalım.

    abstract class Araba
    {
        public string Marka { get; set; }
        public int VitesSayisi { get; set; }
        // Kısacası arabaların sahip oldukları tüm ortak özellikler

        public abstract void MaximumHiz();
        // Override edilecek methodumuz çünkü her arabanın kendine özgü bir maximum hız bilgisi vardır
    }

    /// <summary>
    /// Ferrari'yi Araba sınıfımızdan inherit alıyoruz.
    /// </summary>
    class Ferrari : Araba
    {
        /// <summary>
        /// Maximum hız bilgimizi override ediyoruz ve Araba abstract sınıfımızın sahip olduğu tüm özelliklere sahip oluyor.
        /// </summary>
        public override void MaximumHiz()
        {
            Console.WriteLine("Ferrari'nin maximum hızı: 300");
        }
    }

Örneğimizden de anlaşılacağı gibi araba örneğimizden yola çıkarak “Araba” isminde bir abstract sınıf oluşturuyoruz ve “Ferrari” bu sınıfdan inherit alarak Arabaların sahip olmuş oldukları tüm ortak özelliklere sahip olmuş oluyor.

NOT: virtual keyi ilede abstract sınıf içerisinde tanımlanmış bir method, alt sınıflar tarafından override (ezilebilir) edilebilir hale getirebilmek mümkündür ve aklımızın bir köşesinde dursun bir class sadece bir abstract class’ı implemente edebilir.

Abstract sınıfın genel özelliklerini sıralayacak olursak;

  1. Kod içerisinde “new” anahtar sözcüğü ile oluşturulamazlar.
  2. Bir sınıf sadece bir abstract sınıfı inherit alabilir.
  3. Inherit alıcak sınıflar arasında genelde “is-a” ilişkisi vardır.
  4. Abstract sınıfda method ve değişkenler tanımlanabilir.

2) Interface

Interface sınıfında sadece method tanımları bulunur. İçlerine kod parçacığı yazılmaz. İçerisinde tanımlanan method tanımları bu interface’i implemente edecek diğer sınıflar tarafından implement edilmesi zorunludur.

Interfaceler başka bir interface den inherit olabilirler.
Interface’ler genelde can-do ilişkisi vardır.

Örnek vermek gerekirse;

+Ferrari can-do drive itself

Ferrari kendi kendini sürebilir (Biraz saçma bir örnek oldu ama) gibi yapabileceği ek özellikler interface olarak tanımlanıp, implemente edilebilir.

Konuyu fazla uzatmadan hemen kaldığımız basit örneğimizle devam edelim:

   /// <summary>
    /// Bazı arabalar cabriolet olabilir hepsinin ortak bir özelliği değildir.
    /// </summary>
    interface ICabrioled
    {
        void TavanTipi();
    }

    abstract class Araba
    {
        public string Marka { get; set; }
        public int VitesSayisi { get; set; }
        // Kısacası arabaların sahip oldukları tüm ortak özellikler

        public abstract void MaximumHiz();
        // Override edilecek methodumuz çünkü her arabanın kendine özgü bir maximum hız bilgisi vardır
    }

    /// <summary>
    /// Ferrari'yi Araba sınıfımızdan inherit alıyoruz ve yeniden şekillendiriyoruz. Ferrarimiz cabriolet ve ICabriolet özelliğini implemente ediyoruz.
    /// </summary>
    class Ferrari : Araba, ICabrioled
    {
        /// <summary>
        /// Maximum hız bilgimizi override ediyoruz ve Araba abstract sınıfımızın sahip olduğu tüm özelliklere sahip oluyor.
        /// </summary>
        public override void MaximumHiz()
        {
            Console.WriteLine("Ferrari'nin maximum hızı: 300");
        }

        /// <summary>
        /// ICabrioled'i implemente ettiğimiz için TavanTipi methodumuzu tanımlıyoruz.
        /// </summary>
        public void TavanTipi()
        {
            Console.WriteLine("Metal tavan");
        }
    }

Örneğimizi basit ve anlaşılır tutmaya çalışırken biraz saçmalamış olabilirim, idare edin. 🙂 Açıklamak gerekirse her aracımız cabriolet olamayacağı için bunu interface olarak tanımlamıştık. “Ferrari” gibi bir aracımızı varsaydık ve buna “ICabrioled” interface’imizi implemente ettik.

Ne demiştik? Interface’ler içerisine kod parçacıkları yazılmaz, sadece method tanımları bulunur. Bunuda gösterebilmek amaçlı sadece “TavanTipi” isminde bir tanımlama yaptık ve “Metal tavan” olarak belirttik.

Interface sınıfının genel özelliklerini sıralayacak olursak;

  1. Kod içerisinde “new” anahtar sözcüğü ile oluşturulamazlar.
  2. Bir sınıf birden fazla interface implemente edebilir.
  3. Implemente edicek sınıflar arasında genelde “can-do” ilişkisi vardır.
  4. Interface içerisine sadece boş method’lar tanımlanabilir.

Gelecek makalelerde görüşmek dileğiyle. 🙂

Gökhan Gökalp

View Comments

  • Ağzınıza sağlık çok güzel bir anlatım olmuş.Abstract class ile inreface class arasındaki farkı çok iyi idrak etmiş oldum.

  • " bir class sadece bir abstract class’ı implemente edebilir." cümledeki sadece kelimesi cümleye farklı anlam yüklemiş
    "abstract tanımlı olduğu class'a bırden fazla abstract tanımlanamaz" gibi bir cümle olması okuyucular için daha anlaşılır olur

  • Anlamadığım nokta şu, biz zaten class içinde kullanacağımız interface in method unu tanimlayamazmiyiz, mesela runable adlı interface var içindede run adlı method, runable interface sini animal classina implement ettik, bunun yerine neden animal class inin içinde kendi run methodumuxu oluşturmuyoruz farkı ne?

Recent Posts

DevEx Series 03: Laying the Azure Focused Platform Foundation for an IDP with ASO and KRO

In the first two parts of this DevEx series, I tried to show how golden…

3 weeks ago

DevEx Series 02: From Catalog to Copilots. Boosting Backstage with MCP Server

In the first part of this DevEx series, I tried to explain Platform Engineering and…

5 months ago

DevEx Series 01: Creating Golden Paths with Backstage, Developer Self-Service Without Losing Control

As an architect involved in platform engineering and DevEx transformation within a large-scale organization for…

6 months ago

Overcoming Event Size Limits with the Conditional Claim-Check Pattern in Event-Driven Architectures

{:en}In today’s technological age, we typically build our application solutions on event-driven architecture in order…

1 year ago

Securing the Supply Chain of Containerized Applications to Reduce Security Risks (Policy Enforcement-Automated Governance with OPA Gatekeeper and Ratify) – Part 2

{:tr} Makalenin ilk bölümünde, Software Supply Chain güvenliğinin öneminden ve containerized uygulamaların güvenlik risklerini azaltabilmek…

2 years ago

Securing the Supply Chain of Containerized Applications to Reduce Security Risks (Security Scanning, SBOMs, Signing&Verifying Artifacts) – Part 1

{:tr}Bildiğimiz gibi modern yazılım geliştirme ortamında containerization'ın benimsenmesi, uygulamaların oluşturulma ve dağıtılma şekillerini oldukça değiştirdi.…

2 years ago