Inversion of Control, bakımı kolay yeniden kullanılabilir, modüler yazılım çerçeveleri oluşturmaya yardımcı olan yazılım mimarisinin genel bir tasarım ilkesidir.
Kontrol Akışının genel olarak yazılmış kitaplıktan veya yeniden kullanılabilir koddan "alındığı" bir tasarım ilkesidir.
Daha iyi anlamak için kodlamanın önceki günlerinde nasıl kod yazdığımızı görelim. Prosedürel / geleneksel dillerde, iş mantığı genellikle uygulamanın akışını kontrol eder ve genel veya yeniden kullanılabilir kodu / fonksiyonları "Aratır". Örneğin, basit bir Konsol uygulamasında, kontrol akışım, programın genel yeniden kullanılabilir işlevlere yapılan çağrıları içerebilen talimatları tarafından kontrol edilir.
print ("Please enter your name:");
scan (&name);
print ("Please enter your DOB:");
scan (&dob);
//More print and scan statements
<Do Something Interesting>
//Call a Library function to find the age (common code)
print Age
Buna karşılık, IoC ile, Çerçeveler iş mantığını "Çağıran" yeniden kullanılabilir koddur.
Örneğin, Windows tabanlı bir sistemde, düğmeler, menüler, pencereler ve iletişim kutuları gibi UI öğeleri oluşturmak için bir çerçeve zaten mevcut olacaktır. Uygulamamın iş mantığını yazdığımda, iş mantığı kodumu (bir olay tetiklendiğinde) çağıracak ve bunun tersi değil, çerçevenin olayları olurdu.
Çerçevenin kodu iş mantığımın farkında olmasa da, yine de kodumu nasıl arayacağımı bilecek. Bu, olaylar / delegeler, geri aramalar vb. Kullanılarak gerçekleştirilir. Burada Akış Kontrolü "Tersine çevrilir".
Dolayısıyla, kontrol akışını statik olarak bağlı nesneler yerine, genel nesne grafiğine ve farklı nesneler arasındaki ilişkilere bağlıdır.
Bağımlılık Enjeksiyonu, nesnelerin bağımlılıklarını çözmek için IoC prensibini uygulayan bir tasarım modelidir.
Daha basit bir deyişle, kod yazmaya çalıştığınızda, farklı sınıflar oluşturacak ve kullanacaksınız. Bir sınıf (Sınıf A) diğer sınıfları (Sınıf B ve / veya D) kullanabilir. Yani, B ve D Sınıfları A sınıfının bağımlılıklarıdır.
Basit bir benzetme bir sınıf Araba olacaktır. Bir araba, Motor, Lastikler ve diğer sınıflara bağlı olabilir.
Bağımlılık Enjeksiyonu, bağımlılıklarını (Sınıf Motoru ve sınıf Lastiği) oluşturmak için Bağımlı sınıflar (burada Sınıf Arabası) yerine, sınıfın bağımlılığın somut örneği ile enjekte edilmesi gerektiğini önermektedir.
Daha pratik bir örnekle anlayalım. Kendi TextEditor'unuzu yazdığınızı düşünün. Diğer şeylerin yanı sıra, kullanıcıya metnindeki yazım hatalarını kontrol etme olanağı sağlayan bir yazım denetleyicisine sahip olabilirsiniz. Böyle bir kodun basit bir uygulaması şunlar olabilir:
Class TextEditor
{
//Lot of rocket science to create the Editor goes here
EnglishSpellChecker objSpellCheck;
String text;
public void TextEditor()
{
objSpellCheck = new EnglishSpellChecker();
}
public ArrayList <typos> CheckSpellings()
{
//return Typos;
}
}
İlk bakışta, hepsi pembe görünüyor. Kullanıcı bir metin yazacaktır. Geliştirici metni yakalar ve CheckSpellings işlevini çağırır ve Kullanıcıya göstereceği Yazım hatalarının bir listesini bulur.
Bir kullanıcının Editör'de Fransızca yazmaya başladığı güzel bir güne kadar her şey harika çalışıyor gibi görünüyor.
Daha fazla dil için destek sağlamak için daha fazla Yazım Denetleyici'ye ihtiyacımız var. Muhtemelen Fransız, Alman, İspanyol vb.
Burada, "English" SpellChecker ile TextEditor sınıfımıza sıkı sıkıya bağlı bir kod oluşturduk; bu da TextEditor sınıfımızın EnglishSpellChecker'a veya başka bir deyişle EnglishSpellCheker'ın TextEditor'a bağımlı olduğu anlamına gelir. Bu bağımlılığı ortadan kaldırmalıyız. Ayrıca, Metin Düzenleyicimiz, geliştiricinin çalışma zamanında takdirine bağlı olarak herhangi bir Yazım Denetleyicisinin somut referansını tutmanın bir yoluna ihtiyaç duyar.
Bu nedenle, DI'nin girişinde gördüğümüz gibi, sınıfın bağımlılıklarına enjekte edilmesi gerektiğini düşündürmektedir. Bu nedenle, çağrılan sınıfa / koda bağımlılıkları enjekte etmek çağrı kodunun sorumluluğunda olmalıdır. Böylece kodumuzu
interface ISpellChecker
{
Arraylist<typos> CheckSpelling(string Text);
}
Class EnglishSpellChecker : ISpellChecker
{
public override Arraylist<typos> CheckSpelling(string Text)
{
//All Magic goes here.
}
}
Class FrenchSpellChecker : ISpellChecker
{
public override Arraylist<typos> CheckSpelling(string Text)
{
//All Magic goes here.
}
}
Örneğimizde, TextEditor sınıfı ISpellChecker türünün somut örneğini almalıdır.
Şimdi, bağımlılık Yapıcı, Kamusal Mülk veya yöntemle enjekte edilebilir.
Yapıcı DI kullanarak sınıfımızı değiştirmeye çalışalım. Değiştirilen TextEditor sınıfı şuna benzer:
Class TextEditor
{
ISpellChecker objSpellChecker;
string Text;
public void TextEditor(ISpellChecker objSC)
{
objSpellChecker = objSC;
}
public ArrayList <typos> CheckSpellings()
{
return objSpellChecker.CheckSpelling();
}
}
Böylece arama kodu, metin düzenleyiciyi oluştururken TextEditor örneğine uygun SpellChecker Türünü enjekte edebilir.
Sen tam makalemizi okuyabilirsiniz burada
