PHP’de Nesne Arayüzleri/Object Interfaces

Hüseyin Akdogan tarafından yazıldı.   

PDF olarak oku

NYP yaklaşımında, öncelikle ele alınması gereken konu/kavramları işlemeye devam ediyoruz. Hatırlayacağınız gibi bir önceki yazıda soyut/abstract sınıf ve metodları incelemiştik, bu gün ise kullanım ve iş mantığı soyut sınıflara çok benzeyen nesne arayüzlerini(object interfaces) ele alacağız.

Arayüz/Interface

Nesne arayüzleri soyut sınıf/nesnelere çok benzerler, nesne arayüzlerinin soyut sınıf/nesnelerden ayrıldıkları temel nokta, gövdeli yordamlar barındırmamaları ve içerdikleri metod ve özelliklerin public erişim belirteçine sahip olma zorunluluğudur.

Nesne arayüzlerinin sadece gövdesiz metodlar içermeleri, soyut sınıf/nesneleri ele aldığımız yazıda belirttiğimiz “birleştirici” olma özelliği hatırlanacak olursa, geliştirdiğimiz kodda böylesi bir yaklaşımı zorlamak istediğimizde başvurabileceğimiz temel aracın nesne arayüzleri olduğunu bize düşündürecektir. Temelde soyut sınıf/nesneler ile nesne arayüzlerinin amacı, gövdesiz metodlarını kendilerini genişleten/uygulayan sınıflara iptal/override ettirmektir. Dolayısıyla, sınıf/nesnelerimizin mutlaka ihtiva etmeleri gerektiğini düşündüğümüz metodlarımız varsa, soyut  sınıf/nesneler ile nesne arayüzlerine başvurarak, sınıf/nesnelerimizi buna zorlarız.

Nesne arayüzleri, interface anahtar sözcüğü ile deklare edilir/tanımlanır. Bu arayüzler implements işleci ile sınıf/nesnelere uygulanır/gerçeklenir. Yine nesne arayüzleri diğer nesne arayüzlerince genişletilebilir. Nesne arayüzlerindeki metodların tamamı, arayüzü uygulayan/implement eden sınıf/nesne içinde iptal/override edilmelidir(nese arayüzlerini uygulayan soyut/abstract sınıf/nesnelerin böyle bir zorunluluğu yoktur) ve yine bir sınıf/nesne, birden fazla arayüzü uygulayabilir.

Nesne arayüzlerine dair bilinmesi gereken temel bilgileri kısaca verdiğimize göre, konuyu kod örnekleri üzerinden incelemeye geçebiliriz.

interface Personel {
	public function tabiOlduguYasa();
}

class Memur implements Personel {
	public function tabiOlduguYasa(){
		return "657 sayılı Devlet Memurları Kanunu...";
	}
}

class Isci implements Personel {
	public function tabiOlduguYasa(){
		return "1475 sayılı İş Kanunu...";
	}
}

Kodumuzda görüldüğü üzere, Personel isminde, “interface” anahtarı ile deklare edilmiş ve tabiOlduğuYasa isminde gövdesiz bir metoda sahip bir arayüzümüz var. Personel arayüzünü iki sınıf/nesnenin, “impelements” anahtarı ile implement ettiğine yani uyguladığına ve arayüzün sahip olduğu metodu iptal/override ettiğine dikkat edin. Bu iptal/override işlemi, Personel arayüzünü uygulayan her sınıf/nesne için bir zorunluluktur.

Basit bir arayüz deklerasyon ve implementasyonunu gördüğümüze göre, tıpkı soyut sınıf/nesnelerde olduğu gibi ilk başta aklınıza gelebilecek muhtemel “peki ama neden/nerede, nesne arayüzlerini kullanayım/kullanmalıyım?” sorusunun cevabına gelelim.

Bu sorunun cevabı, soyut sınıf/nesneler için verilen cevapta olduğu gibi “birleştirici rol”ün anlam ve mahiyetinde gizlidir. Arayüzlerin oynadığı birleştirici rolü, aşağıda yer alan birazdan inceleyeceğimiz kodda görmeniz mümkündür. Önce UML diyagramına bakalım.

UML Diyagramı

Kodumuz.

interface Bitki {
    public function familya();
	public function govde();
}

interface Agac extends Bitki{
	public function yaprak();
}

interface Patates extends Bitki{
	public function renk();
}

class Kavak implements Agac{

	public function familya(){
		return "SALİCACEAE";
	}
	public function govde(){
		return "ODUNSU";
	}

	public function yaprak(){
		return "YAPRAKLI";
	}

	public function getAdi(){
		return "Kavak Ağacı";
	}
}

class Granula implements Patates {

	public function familya(){
		return "SOLANACEAE";
	}

	public function govde(){
		return "YUMRU";
	}

	public function renk(){
		return "SARI";
	}

	public function getAdi(){
		return "Granula Patates";
	}
}

class Goster {

	public function Info(Bitki $bitki){
		echo $bitki->getAdi().", Familyası: ".$bitki->familya()." Gövdesi: ".$bitki->govde()."\n";
	}

}

$goster  = new Goster;
$kavak   = new Kavak;
$granula = new Granula;

$goster->Info($kavak);
$goster->Info($granula);

Kavak Ağacı, Familyası: SALİCACEAE Gövdesi: ODUNSU
Granula Patates, Familyası: SOLANACEAE Gövdesi: YUMRU

UML diyagramı ve kodumuza baktığımızda, familya ve govde adında iki metoda sahip Bitki isimli arayüzün, Agac ve Patates arayüzlerince genişletildiğini, bu iki arayüzünden Agac’ın yaprak, Patates’in ise renk isminde birer metoda sahip olduğunu görüyoruz.

Kavak isimli sınıf/nesne Agac arayüzünü implement ederken, Granula sınıf/nesnesi ise Patates arayüzünü implement ediyor. Her iki sınıf, uyguladıkları arayüzlerin gövdesiz metodlarını iptal/override ediyor. Burada dikkat edilmesi gereken, iptal/override edilen metodlar arasında Bitki arayüzünde deklare edilen familya ve govde metodlarının da olmasıdır. Bunun sebebi, Agac ve Patates arayüzlerinin kalıtım yolu ile Bitki arayüzünden bu metodları miras almış olmalarıdır.

Kodumuzda, UML diyagramında yer almayan Goster ismindeki sınıfın info metodu, nesne arayüzlerinin oynadıkları birleştirici rolü tam olarak gözlemleyebileceğimiz yerdir.

public function Info(Bitki $bitki){
echo $bitki->getAdi().", Familyası: ".$bitki->familya()." Gövdesi: ".$bitki->govde()."\n";
}

Metodun Bitki arayüzü tipinde bir parametre aldığına dikkat edin. İşte bu sayededir ki,

$goster->Info($kavak);
$goster->Info($granula);

şeklinde bir kullanım ile, tek bir metod içinde, Bitki arayüzünü implement eden sınıf/nesnelerin, bu arayüzde gövdesiz olarak deklare edilip sınıf/nesne içinde iptal edilmiş metodlarını çağırabiliyor ve nesne özelliklerini çıktılayabiliyoruz.

Altını çizerek belirtelim ki burada gördüğümüz şey, Kavak, Patates ve bu yapıya eklenebilecek diğer bitkilerin familya, gövde ve isim bilgilerini tek bir metod içinde, nesnenin implement ettiği arayüz tipindeki değişken referansı ile çıktılanmasıdır.

Böylesi bir kullanımın, ortak kategoriler ve fakat farklı içerikler ihtiva eden yapılarda kod geliştirme sürecinde bizlere sağladığı yarar açıktır. Projeye eklenecek yeni bitkilerin farklı familya ve gövde yapılarına sahip olması ve yine bunlar dışında(örneğimizdeki yaprak, renk unsurları gibi) özelliklerinin bulunması bizim için bir sorun oluşturmayacaktır. Ortak kategorilerdeki farklı özellikleri, yine aynı yöntemle tek bir metod ve referansla çıktılayabileceğiz.