Inversion of Control (IoC) bisa sangat membingungkan ketika pertama kali ditemukan.
- Apa itu?
- Masalah apa yang dipecahkan?
- Kapan pantas digunakan dan kapan tidak?
Inversion of Control (IoC) bisa sangat membingungkan ketika pertama kali ditemukan.
Jawaban:
Pola Inversion of Control (IoC) dan Dependency Injection (DI) adalah tentang menghapus dependensi dari kode Anda.
Misalnya, aplikasi Anda memiliki komponen editor teks dan Anda ingin memberikan pemeriksaan ejaan. Kode standar Anda akan terlihat seperti ini:
public class TextEditor {
private SpellChecker checker;
public TextEditor() {
this.checker = new SpellChecker();
}
}
Apa yang kami lakukan di sini menciptakan ketergantungan antara TextEditor
dan SpellChecker
. Dalam skenario IoC, kami akan melakukan sesuatu seperti ini:
public class TextEditor {
private IocSpellChecker checker;
public TextEditor(IocSpellChecker checker) {
this.checker = checker;
}
}
Pada contoh kode pertama kita instantiating SpellChecker
( this.checker = new SpellChecker();
), yang berarti TextEditor
kelas secara langsung tergantung pada SpellChecker
kelas.
Dalam contoh kode kedua kami membuat abstraksi dengan memiliki SpellChecker
kelas dependensi dalam TextEditor
tanda tangan konstruktor (tidak menginisialisasi dependensi di kelas). Ini memungkinkan kita untuk memanggil dependensi lalu meneruskannya ke kelas TextEditor seperti:
SpellChecker sc = new SpellChecker; // dependency
TextEditor textEditor = new TextEditor(sc);
Sekarang klien yang membuat TextEditor
kelas memiliki kontrol atas SpellChecker
implementasi yang akan digunakan karena kami menyuntikkan ketergantungan ke TextEditor
tanda tangan.
Inversi Kontrol adalah apa yang Anda dapatkan ketika panggilan balik program Anda, misalnya seperti program gui.
Misalnya, dalam menu sekolah lama, Anda mungkin memiliki:
print "enter your name"
read name
print "enter your address"
read address
etc...
store in database
dengan demikian mengendalikan aliran interaksi pengguna.
Dalam program GUI atau semacamnya, kita katakan:
when the user types in field a, store it in NAME
when the user types in field b, store it in ADDRESS
when the user clicks the save button, call StoreInDatabase
Jadi sekarang kontrol terbalik ... alih-alih komputer menerima input pengguna dalam urutan tetap, pengguna mengontrol urutan data dimasukkan, dan ketika data disimpan dalam database.
Pada dasarnya, apa pun dengan loop peristiwa, panggilan balik, atau eksekusi pemicu termasuk dalam kategori ini.
Apa itu Pembalikan Kontrol?
Jika Anda mengikuti dua langkah sederhana ini, Anda telah melakukan inversi kontrol:
Ada beberapa teknik yang mungkin untuk setiap langkah ini berdasarkan teknologi / bahasa yang Anda gunakan untuk implementasi Anda.
-
Bagian inversi dari Inversion of Control (IoC) adalah hal yang membingungkan; karena inversi adalah istilah relatif. Cara terbaik untuk memahami IOC adalah melupakan kata itu!
-
Contohnya
what-to-do
danwhen-to-do
Inversi Kontrol adalah tentang memisahkan masalah.
Tanpa IoC : Anda memiliki komputer laptop dan Anda secara tidak sengaja merusak layar. Dan sial, Anda menemukan layar laptop model yang sama tidak ada di pasar. Jadi kamu terjebak.
Dengan IoC : Anda memiliki komputer desktop dan Anda secara tidak sengaja merusak layar. Anda dapat mengambil hampir semua monitor desktop dari pasar, dan ini berfungsi baik dengan desktop Anda.
Desktop Anda berhasil mengimplementasikan IoC dalam kasus ini. Ini menerima berbagai jenis monitor, sementara laptop tidak, perlu layar khusus untuk diperbaiki.
Inversion of Control, (atau IoC), adalah tentang mendapatkan kebebasan (Anda menikah, Anda kehilangan kebebasan dan Anda sedang dikendalikan. Anda bercerai, Anda baru saja mengimplementasikan Inversion of Control. Itulah yang kami sebut, "decoupled". Sistem komputer yang baik mencegah beberapa hubungan yang sangat dekat.) lebih banyak fleksibilitas (Dapur di kantor Anda hanya menyajikan air keran yang bersih, itu adalah satu-satunya pilihan Anda ketika Anda ingin minum. Bos Anda menerapkan Inversion of Control dengan mendirikan mesin kopi baru. Sekarang Anda mendapatkan fleksibilitas memilih air ledeng atau kopi.) dan lebih sedikit ketergantungan (Pasangan Anda memiliki pekerjaan, Anda tidak memiliki pekerjaan, Anda secara finansial bergantung pada pasangan Anda, sehingga Anda dikendalikan. Anda menemukan pekerjaan, Anda telah mengimplementasikan Inversion of Control. Sistem komputer yang baik mendorong ketergantungan.)
Ketika Anda menggunakan komputer desktop, Anda telah bekerja keras (atau mengatakan, dikendalikan). Anda harus duduk di depan layar dan melihatnya. Menggunakan keyboard untuk mengetik dan menggunakan mouse untuk bernavigasi. Dan perangkat lunak yang ditulis dengan buruk bahkan dapat membuat Anda menjadi budak. Jika Anda mengganti desktop Anda dengan laptop, maka Anda memiliki kontrol yang agak terbalik. Anda dapat dengan mudah mengambilnya dan bergerak. Jadi sekarang Anda dapat mengontrol di mana Anda berada dengan komputer Anda, bukan komputer Anda yang mengendalikannya.
Dengan menerapkan Inversion of Control, konsumen perangkat lunak / objek mendapatkan lebih banyak kontrol / opsi daripada perangkat lunak / objek, alih-alih dikendalikan atau memiliki lebih sedikit opsi.
Dengan pemikiran di atas. Kami masih kehilangan bagian penting dari IoC. Dalam skenario IoC, konsumen perangkat lunak / objek adalah kerangka kerja yang canggih. Itu berarti kode yang Anda buat tidak dipanggil sendiri. Sekarang mari kita jelaskan mengapa cara ini bekerja lebih baik untuk aplikasi web.
Misalkan kode Anda adalah sekelompok pekerja. Mereka perlu membuat mobil. Para pekerja ini membutuhkan tempat dan alat (kerangka kerja perangkat lunak) untuk membangun mobil. Sebuah tradisional kerangka kerja perangkat lunak akan menjadi seperti sebuah garasi dengan banyak alat. Jadi para pekerja perlu membuat rencana sendiri dan menggunakan alat untuk membangun mobil. Membangun mobil bukanlah bisnis yang mudah, akan sangat sulit bagi pekerja untuk merencanakan dan bekerja sama dengan baik. Seorang yang modernkerangka kerja perangkat lunak akan seperti pabrik mobil modern dengan semua fasilitas dan manajer di tempat. Para pekerja tidak harus membuat rencana apa pun, para manajer (bagian dari kerangka kerja, mereka adalah orang-orang paling cerdas dan membuat rencana paling canggih) akan membantu mengoordinasikan sehingga para pekerja tahu kapan harus melakukan pekerjaan mereka (kerangka kerja menyebut kode Anda). Pekerja hanya perlu cukup fleksibel untuk menggunakan alat apa pun yang diberikan manajer kepada mereka (dengan menggunakan Injeksi Ketergantungan).
Meskipun para pekerja memberikan kontrol mengelola proyek di tingkat atas kepada para manajer (kerangka kerja). Tetapi ada baiknya untuk membantu beberapa profesional. Ini adalah konsep IoC yang benar-benar berasal.
Aplikasi Web modern dengan arsitektur MVC tergantung pada kerangka kerja untuk melakukan Routing URL dan menempatkan Pengontrol di tempat untuk kerangka kerja untuk memanggil.
Ketergantungan Injeksi dan Pembalikan Kontrol terkait. Ketergantungan Injeksi berada di tingkat mikro dan Inversi Kontrol berada di tingkat makro . Anda harus makan setiap gigitan (menerapkan DI) untuk menyelesaikan makan (menerapkan IoC).
Sebelum menggunakan Inversion of Control Anda harus menyadari fakta bahwa ia memiliki pro dan kontra dan Anda harus tahu mengapa Anda menggunakannya jika Anda melakukannya.
Pro:
Cons:
Secara pribadi saya melihat poin kuat dari IoC dan saya sangat menyukainya, tetapi saya cenderung menghindari IoC jika memungkinkan karena mengubah perangkat lunak Anda menjadi kumpulan kelas yang tidak lagi merupakan program "nyata" tetapi hanya sesuatu yang perlu disatukan oleh Konfigurasi XML atau metadata anotasi dan akan jatuh (dan jatuh) tanpa itu.
Artikel Wikipedia . Bagi saya, inversi kontrol mengubah kode tertulis berurutan Anda dan mengubahnya menjadi struktur delegasi. Alih-alih program Anda secara eksplisit mengendalikan semuanya, program Anda membuat kelas atau pustaka dengan fungsi tertentu untuk dipanggil ketika hal-hal tertentu terjadi.
Ini memecahkan duplikasi kode. Sebagai contoh, di masa lalu Anda akan secara manual menulis loop acara Anda sendiri, polling perpustakaan sistem untuk acara baru. Saat ini, sebagian besar API modern Anda hanya memberi tahu sistem perpustakaan acara apa yang Anda minati, dan itu akan memberi tahu Anda ketika itu terjadi.
Pembalikan kontrol adalah cara praktis untuk mengurangi duplikasi kode, dan jika Anda menemukan diri Anda menyalin seluruh metode dan hanya mengubah sepotong kecil kode, Anda dapat mempertimbangkan untuk menanganinya dengan inversi kontrol. Inversi kontrol dibuat mudah dalam banyak bahasa melalui konsep delegasi, antarmuka, atau bahkan pointer fungsi mentah.
Ini tidak tepat untuk digunakan dalam semua kasus, karena aliran program bisa lebih sulit untuk diikuti ketika ditulis dengan cara ini. Ini adalah cara yang berguna untuk merancang metode saat menulis perpustakaan yang akan digunakan kembali, tetapi harus digunakan dengan hemat dalam inti program Anda sendiri kecuali jika itu benar-benar memecahkan masalah duplikasi kode.
Tapi saya pikir Anda harus sangat berhati-hati dengan itu. Jika Anda terlalu sering menggunakan pola ini, Anda akan membuat desain yang sangat rumit dan bahkan kode yang lebih rumit.
Seperti dalam contoh ini dengan TextEditor: jika Anda hanya memiliki satu SpellChecker, mungkin tidak perlu menggunakan IoC? Kecuali jika Anda perlu menulis unit test atau sesuatu ...
Pokoknya: masuk akal. Pola desain adalah praktik yang baik tetapi bukan Alkitab untuk diberitakan. Jangan menempel di mana-mana.
IoC / DI bagi saya mendorong dependensi ke objek panggilan. Sangat sederhana.
Jawaban non-techy adalah mampu menukar mesin di mobil tepat sebelum Anda menyalakannya. Jika semuanya terhubung dengan benar (antarmuka), Anda baik.
Misalkan Anda adalah objek. Dan Anda pergi ke restoran:
Tanpa IOC : Anda meminta "apel", dan Anda selalu disajikan apel saat Anda bertanya lebih banyak.
Dengan IoC : Anda dapat meminta "buah". Anda bisa mendapatkan buah yang berbeda setiap kali dilayani. misalnya, apel, jeruk, atau melon air.
Jadi, jelas, IOC lebih disukai bila Anda suka varietas.
Inversion of control adalah pola yang digunakan untuk memisahkan komponen dan lapisan dalam sistem. Pola diimplementasikan melalui menyuntikkan dependensi ke dalam komponen ketika itu dibangun. Ketergantungan ini biasanya disediakan sebagai antarmuka untuk decoupling lebih lanjut dan untuk mendukung testability. Kontainer IoC / DI seperti Castle Windsor, Unity adalah alat (perpustakaan) yang dapat digunakan untuk menyediakan IoC. Alat-alat ini menyediakan fitur-fitur tambahan di atas dan di luar manajemen ketergantungan yang sederhana, termasuk masa pakai, AOP / Interception, kebijakan, dll
Sebuah. Mengurangi komponen agar tidak bertanggung jawab untuk mengelola dependensinya.
b. Memberikan kemampuan untuk menukar implementasi ketergantungan di lingkungan yang berbeda.
c. Mengizinkan komponen diuji melalui mengejek dependensi.
d. Menyediakan mekanisme untuk berbagi sumber daya di seluruh aplikasi.
Sebuah. Sangat penting saat melakukan pengembangan yang digerakkan oleh tes. Tanpa IoC bisa jadi sulit untuk diuji, karena komponen yang diuji sangat berpasangan dengan sistem lainnya.
b. Sangat penting ketika mengembangkan sistem modular. Sistem modular adalah sistem yang komponennya dapat diganti tanpa memerlukan kompilasi ulang.
c. Sangat penting jika ada banyak masalah lintas sektoral yang perlu ditangani, sebagian dalam aplikasi perusahaan.
Menjawab hanya bagian pertama. Apa itu?
Inversion of Control (IoC) berarti membuat instance dependensi pertama dan instance terakhir dari kelas (secara opsional menginjeksi mereka melalui konstruktor), alih-alih membuat instance kelas terlebih dahulu dan kemudian instance kelas membuat instance dependensi. Dengan demikian, inversi kontrol membalikkan yang aliran kontrol program. Alih-alih yang callee mengendalikan para aliran kontrol (sekaligus menciptakan dependensi), yang pemanggil mengontrol aliran kontrol program .
Saya akan menuliskan pemahaman sederhana saya tentang dua istilah ini:
For quick understanding just read examples*
Dependency Injection (DI):
Injeksi dependensi umumnya berarti melewatkan objek yang bergantung pada metode, sebagai parameter metode, daripada meminta metode membuat objek dependen .
Apa yang dimaksud dalam praktiknya adalah bahwa metode ini tidak tergantung langsung pada implementasi tertentu; implementasi apa pun yang memenuhi persyaratan dapat diteruskan sebagai parameter.
Dengan ini objek memberitahu dependensi mereka. Dan musim semi membuatnya tersedia.
Ini mengarah pada pengembangan aplikasi yang digabungkan secara longgar.
Quick Example:EMPLOYEE OBJECT WHEN CREATED,
IT WILL AUTOMATICALLY CREATE ADDRESS OBJECT
(if address is defines as dependency by Employee object)
Inversion of Control (IoC) Container:
Ini adalah karakteristik umum dari frameworks, IOC mengelola objek java
- dari instantiation hingga penghancuran melalui BeanFactory-nya.
-Java komponen yang dipakai oleh wadah IoC disebut kacang, dan wadah IoC mengelola lingkup kacang, peristiwa siklus hidup, dan setiap fitur AOP yang telah dikonfigurasi dan dikodekan.
QUICK EXAMPLE:Inversion of Control is about getting freedom, more flexibility, and less dependency. When you are using a desktop computer, you are slaved (or say, controlled). You have to sit before a screen and look at it. Using keyboard to type and using mouse to navigate. And a bad written software can slave you even more. If you replaced your desktop with a laptop, then you somewhat inverted control. You can easily take it and move around. So now you can control where you are with your computer, instead of computer controlling it
.
Dengan menerapkan Inversion of Control, konsumen perangkat lunak / objek mendapatkan lebih banyak kontrol / opsi daripada perangkat lunak / objek, alih-alih dikendalikan atau memiliki lebih sedikit opsi.
Inversi kontrol sebagai pedoman desain melayani tujuan berikut:
Ada decoupling dari pelaksanaan tugas tertentu dari implementasi.
Setiap modul dapat fokus pada apa yang dirancang untuk itu.
Modul tidak membuat asumsi tentang apa yang dilakukan sistem lain kecuali mengandalkan kontraknya.
Mengganti modul tidak memiliki efek samping pada modul lain.
Saya akan menjaga hal-hal abstrak di sini, Anda dapat mengunjungi tautan berikut untuk memahami topik secara terperinci.
Bacaan yang bagus dengan contoh
Saya setuju dengan NilObject , tetapi saya ingin menambahkan ini:
jika Anda menemukan diri Anda menyalin seluruh metode dan hanya mengubah sepotong kecil kode, Anda dapat mempertimbangkan untuk menanganinya dengan inversi kontrol
Jika Anda menemukan diri Anda menyalin dan menyisipkan kode di sekitar, Anda hampir selalu melakukan sesuatu yang salah. Diketahui sebagai prinsip desain Once and Only Once .
Misalnya, tugas # 1 adalah membuat objek. Tanpa konsep IOC, tugas # 1 seharusnya dilakukan oleh Programmer. Tetapi dengan konsep IOC, tugas # 1 akan dilakukan dengan wadah.
Singkatnya Kontrol akan terbalik dari Programmer ke wadah. Jadi, ini disebut sebagai inversi kontrol.
Saya menemukan satu contoh bagus di sini .
Katakanlah bahwa kami mengadakan pertemuan di beberapa hotel.
Banyak orang, banyak botol air, banyak gelas plastik.
Ketika seseorang ingin minum, dia mengisi cangkir, minum dan melempar cangkir ke lantai.
Setelah satu jam atau sesuatu, kami memiliki lantai tertutup gelas plastik dan air.
Biarkan kontrol terbalik.
Pertemuan yang sama di tempat yang sama, tetapi bukannya gelas plastik kami memiliki pelayan dengan satu gelas gelas (Singleton)
dan dia sepanjang waktu menawarkan kepada tamu minum.
Ketika seseorang ingin minum, dia mendapatkan dari gelas pelayan, minum dan mengembalikannya ke pelayan.
Mengesampingkan masalah kebersihan, bentuk terakhir dari kontrol proses minum jauh lebih efektif dan ekonomis.
Dan inilah yang dilakukan oleh Spring (wadah IoC lainnya, misalnya: Guice). Alih-alih membiarkan aplikasi membuat apa yang dibutuhkan menggunakan kata kunci baru (mengambil gelas plastik), wadah Spring IoC selalu menawarkan aplikasi contoh yang sama (tunggal) dari objek yang dibutuhkan (segelas air).
Pikirkan diri Anda sebagai penyelenggara pertemuan tersebut. Anda perlu cara untuk mengirim pesan ke administrasi hotel itu
anggota rapat akan membutuhkan segelas air tetapi bukan sepotong kue.
Contoh:-
public class MeetingMember {
private GlassOfWater glassOfWater;
...
public void setGlassOfWater(GlassOfWater glassOfWater){
this.glassOfWater = glassOfWater;
}
//your glassOfWater object initialized and ready to use...
//spring IoC called setGlassOfWater method itself in order to
//offer to meetingMember glassOfWater instance
}
Tautan yang bermanfaat: -
Tampaknya hal yang paling membingungkan tentang "IoC" akronim dan nama yang berdiri adalah bahwa itu terlalu glamor dari sebuah nama - hampir merupakan nama berisik.
Apakah kita benar-benar membutuhkan nama untuk menggambarkan perbedaan antara pemrograman prosedural dan pemrograman berbasis acara? OK, jika kita perlu, tetapi apakah kita harus memilih nama baru "lebih besar dari kehidupan" yang membingungkan lebih dari itu memecahkan?
Pembalikan kontrol adalah ketika Anda pergi ke toko kelontong dan istri Anda memberi Anda daftar produk untuk dibeli.
Dalam istilah pemrograman, dia meneruskan fungsi panggilan balik getProductList()
ke fungsi yang Anda jalankan - doShopping()
.
Ini memungkinkan pengguna fungsi untuk mendefinisikan beberapa bagiannya, membuatnya lebih fleksibel.
getProductList()
Anda memanggil Anda harus menemukan sumber uang, berarti kontrol ada di pihak Anda. Dalam kasus inversi, dia akan mengendalikan, berarti uang juga akan dia sediakan untuk dibeli.
Saya menemukan contoh yang sangat jelas di sini yang menjelaskan bagaimana 'kontrol dibalik'.
Kode klasik (tanpa injeksi Ketergantungan)
Berikut ini cara kerja kode yang tidak menggunakan DI:
Menggunakan injeksi ketergantungan
Berikut ini cara kerja kode menggunakan DI:
Kontrol dependensi dibalik dari yang dipanggil ke yang terpanggil.
Masalah apa yang dipecahkan?
Ketergantungan injeksi membuatnya mudah untuk bertukar dengan implementasi yang berbeda dari kelas yang disuntikkan. Sementara pengujian unit Anda dapat menyuntikkan implementasi dummy, yang membuat pengujian jauh lebih mudah.
Mis: Misalkan aplikasi Anda menyimpan file yang diunggah pengguna di Google Drive, dengan DI, kode pengontrol Anda mungkin terlihat seperti ini:
class SomeController
{
private $storage;
function __construct(StorageServiceInterface $storage)
{
$this->storage = $storage;
}
public function myFunction ()
{
return $this->storage->getFile($fileName);
}
}
class GoogleDriveService implements StorageServiceInterface
{
public function authenticate($user) {}
public function putFile($file) {}
public function getFile($file) {}
}
Ketika persyaratan Anda berubah katakan, alih-alih GoogleDrive Anda diminta untuk menggunakan Dropbox. Anda hanya perlu menulis implementasi dropbox untuk StorageServiceInterface. Anda tidak harus membuat perubahan apa pun di controller selama implementasi Dropbox mematuhi StorageServiceInterface.
Saat menguji Anda dapat membuat tiruan untuk StorageServiceInterface dengan implementasi dummy di mana semua metode mengembalikan nol (atau nilai yang telah ditentukan sebelumnya sesuai kebutuhan pengujian Anda).
Alih-alih jika Anda memiliki kelas controller untuk membangun objek penyimpanan dengan new
kata kunci seperti ini:
class SomeController
{
private $storage;
function __construct()
{
$this->storage = new GoogleDriveService();
}
public function myFunction ()
{
return $this->storage->getFile($fileName);
}
}
Saat Anda ingin mengubah dengan implementasi Dropbox Anda harus mengganti semua baris tempat new
objek GoogleDriveService dibangun dan menggunakan DropboxService. Selain itu ketika menguji kelas SomeController, konstruktor selalu mengharapkan kelas GoogleDriveService dan metode aktual kelas ini dipicu.
Kapan itu tepat dan kapan tidak? Menurut pendapat saya, Anda menggunakan DI ketika Anda berpikir ada (atau mungkin ada) implementasi alternatif kelas.
Penjelasan tertulis yang sangat sederhana dapat ditemukan di sini
http://binstock.blogspot.in/2008/01/excellent-explanation-of-dependency.html
Ia mengatakan -
"Setiap aplikasi nontrivial terdiri dari dua kelas atau lebih yang berkolaborasi satu sama lain untuk melakukan beberapa logika bisnis. Secara tradisional, setiap objek bertanggung jawab untuk mendapatkan referensi sendiri ke objek yang dikolaborasikan dengan (dependensinya). Ketika menerapkan DI, objek diberi dependensinya pada waktu pembuatan oleh beberapa entitas eksternal yang mengoordinasikan setiap objek dalam sistem. Dengan kata lain, dependensi disuntikkan ke dalam objek. "
Inversion of Control adalah prinsip umum, sedangkan Injeksi Ketergantungan menyadari prinsip ini sebagai pola desain untuk konstruksi grafik objek (mis. Konfigurasi mengontrol bagaimana objek saling merujuk satu sama lain, daripada objek itu sendiri yang mengontrol cara mendapatkan referensi ke objek lain).
Melihat Inversion of Control sebagai pola desain, kita perlu melihat apa yang kita membalikkan. Ketergantungan Injeksi membalikkan kontrol membangun grafik objek. Jika diceritakan dalam istilah awam, inversi kontrol menyiratkan perubahan aliran kontrol dalam program. Misalnya. Dalam aplikasi mandiri tradisional, kami memiliki metode utama, dari mana kontrol dilewatkan ke perpustakaan pihak ketiga lainnya (dalam kasus, kami telah menggunakan fungsi perpustakaan pihak ketiga), tetapi melalui inversi kontrol kontrol ditransfer dari kode perpustakaan pihak ketiga ke kode kami , saat kami menggunakan layanan perpustakaan pihak ketiga. Tetapi ada aspek lain yang perlu dibalik dalam suatu program - mis. Doa metode dan utas untuk mengeksekusi kode.
Bagi mereka yang tertarik secara lebih mendalam tentang Inversion of Control, sebuah makalah telah diterbitkan menguraikan gambaran yang lebih lengkap dari Inversion of Control sebagai pola desain (OfficeFloor: menggunakan pola kantor untuk meningkatkan desain perangkat lunak http://doi.acm.org/10.1145/ 2739011.2739013 dengan salinan gratis tersedia untuk diunduh dari http://www.officefloor.net/about.html ).
Apa yang diidentifikasi adalah hubungan berikut:
Inversi Kontrol (untuk metode) = Ketergantungan (status) Injeksi + Injeksi Lanjutan + Injeksi Thread
Ringkasan hubungan di atas untuk Inversion of Control tersedia - http://dzone.com/articles/inversion-of-coupling-control
IoC adalah tentang membalikkan hubungan antara kode Anda dan kode pihak ketiga (perpustakaan / kerangka kerja):
DI (Dependency Injection) adalah tentang bagaimana kontrol mengalir dalam aplikasi. Aplikasi desktop tradisional memiliki aliran kontrol dari aplikasi Anda (metode utama ()) ke panggilan metode pustaka lainnya, tetapi dengan aliran kontrol DI terbalik, kerangka kerja itu mengatur memulai aplikasi Anda, menginisialisasi dan menggunakan metode Anda kapan pun diperlukan.
Pada akhirnya Anda selalu menang :)
Saya suka penjelasan ini: http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/
Itu mulai sederhana dan menunjukkan contoh kode juga.
Konsumen, X, membutuhkan kelas yang dikonsumsi, Y, untuk mencapai sesuatu. Itu semua baik dan alami, tetapi apakah X benar-benar perlu tahu bahwa ia menggunakan Y?
Bukankah sudah cukup bahwa X tahu bahwa ia menggunakan sesuatu yang memiliki perilaku, metode, properti, dll, dari Y tanpa mengetahui siapa yang sebenarnya mengimplementasikan perilaku itu?
Dengan mengekstraksi definisi abstrak dari perilaku yang digunakan oleh X dalam Y, diilustrasikan seperti saya di bawah ini, dan membiarkan konsumen X menggunakan contoh yang alih-alih Y, ia dapat terus melakukan apa yang dilakukannya tanpa harus mengetahui secara spesifik tentang Y.
Dalam ilustrasi di atas Y mengimplementasikan I dan X menggunakan instance I. Sementara itu sangat mungkin bahwa X masih menggunakan Y yang menarik adalah bahwa X tidak tahu itu. Ia hanya tahu bahwa ia menggunakan sesuatu yang mengimplementasikan saya.
Baca artikel untuk info lebih lanjut dan deskripsi manfaat seperti:
...
Saya mengerti bahwa jawabannya sudah diberikan di sini. Tapi saya masih berpikir, beberapa dasar tentang inversi kontrol harus dibahas panjang lebar di sini untuk pembaca masa depan.
Inversion of Control (IoC) telah dibangun di atas prinsip yang sangat sederhana yang disebut Prinsip Hollywood . Dan dikatakan bahwa,
Jangan hubungi kami, kami akan menghubungi Anda
Artinya adalah bahwa jangan pergi ke Hollywood untuk memenuhi impian Anda melainkan jika Anda layak maka Hollywood akan menemukan Anda dan mewujudkan impian Anda. Cukup banyak terbalik, ya?
Sekarang ketika kita membahas tentang prinsip IoC, kita gunakan untuk melupakan Hollywood. Untuk IoC, harus ada tiga elemen, Hollywood, Anda dan tugas ingin memenuhi impian Anda.
Di dunia pemrograman kami, Hollywood mewakili kerangka kerja umum (dapat ditulis oleh Anda atau orang lain), Anda mewakili kode pengguna yang Anda tulis dan tugas tersebut mewakili hal yang ingin Anda capai dengan kode Anda. Sekarang Anda tidak pernah pergi untuk memicu tugas Anda sendiri, bukan di IoC! Sebaliknya Anda telah merancang segala sesuatu sedemikian rupa sehingga kerangka kerja Anda akan memicu tugas Anda untuk Anda. Dengan demikian Anda telah membangun kerangka kerja yang dapat digunakan kembali yang dapat membuat seseorang menjadi pahlawan atau penjahat lainnya. Tetapi kerangka kerja itu selalu bertanggung jawab, ia tahu kapan harus memilih seseorang dan bahwa seseorang hanya tahu apa yang diinginkannya.
Contoh nyata akan diberikan di sini. Misalkan, Anda ingin mengembangkan aplikasi web. Jadi, Anda membuat kerangka kerja yang akan menangani semua hal umum yang harus ditangani oleh aplikasi web seperti menangani permintaan http, membuat menu aplikasi, melayani halaman, mengelola cookie, memicu acara, dll.
Dan kemudian Anda meninggalkan beberapa kait di kerangka kerja Anda di mana Anda dapat menempatkan kode lebih lanjut untuk menghasilkan menu kustom, halaman, cookie atau mencatat beberapa peristiwa pengguna dll. Pada setiap permintaan browser, kerangka kerja Anda akan berjalan dan mengeksekusi kode kustom Anda jika terhubung kemudian melayani kembali ke browser.
Jadi, idenya cukup sederhana. Daripada membuat aplikasi pengguna yang akan mengendalikan semuanya, pertama Anda membuat kerangka kerja yang dapat digunakan kembali yang akan mengendalikan semuanya kemudian menulis kode khusus Anda dan menghubungkannya ke kerangka kerja untuk mengeksekusi mereka pada waktunya.
Laravel dan EJB adalah contoh kerangka kerja seperti itu.
Referensi:
Pemrograman berbicara
IoC dalam istilah yang mudah: Ini penggunaan Interface sebagai cara sesuatu yang spesifik (seperti bidang atau parameter) sebagai wildcard yang dapat digunakan oleh beberapa kelas. Ini memungkinkan penggunaan ulang kode.
Sebagai contoh, katakanlah kita memiliki dua kelas: Anjing dan Kucing . Keduanya memiliki kualitas / status yang sama: usia, ukuran, berat. Jadi alih-alih membuat kelas layanan yang disebut DogService dan CatService , saya bisa membuat satu yang disebut AnimalService yang memungkinkan untuk menggunakan Dog dan Cat hanya jika mereka menggunakan antarmuka IAnimal .
Namun, secara pragmatis, ada beberapa yang mundur.
a) Sebagian besar pengembang tidak tahu cara menggunakannya . Sebagai contoh, saya dapat membuat kelas yang disebut Pelanggan dan saya dapat membuat secara otomatis (menggunakan alat IDE) sebuah antarmuka yang disebut ICustomer . Jadi, tidak jarang menemukan folder yang penuh dengan kelas dan antarmuka, tidak peduli apakah antarmuka akan digunakan kembali atau tidak. Itu disebut BLOATED. Beberapa orang bisa berpendapat bahwa "mungkin di masa depan kita bisa menggunakannya". : - |
b) Ada beberapa batasan. Sebagai contoh, mari kita bicara tentang kasus Dog and Cat dan saya ingin menambahkan layanan baru (fungsionalitas) hanya untuk anjing. Katakanlah saya ingin menghitung jumlah hari yang saya perlukan untuk melatih seekor anjing ( trainDays()
), karena kucing itu tidak berguna, kucing tidak bisa dilatih (saya bercanda).
b.1) Jika saya menambahkan trainDays()
ke AnimalService Layanan maka ia juga berfungsi dengan kucing dan itu tidak berlaku sama sekali.
b.2) Saya dapat menambahkan kondisi di trainDays()
mana ia mengevaluasi kelas mana yang digunakan. Tapi itu akan menghancurkan IOC sepenuhnya.
b.3) Saya dapat membuat kelas layanan baru bernama DogService hanya untuk fungsionalitas baru. Tapi, itu akan meningkatkan rawatan kode karena kami akan memiliki dua kelas layanan (dengan fungsi serupa) untuk Dog dan itu buruk.
Saya sudah membaca banyak jawaban untuk ini, tetapi jika seseorang masih bingung dan perlu ditambah "istilah awam" untuk menjelaskan IoC, inilah yang saya ambil:
Bayangkan orangtua dan anak saling berbicara.
Tanpa IOC:
* Induk : Anda hanya dapat berbicara ketika saya mengajukan pertanyaan dan Anda hanya dapat bertindak ketika saya memberi Anda izin.
Induk : Ini artinya, Anda tidak bisa bertanya kepada saya apakah Anda bisa makan, bermain, pergi ke kamar mandi atau bahkan tidur jika saya tidak bertanya kepada Anda.
Induk : Apakah kamu mau makan?
Anak : Tidak.
Parent : Oke, aku akan kembali. Tunggu aku
Anak : (Ingin bermain tetapi karena tidak ada pertanyaan dari orang tua, anak tidak dapat melakukan apa-apa).
Setelah 1 jam...
Induk : Saya kembali. Apakah kamu ingin bermain?
Anak : Ya.
Induk : Izin diberikan.
Anak : (akhirnya bisa bermain).
Skenario sederhana ini menjelaskan kontrol dipusatkan ke induk. Kebebasan anak dibatasi dan sangat tergantung pada pertanyaan orang tua. Anak HANYA dapat berbicara ketika diminta untuk berbicara, dan HANYA dapat bertindak ketika diberi izin.
Dengan IoC:
Anak sekarang memiliki kemampuan untuk mengajukan pertanyaan dan orang tua dapat merespons dengan jawaban dan izin. Berarti kontrolnya terbalik! Anak itu sekarang bebas untuk mengajukan pertanyaan kapan saja dan meskipun masih ada ketergantungan dengan orang tua mengenai izin, ia tidak bergantung pada cara berbicara / mengajukan pertanyaan.
Dalam cara teknologi menjelaskan, ini sangat mirip dengan interaksi konsol / shell / cmd vs GUI. (Yang merupakan jawaban dari Mark Harrison di atas no.2 jawaban teratas). Di konsol, Anda bergantung pada apa yang diminta / ditampilkan kepada Anda dan Anda tidak dapat melompat ke menu dan fitur lain tanpa menjawab pertanyaannya terlebih dahulu; mengikuti aliran berurutan yang ketat. (secara terprogram ini seperti metode / fungsi loop). Namun dengan GUI, menu dan fitur diletakkan dan pengguna dapat memilih apa pun yang dibutuhkan sehingga memiliki kontrol lebih besar dan lebih sedikit dibatasi. (secara terprogram, menu memiliki panggilan balik ketika dipilih dan suatu tindakan terjadi).
Inversi kontrol adalah tentang mentransfer kontrol dari perpustakaan ke klien. Lebih masuk akal ketika kita berbicara tentang klien yang menyuntikkan (melewati) nilai fungsi (ekspresi lambda) ke fungsi urutan yang lebih tinggi (fungsi perpustakaan) yang mengontrol (mengubah) perilaku fungsi perpustakaan. Klien atau kerangka kerja yang menyuntikkan dependensi perpustakaan (yang membawa perilaku) ke perpustakaan juga dapat dianggap sebagai IoC
Karena sudah ada banyak jawaban untuk pertanyaan tetapi tidak satupun dari mereka yang menunjukkan rincian istilah Kontrol Pembalikan, saya melihat peluang untuk memberikan jawaban yang lebih ringkas dan bermanfaat.
Inversion of Control adalah pola yang mengimplementasikan Prinsip Ketergantungan Inversi (DIP). DIP menyatakan sebagai berikut: 1. Modul tingkat tinggi tidak boleh bergantung pada modul tingkat rendah. Keduanya harus bergantung pada abstraksi (misalnya antarmuka). 2. Abstraksi tidak harus tergantung pada detail. Detail (implementasi konkret) harus bergantung pada abstraksi.
Ada tiga jenis Pembalikan Kontrol:
Penyedia Pembalik Antarmuka tidak harus mendefinisikan antarmuka. Sebagai gantinya, konsumen harus mendefinisikan antarmuka dan penyedia harus mengimplementasikannya. Inversi Antarmuka memungkinkan menghilangkan keharusan untuk mengubah konsumen setiap kali ketika penyedia baru ditambahkan.
Inversi Aliran Mengubah kontrol aliran. Misalnya, Anda memiliki aplikasi konsol tempat Anda diminta memasukkan banyak parameter dan setelah setiap parameter yang dimasukkan, Anda terpaksa menekan Enter. Anda dapat menerapkan Flow Inversion di sini dan mengimplementasikan aplikasi desktop di mana pengguna dapat memilih urutan parameter yang dimasukkan, pengguna dapat mengedit parameter, dan pada langkah terakhir, pengguna perlu menekan Enter hanya sekali.
Pembalikan Penciptaan Hal ini dapat diimplementasikan dengan pola-pola berikut: Pola Pabrik, Pencari Lokasi Layanan, dan Injeksi Ketergantungan. Pembalikan Penciptaan membantu untuk menghilangkan dependensi antara tipe yang menggerakkan proses pembuatan objek dependensi di luar tipe yang menggunakan objek dependensi ini. Mengapa ketergantungan itu buruk? Berikut adalah beberapa contoh: pembuatan objek baru langsung dalam kode Anda membuat pengujian lebih sulit; tidak mungkin untuk mengubah referensi di majelis tanpa kompilasi ulang (pelanggaran prinsip OCP); Anda tidak dapat dengan mudah mengganti desktop-UI dengan UI web.
Jadi nomor 1 di atas . Apa itu Pembalikan Kontrol?
Pemeliharaan adalah hal nomor satu yang dipecahkan untuk saya. Ini menjamin saya menggunakan antarmuka sehingga dua kelas tidak intim satu sama lain.
Dalam menggunakan wadah seperti Castle Windsor, itu memecahkan masalah pemeliharaan lebih baik. Mampu menukar komponen yang masuk ke database dengan komponen yang menggunakan kegigihan berbasis file tanpa mengubah sebaris kode pun luar biasa (perubahan konfigurasi, Anda sudah selesai).
Dan begitu Anda masuk ke obat generik, itu menjadi lebih baik. Bayangkan memiliki penerbit pesan yang menerima catatan dan menerbitkan pesan. Tidak peduli apa yang diterbitkannya, tetapi perlu mapper untuk mengambil sesuatu dari catatan ke pesan.
public class MessagePublisher<RECORD,MESSAGE>
{
public MessagePublisher(IMapper<RECORD,MESSAGE> mapper,IRemoteEndpoint endPointToSendTo)
{
//setup
}
}
Saya menulisnya sekali, tapi sekarang saya bisa menyuntikkan banyak tipe ke set kode ini jika saya mempublikasikan berbagai jenis pesan. Saya juga dapat menulis pemetaan yang mengambil catatan dari jenis yang sama dan memetakannya ke pesan yang berbeda. Menggunakan DI dengan Generik telah memberi saya kemampuan untuk menulis kode yang sangat sedikit untuk menyelesaikan banyak tugas.
Oh ya, ada masalah testability, tetapi mereka di urutan kedua dari manfaat IoC / DI.
Saya pasti mencintai IoC / DI.
3. Menjadi lebih tepat begitu Anda memiliki proyek berukuran sedang dengan kompleksitas yang lebih banyak. Saya akan mengatakan itu menjadi tepat saat Anda mulai merasa sakit.
Membuat objek dalam kelas disebut kopling ketat, Spring menghilangkan ketergantungan ini dengan mengikuti pola desain (DI / IOC). Di mana objek kelas di lewat di konstruktor daripada menciptakan di kelas. Terlebih lagi kami memberikan variabel referensi kelas super dalam konstruktor untuk mendefinisikan struktur yang lebih umum.