Laravel Türkiye Discord Kanalı Forumda kod paylaşılırken dikkat edilmesi gerekenler!Birlikte proje geliştirmek ister misiniz?

Dependency Injection ve IoC Container

Aaron

Merhaba. Bağımlılık enjeksiyonu (dependency injection) kullanmak istediğimizde konteyner (IoC) kullanmak bir zorunluluk değil. Çoğu dokümanda zorunluluk olmadığı halde bağımlılık enjeksiyonu kullanılan tüm sınıflar ve implementasyonlar konteyner kullanılarak bağlanmış (App::bind) ya da konteynerden çözümlenmiş (App::make). Konteyner, bağımlılık enjeksiyonunun bir gerekliliği değil fakat organize olmak açısından kullanılması tavsiye ediliyor. Benim merak ettiğim şey konteynerin bana ne fayda sağladığı.
Laravel'de bağımlılık enjeksiyonunu ve konteyneri test etmek için basit bir şey yazmaya çalıştım. Aşağıda kodları gördükten sonra öğrenmek istediğim asıl konuyu size soru olarak yönelteceğim.

Controller:

class FooController extends BaseController {
	public function __construct(FooClass $foo)
	{
 $this->foo = $foo;
	}
	public function bar($string)
	{
 return $this->foo->write($string);
	}
}

Interface:

interface FooInterface {
	public function write($string);
}

FooInterface implementasyonu:

class FooClass implements FooInterface {
	public function write($string)
	{
 return $string;
	}
}

Route:

Route::get('/foo/{string}', array('uses' => 'FooController@bar'));

Binding:

App::bind('FooInterface',function() {
	return new FooClass;
});

(Kullanımın doğru olduğuna emin değilim test etmedim. Ama implement ettiğim sınıftan implementasyonu kaldırdığımda hata dönmüyor.) Bu tip bir kullanımda App::bind yapmak zorunda değilim. Yukarıda da bahsetmiştim. Bu şekilde kullanıyor olmak bana ne sağlıyor? Misal start.php'de ya da herhangi bir yerde FooInterface bind edilmese bana kaybettireceği şey nedir? Eğer bu arayüzü kullanan sınıfı bind etmesem bile enjeksiyon gerçekleşecek. Bind ve make tam olarak ne yarar sağlıyor? Metotların ne işe yaradığını biliyorum. Asıl sorum kullandığımda ya da kullanmadığımda neyin değişeceği?

sergin

Bağımlılığın tersine çevrilmesi ilkesi, Kontrolün tersine çevrilmesi deseni, Bağımlılık enjeksiyonu ve konteynerler çoğu kere karıştırılan ve bu konudaki yazılarda verilen örneklerin kafada somutlaştırılması ve anlaşılması zor kavramlardır. Burada bir cevap olarak anlatmam da zor olacaktır. Ben sadece örneğiniz üzerinde konuşacağım. Ancak konuyla ilgili çok sayıda yazı vardır ve https://leanpub.com/laravel-4-tr (Laravel: From Apprentice To Artisan (TR) Türkçe Çevirisi) yardımcı olabilir.

Bağımlılığın tersine çevrilmesi ilkesi SOLID ilkelerinden biridir. Kontrolün tersine çevrilmesi deseni bu ilkenin uygulamaya konulmasından biridir ve Bağımlılık enjeksiyonu bu uygulamanın bir şekli olarak düşünülebilir. Konteynerler de bu işlemi kolaylaştırmanın bir yoludur.

Bağımlılığın tersine çevrilmesi ilkesinin birinci maddesi yüksek düzeyli kodun düşük düzeyli koda bağımlı olmamasını, her ikisinin de soyutlamalara bağımlı olmasını söyler. Sizin kodunuzdaki

public function __construct(FooClass $foo)

Bu satır, ilke çerçevesinde andığımız Bağımlılık Enjeksiyonu olarak kabul edilememektedir (her ne kadar bir bağımlılığı enjekte etse de). Zira bu satırda yüksek düzeyli kodunuz FooController sınıfı, düşük düzeyli kod olan FooClass sınıfına bağımlıdır ve ilkenin söz ettiğim maddesini ihlal ederek işe başlamaktadır. Dolayısıyla zaten bir konteytner ya da başka bir şey gerekli değildir. Oysa bu satır

public function __construct(FooInterface $foo)

olsaydı, yüksek düzeyli kodunuz bir soyutlamaya bağımlı olacaktı. Aynı zamanda düşük düzeyli kodunuz FooClass da bir soyutlamaya bağımlı olacaktır, Çünkü bu soyutlamayı (FooInterface) bizzat implemente etmektedir. Böylece ilkenin anılan maddesi yerine getirilmiş olacaktır.

Peki FooController sınıfı bağımlı olduğu somut sınıfı nereden bilecek?. İşte konteyner burada devreye girebilir. Tabii ki, konteyner olmadan da FooController sınıfının bağımlı olduğu FooInterface implementasyonunun FooClass olduğunu başka bir yerden tanımlayabilirsiniz. Laravel'de ise genel olarak bir servis sağlayıcı aracılığıyla tanımlamalar IoC konteynerinde kayda geçirilmekte ve sonrasını bu konteyner halletmektedir. Laravel IoC konteyneri App diye bildiğimiz şeydir ve Larave'lin parçalarını bir arada tutan, her şeyi barındıran bir kutu olarak düşünülmüştür. Gelenek olarak bağımlı sınıf çözümlemesi, çözülen sınıfın enjeksiyonu IoC konteyneri tarafından yapılmaktadır. Bunun yararlarından sadece birisi şudur. FooClass sınıfı da başka bir sınıfa bağımlı olabilir, o da başka birine. Bu durumda Konteyner dışı çözümlerde iş epey uzar. Konteyner ise bunu bizim için halledecektir.

Aaron

@sergin cevap için çok teşekkür ederim. Bahsettiğiniz kitap bende mevcut. Dependency Inversion bir gereklilik değil. Yani uygulamanızı bu ilkelere göre yapmak zorunda değilsiniz. Kafamı karıştıran nokta o kitapda bahsedilen ReflectionClass bölümü. Çünkü orada StripeBiller adındaki bir sınıf tip dayatma ile constructora eklenmiş. Belki de onun konumuz ile alakası yoktur. Söylemek istediğim şey aslında şu benim FooInterface sınıfımı implement eden birden çok sınıfım olduğunu düşünüyorum Laravel bu interfacein hangi implementasyonunu çözeceğini nasıl anlayacak? İşte konteyner burada devreye giriyor;

App::bind('FooInterface', 'FooClass');

ya da

App::bind('FooInterface', function(){
 return new FooClass;
});

yaparsak Laravel FooInterface'in çağırıldığı yerde FooClass implementasyonunu enjekte edeceğini çözümlemiş olacak. Konteyner bana bir kolaylık sağlıyor. Eğer konteyner kullanmıyorsam aynı kitapta bahsedilen şekilde

$biller = new StripeBiller(new SmsNotifier);

bağımlılık enjeksiyonunu gerçekleştirebilirim sanırım. Çünkü buradaki SmsNotifier bir BillingNotifierInterface implementasyonu. Yanlış mıyım?

sergin

Evet doğru, Konteyneri kullanmıyorsanız

$biller = new StripeBiller(new SmsNotifier);

olarak gerçekleştirebilirsiniz.

Reflection kullanarak çözümleme konusu şöyle; bir sınıfı kullanmak için başlatmak zorundayız ya her halükarda, bir yerlerde $nesne = new Sinif olacak. IoC konteynerinde kayda geçirirken

App::bind('FooInterface', function(){
 return new FooClass;
});

şeklinde değil de

App::bind('FooInterface', 'FooClass');

şeklinde belirtilmişse, bir new FooClass diye bir şey olmuyor. O zaman IoC konteyneri FooClass'ı, ReflectionClass kullanarak başlatıyor: FooClass'ı buluyor, eğer bir konstrüktür metodu varsa o zaman onun parametrelerine bakarak bağımlılıklarını da tespit ediyor, ona göre yeni bir FooClass olgusu başlatmış oluyor. Container sınıfının ilgili bir metodunu FooClass için uyarlarsak, şöyle:

$somut = 'FooClass';
$reflector = new \ReflectionClass($somut);
$constructor = $reflector->getConstructor();
//eğer bir konstrüktör metodu yoksa bağımlılığı da yoktur. Sınıfı direkt çözümleyebiliriz: 
if (is_null($constructor))
{
return new $somut ;
}
//eğer konstüktörü varsa parametrelerini, dolayısıyla bağımlılıklarını öğreniyoruz.
$parameters = $constructor->getParameters();
//Sonra da bağımlıkların her birinin olgularını başlatıyor, sınıfımıza bunları enjekte ederek sınıfımızın olgusunu da başlatıyoruz. 
$dependencies = $this->getDependencies($parameters);
return $reflector->newInstanceArgs($dependencies);

Aslında bu olay kitapta şöyle anlatılmıştır:

Laravel konteyneri bir sınıf için açıkça bağlanmış bir çözümleyiciye sahip olmadığı zaman, bu sınıfı refleksiyon aracılığı ile çözümlemeye çalışacaktır. Bu akış şuna benzer:
1. StripeBiller için bir çözümleyicim var mı?
2. Çözümleyici yok mu? Bağımlılıkları olup olmadığını tayin etmek için StripeBiller refleksiyonu kullan.
3. StripeBiller için gerekli bağımlılıkları çözümle (yinelemeli).
4. ReflectionClass->newInstanceArgs() aracılığıyla yeni StripeBiller olgusu başlat.

http://laravel.com/api/source-class-Illuminate.Container.Container.html adresini incelerseniz kafanıza takılan husus iyice aydınlanacaktır.

Aaron

@sergin benim sorun aslında nasıl yapıldığı ile alakalı değildi. Sadece konteynerin bana faydasını araştımak istiyordum. Çünkü yukarıda da belirttiğim gibi konteyner bana bağımlılıkları kolay kontrol etmeme imkan veriyor. İlk avantajı bu. Dezavantajı var mı? Bir de yukarıda verdiğiniz reflection uygulamasını Laravel otomatik olarak yapıyor şeklinde anlıyorum ve öyle olduğunu biliyorum. API'yi sürekli inceliyorum ve bu tip konular ile alakalı bir sorum daha var misal; https://laravel.gen.tr/d/356

sergin

Evet aynı şeyleri söylüyoruz (verdiğim kodun Container sınıfının bir metodunun [build metodu] bir uyarlaması olduğunu söylemiştim) ve konteyner kolaylık sağlıyor. Laravel'in kurucusu IoC konteynerinin çok önemli olduğunu söylüyor ve ondan yararlanılmasını istiyor.
Bir SınıfA nesnesi kullanabilmek için konteynerde App::bind('AInterface', 'SınıfA'); şeklinde kayda geçirmenin yeterli olacağını, konteynerin SınıfA'nın bağımlı olduğu sınıfları ve gerekirse onların da bağımlı oldukları sınıfları gerektiğinde reflection sınıfını da kullanarak otomatik olarak başlatacağında aynı fikirdeyiz.
SınıfA'nın SınıfB'ye, SınıfB'nin SınıfC ve SınıfD'ye, SınıfC'nin SınıfE'ye ve SınıfD'nin SınıfF'ye bağımlı olduğunu düşünelim. İşin geri kalan kısmı interface vs hep olduğunu varsayıyoruz.
Konteyner olmadan SınıfA'yı kullanmak için bu sefer şöyle yapacağız. Tüm sınıf bağımlılıklarını hep akılda tutmak ve
$sinifE = new SınıfE;
$sinifF = new SınıfF;
$sinifD = new SınıfD($sinifF);
$sinifC = new SınıfC($sinifE);
$sinifB = new SınıfB($sinifC, $sinifD);
$sinifA = new SınıfA($sinifB);

PHP'de nesne yönelimli programlama diğer dillerin oldukça gerisindedir. SOLID ilkelerinin geçmişi daha eskidir. Konteynerler Bağımlılık Enjeksiyonunun kimi zorluklarının üstesinden gelmek için geliştirilmiş şeylerdir, Laravel kendi konteynerine IoC adını vermiştir. Ve sanırım ben sorularınızı tam olarak anlayamıyorum. Ben size en iyisi şöyle öneride bulunsam. C# gibi .NET dillerinde bu konular yılllardır ele alınmaktadır ve o dillerde bu tür kavramlar hakkında çok daha fazla kaynak bulunmaktadır.

Aaron

@sergin yok anlaşabiliyoruz. Aslında kendiniz de söylemişsiniz;

Laravel'in kurucusu IoC konteynerinin çok önemli olduğunu söylüyor ve ondan yararlanılmasını istiyor.

Yararlanmamızı istiyor ama niçin kullanmalıyım? Sadece bana kolaylık sağlıyor diye mi?

xsearch

Benimde OOP yazarken mantığımı zorlayan bir durum var, alıştığımız bir dosya ve çok iş mantığının dışında bir yapı oluşturmak zahmetli görünüyor. O yüzden, MVC bile "niçin kullanmalıyım? sadece kolaylık sağlıyor diye mi?" diye özetlenebilir.

Ben yeni incelemeye başladığım Laravelle ilgili gördüğüm en önemli fark bu iş ayrıştırması ve yüklenilmesi durumunun ileri düzeyde desteklenmesi ve önerilmesi durumu. iOc bunun temelinde bulunuyor gördüğüm kadarı ile.

iOc'u algıladığım şekil, işi iste nasıl yapılacağına ilgili yapı karar versin.

Örnek : bir projemde kullanıcılar var.
Bu kullanıcılara erişmem gerektiğinde Eloquent modeli oluşturup, ilgili sql driveri üzerinden verilere erişebiliyorum.
Örneğin controllere Personel::all(); diye erişim sağlayabiliyorum.
fakat personel bilgileri sık değişmediği için bunları önbellek mekanizmasına yükleyip ordan almak istiyorum ki sorgular azalsın.
bu durumda verilere erişeceğim metod Eloquent'ten bağımsız olabilmeli hatta tercih hakkım olmalı, db mi cache mi vs. gibi.
bu noktada iOc bu organizasyonu yapma işini üstleniyor. ve yapılar arasında geçiş yaparken tüm kodu taramak yerine config yada gerçek zamanlı olarak seçim yapabilir duruma geliyorum.

Benim algıladığım şekli ile iOc Lokanta şefi gibi çalışıyor. İstediğiniz yemeği o şef olmadan da iletebilirsiniz. Ancak yapılan yemeğin yapılış şekli değiştiğinde örneğin lokantanız büyüdüğünde yeni işleyişi tüm personele öğretmek yere şefe öğretmek yeterli olacaktır. yemeğiniz tam zamanında sıcak ve taze önünüze gelecektir diye umuyorum.

Aaron

@xsearch cevap için teşekkür ederim. Umarım bu konuda bilgisi olan diğer arkadaşlar da paylaşımda bulunurlar.

xsearch

Biraz karışık anlattım sanırım şöyle örnekleyeyim
İlk önce bağımlılık Enjeksiyonunu kavramak önemli diye düşünüyorum. Sizin açtığınız konu ve kendimi tam anlatamadığımı düşündüğüm cevabım sonrasında Design Patterns konusuna eğildim.

Bende algılamaya çalışıyorum bir yandan bunuda belirteyim. Oluşabilecek saçma cümlelerime tahammülünüz için şimdiden teşekkür ederim.

Bağımlılık enjeksiyonu yaklaşım olarak sınıflarımızın mümkün olduğu kadar bir birine "az" mümkünse hiç bağlı kalmadan çalışabilmesi. Bu çerçevede soyut sınıflar kullanarak yapıları oluşturup alternatif senaryolara geçiş aşamasında yazdığımız yapıyı bozmadan devam etme olanağı sağlıyor.

Çok basit olarak verilen stringin karakter sayısını döndüren bir yapı istensin.
bu basit işlem için alternatif istek noktaları olması muhtemeldir. veritabanı, dosya , form v.s.
Bu talebi değerlendirip arayüzler ve sınıflarla işlemi gerçekleştirebilir olduk.

App::bind("saybakalim" , function(){
 new Saydir();
})

kodu

App::make("saybakalim");

çağrıldığında yapılacak işlemi belirliyor.
Burda bağlılıklar düzenlenebiir. Sizin verdiğiniz örnekte

App::bind('FooInterface',function() {
	return new FooClass;
});

FooInterface kullanmanız o interfaceyi çağıracağı anlamını taşımıyor oraya yazdığınız bir tanımlama yani patates te yazabilirsiniz.
siz App::make("patates"); dediğinizde de aynı işlemi yapacaktır.

Buraya kadar kullanımı anlamaya çalıştım.
Şimdi neden kullanalım.

App::bind('DbdenSay',function() {
 
 

});

diye bir koda başlayıp. bir biri ile "bağımlılığı" bulunmayan sınıfları bağlayarak istediğimiz işlemi yapabiliriz.

Yemek yemeyi seven birisi olarak şöyle örnekleyeyim.

Melemen yapacağız
Soğan , Domates , yumurta , biber bir birine bağımlılığı olmayan sınıflarımız.

App::bind("melemenYap", function(){
$sogan = new Sogan();
$sogan->getAdet(2);
$sogan-->soy();
$sogan->dogra();

.............................
}

dedikten sonra (..... ları anlayacağınızı umuyorum.

Canımız çektiğinde

App::Make("melemen");

diyerek "Bağımlı olmayan" elemanlarımızdan tek komutla melemeni yaparız.
Afiyet Olsun :)))

sineld

@xsearch tarif için teşekkürler

Aristona

xsearch yazdı

App::bind("melemenYap", function(){
$sogan = new Sogan();
$sogan->getAdet(2);
$sogan-->soy();
$sogan->dogra();

Bir yemek tarifinde solid düzenlemesi yapacağım hiç aklıma gelmezdi ancak büyük ihtimalle bu kod solid'i violate ediyor. Soğanı kesecek şey bıçaktır. Soğan kendi kendini doğrayamaz. Bu yüzden:

interface KesiciInterface {
 public function kes($neyi);
}

class Bıçak implements KesiciInterface {
 public function kes($neyi) {
 //Kesme kodları
 }
}

class Soğan implements SebzeInterface, DogranabilirInterface {
 protected $kesici;
 public function __construct(KesiciInterface $kesici)
 {
 $this->kesici = $kesici;
 }

 public function dogra() {
 $this->kesici->kes($this);
 }
}

gibi olmalı. Ayrıca bıçak kesme işlemini yapmak için bir insana ihtiyaç duyar. Bıçağa "InsanInterface" dependencysi eklenebilir.

Birde, "$sogan->getAdet(2);" yanlıştır. Bu fonksiyonda soğanın kendisini klonlayıp yeni bir soğan yaratacağını düşünebiliriz. Daha iyi bir alternatif, "SoğanContainer" (sepet?) sınıfı oluşturup 2 soğanında instancesini tutmaktır.


$sepet = new Sepet(array(new Soğan, new Soğan));
$soğan1 = $sepet->soğanAl(); //ilk soğan gitti
$soğan2 = $sepet->soğanAl(); //ikinci soğan gitti
$soğan3 = $sepet->soğanAl(); //throw new SepetBoşException;

Evet, ağır işsizim ;D ama doğrusu buna benziyor olmalı.

xsearch

Genişletilebilir bir durum.

Bıçakla doğrama zorunluluğumuzda yok ona bakarsanız özel alette kullanılabilir, o zaman doğra sınıfı yapıp doğrama araçları için interface yazıp doğrama araç sınıfları bıçak robot kesme aparatı tanımlamak gerekir.

Ateş kaynağımız nedir? soba mı , ocak mı?

SOLID prensiplerine göre melemen nasıl yapılır diye bir makale mi yazılsa nedir :))))

sergin

Bağımlılık enjeksiyonu ve IoC konteynerini önceki mesajlarımda açıklamaya çalıştım. IoC konteynerinin bağımlılık enjeksiyonunu ne kadar kolaylaştırdığını da bir miktar gösterdim, bağımlılık enjeksiyonu kullanmak için konteyner kullanmak zorunda olmadığımızı da söyledim. "Sırf bana yardımcı olacak, işlerimi kolaylaştırcak diye niye kullanayım ki?" ifadesiyle karşılaşınca daha fazla açıklama yapmamayı düşünmüştüm. Ancak gelinen aşamada konu izleyicilerine şu bilgiyi verme zorunluğu hissettim:

bind metodu IoC konteynerine bir bağlama kaydı yapmak için kullanılır. Bir soyutlamanın hangi somut sınıf olarak anlaşılması gerektiğini bildirmek içindir. Bu somut sınıftan bir olgu döndürür. Böylece, bu soyutlamanın geçtiği yerlerde o somut sınıfın bir olgusu döndürülür.

Container sınıfının make metodu ise bir soyutlama alır ve bunun temsil ettiği somut sınıfı döndürür.

xsearch

Aslında anlamakta zorlanmamızın sebebi sondan başlıyor olmamız diye düşünüyorum.

IoC u anlamak için solidi anlamak gerektiğini düşünüyorum. Benden daha deneyimli ve iyi anlatabilen birinin bu konuda makale yazması güzel olabilir.

Aaron

sergin yazdıBağımlılık enjeksiyonu ve IoC konteynerini önceki mesajlarımda açıklamaya çalıştım. IoC konteynerinin bağımlılık enjeksiyonunu ne kadar kolaylaştırdığını da bir miktar gösterdim, bağımlılık enjeksiyonu kullanmak için konteyner kullanmak zorunda olmadığımızı da söyledim. "Sırf bana yardımcı olacak, işlerimi kolaylaştırcak diye niye kullanayım ki?" ifadesiyle karşılaşınca daha fazla açıklama yapmamayı düşünmüştüm. Ancak gelinen aşamada konu izleyicilerine şu bilgiyi verme zorunluğu hissettim:

bind metodu IoC konteynerine bir bağlama kaydı yapmak için kullanılır. Bir soyutlamanın hangi somut sınıf olarak anlaşılması gerektiğini bildirmek içindir. Bu somut sınıftan bir olgu döndürür. Böylece, bu soyutlamanın geçtiği yerlerde o somut sınıfın bir olgusu döndürülür.

Container sınıfının make metodu ise bir soyutlama alır ve bunun temsil ettiği somut sınıfı döndürür.

@sergin zaten en ölümcül ve kritik nokta bu bind. Çünkü bir interfacein birden çok implementasyonu olabilir. Misal DbInterface diye bir sözleşmeniz olsun. MongoDB, CouchDB, Cassandra, Redis, Riak gibi birden fazla implementasyonunuz olabilir. Bir sınıfa bir interface enjekte ettiğinizde yani DbInferface constructor injection olarak kullanıldığında uygulama bu interface implementasyonlarından hangisinin kullanılacağını kestiremez. İşte bind burada çok önem arz ediyor. Bu görevi yerine getiriyor. Eğer

App::bind('DbInterface', function() {
	return new MongoDB();
})

şeklinde kullanırsanız. DbInterface'i enjekte ettiğiniz yerde MongoDB implementasyonunuz kullanılacak. Aynı zamanda MongoDB implementasyonuna da bir bağımlılık enjekte etmiş olabilirsiniz. Eğer MongoDB implementasyonuna bir BarInterface sözleşmesi bağlanmışsa ilk olarak ona ait olan implementasyonun çözümlenmesi gerekir. Make de bu noktada devreye giriyor.

App::bind('DbInterface', function() {
	return new MongoDB(App::make('BarInterface'));
})

App::bind('BarInterface', function() {
	return new BarImplementation();
});

App::make ile çözümlediğimiz implementasyon uygulamanızın her yerinde kullanılabilir duruma gelecektir.

sergin

Evet böyledir.