Soru : Interface mi, Abstract Class mı?

[uparlayan]

Kısa cevaplarla geçiştirmemeniz dileğiyle;

OOP'nin dayanılmaz cazibesine kapılmış arkadaşlarımın bu iki yapıyı da bolca kullandığını tahmin ediyorum. Onlara sormak istediğim husus şu; hangisini hangi durumda neden kullanırız?

[klavye]

Sanırım bu link sizin soruya fazlasıyla yeterli bir cevap olacaktır.
http://www.tugrulhelvaci.com/?p=582

Alıntı:Sanıyorum artık, abstract sınıflar ve interface’lerle ilgili az da olsa bir fikir sahibiyiz. Bu iki birbirine yakın kullanım temelde aynı amaca hizmet etmektedir. Ancak birbirinden farklı bir sözdizimine sahiptir. Peki, biz hangi durumlarda hangisini kullanacağız ?

Bu sorunun yanıtı abstract sınıf ve interface ayrımına gidilmesinin nedenlerini izah için yeterli olacaktır. Hepimizin bildiği gibi Delphi, C# gibi diller multiple inheritance adı verilen çoklu kalıtımı desteklemezler. Ancak C++ gibi diller çoklu kalıtıma imkan sağlarlar. Bir sınıfın birden fazla atasının olması gibi bir konseptin Delphi, C# gibi dillerde olmaması belki karmaşanın önüne geçmek içindir. Ancak çoklu kalıtıma ihtiyaç duyduğumuz yerlerde olabilir. Kısa bir örnek vererek daha da anlamlandırmaya çalışalım.

[narkotik]

(21-11-2018, Saat: 19:03)uparlayan Adlı Kullanıcıdan Alıntı: Kısa cevaplarla geçiştirmemeniz dileğiyle;

OOP'nin dayanılmaz cazibesine kapılmış arkadaşlarımın bu iki yapıyı da bolca kullandığını tahmin ediyorum. Onlara sormak istediğim husus şu; hangisini hangi durumda neden kullanırız?

uparlayan hocam konu dışında bir cevap fakat bu benim kişisel merakım. Kaç tane delphi ile yazılmış proje gördüysem kodların %60 ı yapısal gidiyor diyebilirim. Ağırklı olarak sürekli veritabanı üzerinde yapılan işlemler. Tabi kişi ile alakalı bir durum ama bu delphicilerin OOP ile sorunu nedir? OOP kullanılmış dediğimde inherited form ve fii tarihinden itibaren yazılmaya başlanmış Wincontrol componentler. Her halde kolay geliyor  form açıp 2 edit bir grid koyup birde TSQL procedure, view yaz olay bitti. Yapısal koda bayılıyoruz sonra arkadan gelen tırmalıyor duruyor.

[veteran]

Kıyaslamalı soru hatalı. Eğer sınıflarının işlevlerini genişletmek bunu da dilden bağımsız yapmak istersen interface gerekir.

[trpersia]

her ikiside bir birlerine çok benzer ama çok ince bir farkı vardır.

aslında sınıflar aynı veya benzer davranışları gösterecekse interface örnek
INotificationSender
Mailsender
SmsSender gibi

Sınıflar Ortak Kod barındıracaksa abstract kullanılması gerek diye biliyorum

[emailx45]

Conceptually, the two types serve distinct purposes (of use), yet the line between them is so fine that some people believe they are ultimately the same thing!

Interface (the object's contract): determines what the object must do—after all, rules are rules! 
You don't know exactly what the object will be, but you know it must adhere to the contract!
It will contain only the structure intended for the object; (I believe there is greater strictness here)
That is why APIs make extensive use of "interfaces": they determine exactly what needs to be done, leaving no room for doubt!

Abstract Class (what the object can be...): Here, the object is known, even if only partially defined. 
Consequently, its subclasses will also be known!
It may contain code, in addition to part of the structure intended for the object;
An abstract class, on the other hand, can be somewhat "open to interpretation" and modified according to the client's wishes (we could "decorate" it to our liking).

What they have in common:
- Neither an interface nor an abstract class ever becomes the actual object in the end; instead, they serve merely as an abstraction of the potential object one wishes to use:
- Therefore, both rely on a concrete class to actually instantiate the object!
- It is also worth mentioning polymorphism here, as I believe it could be present in both cases (in the final object).

Thinking back to SOLID principles, the Dependency Inversion principle really highlights the power of interfaces—something that wouldn't carry the same weight if we used a class (whether abstract or concrete), as you would lose that sense of purpose-driven impersonality!

The same applies to Interface Segregation, where you can make extensive use of multiple interfaces—each one even more independent, yet ultimately combining to fulfill the purpose of the final contract.