question Abstract sınıf ile interface arasındaki belirgin farklar nelerdir() {

1. // @author kenan | 20 Aralık 2017

   [

   Java’da zamanla birbirine yaklaşmaya başladılar 🙂

   Prensip olarak fark olmakla beraber, pratikte sanki birbiri yerine kullanımı oluyor. Hatta çoğu zaman karıştırılıyor.

   Ben bunu iş ilanı üzerinden örneklendirmeyi seviyorum. Benim bir iş ilanım var ve sen programcı olarak başvuracaksın. Kısaca bakalım nasıl bir kodlama izleyebiliriz.

   Ilan.java
    

   public interface Programci {
       boolean universiteMezunuMu();
       void kodYaz();
       String sonMezunOlduguOkul();
      void testYaz();
   }

   Burada bir interface ile işe alacağımız programcının özelliklerini belirliyoruz. Yani bu yukarıda sorduğumuz sorulara cevap verebilir bir programcı olmalı. Ama nasıl cevap vereceği programcının özelliklerini ilgilendirir. Mesela universiteMezunuMu() sorusunun cevabı bazısı için evet, bazısı içinse hayır. Ya da kodYaz() komutu senin nasıl kod yazdığınla ya da hangi dilde kod yazdığına bakmaz. Kod yazmanı bekler. İyi yazdı, kötü yazdı onlar hep gerçekleştirim detayları. Interface kullanımı örneği bu oluyor. Yani gerçekleştirimden(implementation) bağımsız çalışmanı sağlar.

   Programcı arayüzünü gerçekleştiren iki sınıf olduğunu varsayalım. Birincisi Mühendis ikincisi Teknisyen. Bu ilanınında muhattabı Erkan olsun. Programcı erkan = new Mühendis(); dediğim zaman elimde erkan adında bir mühendis olur. Bu mühendis de programcı arayüzünü gerçekleştirdiği için programcılık yetisine sahip olur. Bu durumda ben erkan.kodYaz() diyebilirim, yazmasını beklerim. Buna nazaran Programcı kenan = new Teknisyen(); dediğim zaman ben Meslek lisesi mezunu bir insan olarak kenan.universiteMezunuMu() sorusuna senden farlı cevap beklemem normal. Kimin yaptığı işleri daha iyi gerçekleştirdiği ise tamamen mühendis/teknisyen vasıflarındaki sınıfların nasıl yazıldığı, nasıl gerçekleştirildiğiyla alakalı.

   Inteface anlaşılır sanıyorum.

   Abstract sınıf için ise aşağıdaki gibi bir yapı kuralım.

   Muhendis.java
    

   public abstract class Muhendis {
      void hesapla() {......};
     abstract void sorunuCoz();
   }

   Burada durum farklı. Keza bu yeterli değil.

   BilgisayarMuhendisi.java

   public class BilgisayarMuhendisi extends Muhendis {
      void sorunuCoz(){......}
   }

   MatematikMuhendisi.java
    

   public class MatematikMuhendisi extends Muhendis {
      void problemiCoz() {.......}
   }

   Burada baktığında elimizde temel bir mühendislik eğitimi alan bir insan olduğunu düşünelim. Bütün mühendisliklerde (okulda) ilk iki sınıfın ders programları büyük oranda örtüşür. Bu da hesapla olsun. Yani hepsi birşeyleri hesaplama bilgisine sahiptir. Ama eğitimi devam ettiği zaman sorunCoz() özelliği farklılık gösterir. Bir matematik mühendisi daha çok matematiksel konuları/soruları çözmekle ilgilenirken, bilgisayar mühendisi yazılım/donanım sorunlarını çözme yetisine sahip olması beklenir. O yüzden bu ikisinin sorunCoz özelliğinin gerçekleştirimi farklılaşır. 4 yıllık bir proje gibi düşünelim. Birinci yılında öğrencimizi bir şekle sokuyoruz. Diyoruz ki bir mühendis hesaplamalı, problem çözmeli. İlk aşamalarda hesaplama detaylarını gerçekleştirebiliriz. Ama ilerleyen zamanlarda bize bir fakültede yaklaşık 10 farklı bölüm var. Bizim gerçekleştiremeyeceğimiz özellikleri onlar gerçekleştirsin diyerek soyut kavram(abstract) olarak bırakabiliriz.

   İlk iki sınıfı okumuş ama diğer sınıfları okumamış mühendis tek tip olur dersek (biraz hayal ürünü ilerleyeceğim), bizim mühendis sınıfımız aslında hep aynı özelliklerden, aynı metodlardan faydalanır. O zaman yeni örnekler yapamayız (instance). Yani doğal olarak single instance üzerinden ilerleriz. Bu da abstract sınıfların başka bir özelliğini verir: new diyerek yeni instance yaratılamaz. Doğal singleton çalışır.

   Burada kalkar programcılığı abstract sınıf olarak tanımlayıp diğerlerini burdan türetme yoluna gidersen, kurduğun yapı senin kafanda geçen bir yapı olur. Doğru mu olur, yanlış mı olur o kısımlar tartışılabilir. Her zaman kesin doğru, kesin yanlış olmadığını düşünürsek 🙂

   Aynı zamanda bir MatematikMühendisi’nin programcı olmasını da istersen “class MatematikMuhendisi implements Programcı” da diyebilirsin.

   Genel anlamda neden interface var neden abstract sınıf var, cevabı bu olabilir sanıyorum.

   ]
   1. // @author erkanerkisi | 20 Aralık 2017

      [

      Teşekkürler 🙂

      ]

// Comments are closed.