Data Vinci 11 : Interface

Tahmini Okuma Süresi: 6 dakika

Yapabiliyor olmak, yapmayı gerektirmez. Bir kavram ile ilgili açıklama yapılırken, neden böyle yaptık , şöyle yapsak olmaz mı gibilerinden bir çok soru hasıl olur. İnterface’de object oriented programlama için bu sorulara maruz kalması en olası kavramlardan birisi. Özellikle programlama ile haşır neşir olmaya başlanılan ilk günlerde bu tarz yapıların anlaşılması daha zor oluyor. Interface bir sınıf için taslak denilecek method tanımlarını içerir, Yani bir sınıf bir interface’den türüyorsa, interface’de tanımı yapılan methodların tümünü  uygulaması(implement) gerekir. Tek bir sınıf düşünüldüğünde bu yapı mantıklı durmasa da, benzer işleri yapan sınıfların olduğu bir  yapıda bütünlük ve birbiriyle olan ilişkilerinin çizilebilmesi açısından faydalıdır. İnterface kullanımı yazılımcıya esneklik sağlar. Öyle ki aynı methodun farklı sınıflar içerisinde farklı uygulanabilmesi buna bir örnektir. Abstract sınıflara benzerliği olmasına rağmen, ayrıldıkları ne önemli nokta, birden çok extend yapılmak istenen noktalardır. Çoklu kalıtım müessesesinde bir hoş sedadır interface. Fakat çoklu kalıtım Java ve C# gibi dillerde Abstract Class’lar ile mümkün olmamaktadır.

İnterface kavramının rol aldığı Object Oriented programming yaklaşımı “Polymorphism” dir. Standartlaştırma başlığı altında, flexibility, scalability, extensibility, maintainability, reusability, testability gibi bir dizi “bility” sağlamaktadır.

Daha önceki yazılarımda “implementasyonu değil, interface’i programla” mottosuna değinmiştim. İnterface kullanımı için bu kavram cepte.

Araba süreceksen karbüratör ne iş yapıyor bilme arkadaş, bas gaza geç yaklaşımı  Implementation Hiding kavramına denk geliyor. Bu da ok.

Yine aştan çıkmaz kara nohut “Loose coupling” kavramı da interface söz konusu olduğunda akıllara gelmektedir. Özellikle servis odaklı mimaride sıklıkla kullanılır. Service Contract, Data Contract gibi yapılar interface olarak sunulur.

Buraya kadar anlattıklarım bardağın dolu tarafı idi. Boş tarafına bakacak olursak bir iki husus önemli. Interface için genellikle bir sözleşme, bir iskelet benzetmeleri yapılmakta. İhtiyaçlara göre tasarlanan interface’ler concrete sınıflarda kullanılarak çok biçimlilik sağlanıyor. Bir interface birçok sınıfa “sözleşme” sağlıyor olabilir. Fakat programlarda ihtiyaçlar her zaman sabit değildir. Interface üzerinde değişiklik yapmak pek kolay olmamaktadır. Özellikle çok fazla sayıda concrete sınıf tarafından kullanılan interface’lere herhangi bir şey eklenmeye çalışıldığında, uygulandığı tüm sınıflar üzerinde değişiklik yapmayı gerektirir. Aslında interface üzerinde bu tarz bir değişiklik yapmak çok mantıklı bir karar gibi durmuyor. Savunma olarak şunu öne sürebiliriz, sözleşmeye uymayan bir sınıf söz konusu ise, bu sınıf zaten interface’i uygulamaya uygun değil, farklı bir “sözleşme” maddesine sahip çünkü. Yani işin özeti bir interface’in sunduğu bir methodun geri dönüş tipini değiştirmem gerekiyor, ne var canım onda diyemiyoruz, özellikle uygulama senelerdir geliştiriliyor ve artık boyutları ve yapılan değişikliklerin etkileri gözle görülemiyorsa. O yüzden bu işi sınıf içerisinde implicit olarak yapmak mümkün ise o yola gitmek daha doğru olacaktır. Fakat bu kez de gidip implementasyonu programlamam gerekiyor. Shit happens! Bu gibi durumlarda belki de ihtiyacımız bu durum için interface değildir.

C# için konuşacak olursak, abstract sınıfların yerine interface kullanmayı hangi durumlarda isteriz sorusu yumru gibi oturur yüreklerimize. Çünkü büyük resmi görmeye çalışmadan bakarsan aşağı yukarı aynı işi yapıyorlar. Fuları taktığımızda ise  daha önce belirttiğim şunu görürüz. Bir sınıf başka bir sınıftan kalıtım yapabilir, fakat sadece tek bir sınıftan kalıtım yapılabilmektedir. Oysa birden çok interface’i uygulayabilmektedir. Çoklu kalıtımı interface ile sağlıyoruz peki o zaman neden abstract sınıflara ihtiyaç var. Kalıtım için interface kullandığımızda interface içerisinde yer alan methodları implemente etmek zorundayız, fakat söz konusu abstract class olduğunda böyle bir zorunluluk mevcut değil.

Dependency Injection, Inversion of Control gibi konular ileri okuma yapmak isteyen arkadaşların araştırabilecekleri konular. Arif’in Manchester’a attığı golden buraya gelmediyseniz. Interface kavramıyla ilişkili başka başlıklara da göz atmak isteyebilirsiniz. Yine interface mocking konusu da Unit Testing başlığı altında ucu interface konusuna dokunan bir kavram. Ona da bakmakta fayda var.

TL;DR

Serinin 11. yazısında interface kavramına değiniyorum. Temel kavramlarda birine değindiğim bu yazıda genel olarak  interface kullanımı ile ilgili olarak yaptığım açıklamaları içermekte, herhangi bir kodlama örneği içermemektedir. Faydalı olması dileğimle…

keep_calm

Leave a Reply

Your email address will not be published. Required fields are marked *