Apa itu Pembalikan Kontrol?


1826

Inversion of Control (IoC) bisa sangat membingungkan ketika pertama kali ditemukan.

  1. Apa itu?
  2. Masalah apa yang dipecahkan?
  3. Kapan pantas digunakan dan kapan tidak?

292
Masalah dengan sebagian besar jawaban ini adalah terminologi yang digunakan. Apa itu wadah? Inversi? Ketergantungan? Jelaskan secara awam tanpa kata-kata besar.
kirk.burleson


8
Ini adalah Dependency Injection (DI) - lihat deskripsi
Ricardo Sanchez


Ini adalah kata sifat, bukan kata benda, itu bukan benda, itu adalah deskripsi perubahan yang dilakukan pada kode, di mana kontrol aliran ada di delegasi, bukan wadah.
Martin Spamer

Jawaban:


1523

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 TextEditordan 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 TextEditorkelas secara langsung tergantung pada SpellCheckerkelas.

Dalam contoh kode kedua kami membuat abstraksi dengan memiliki SpellCheckerkelas dependensi dalam TextEditortanda 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 TextEditorkelas memiliki kontrol atas SpellCheckerimplementasi yang akan digunakan karena kami menyuntikkan ketergantungan ke TextEditortanda tangan.


50
Contoh yang jelas dan bagus. Namun, misalkan alih-alih membutuhkan antarmuka ISpellChecker diteruskan ke konstruktor objek, kami mengeksposnya sebagai properti yang dapat diatur (atau metode SetSpellChecker). Apakah ini masih merupakan IOC?
devios1

25
chainguy1337 - ya itu akan Menggunakan setter seperti itu disebut injeksi setter sebagai lawan dari injeksi konstruktor (keduanya teknik injeksi ketergantungan). IOC adalah pola yang cukup generik, tapi injeksi ketergantungan acheives IOC
Jack Ukleja

257
Meskipun banyak suara, jawaban ini tidak benar. Silakan lihat martinfowler.com/articles/injection.html#InversionOfControl . Secara khusus, perhatikan bagian yang mengatakan "Inversion of Control adalah istilah yang terlalu umum, dan dengan demikian orang-orang merasa membingungkan. Akibatnya dengan banyak diskusi dengan berbagai pendukung IoC kami memilih nama Dependency Injection".
Rogério

45
Saya setuju dengan @Rogeria. ini tidak menjelaskan mengapa ini disebut IoC dan saya terkejut dengan jumlah suara ;-)
Aravind Yarram

31
Saya berpihak pada @Rogerio dan @Pangea. Ini mungkin contoh yang baik untuk injeksi konstruktor tetapi bukan jawaban yang baik untuk pertanyaan awal. IoC, sebagaimana didefinisikan oleh Fowler , dapat direalisasikan tanpa menggunakan injeksi apa pun, misalnya dengan menggunakan pencari lokasi layanan atau bahkan warisan sederhana.
mtsz

642

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.


161
jangan tandai orang ini. secara teknis dia benar martinfowler.com/bliki/InversionOfControl.html IoC adalah prinsip yang sangat umum. Aliran kontrol "terbalik" dengan injeksi ketergantungan karena Anda telah mendelegasikan ketergantungan secara efektif ke beberapa sistem eksternal (mis. Wadah IoC)
Jack Ukleja

38
Setuju dengan komentar Schneider. 5 downvotes? Pikiran membingungkan, karena ini adalah satu-satunya jawaban yang benar. Perhatikan pembukaan: ' like a gui program.' Injeksi ketergantungan hanya merupakan realisasi IoC yang paling umum dilihat.
Jeff Sternal

40
Memang, ini adalah salah satu dari sedikit jawaban yang benar ! Guys, IoC bukan fundamental tentang ketergantungan. Tidak semuanya.
Rogério

13
+1 - Ini adalah deskripsi yang baik (dengan contoh) dari pernyataan berikut oleh Martin Fowler - "Antarmuka pengguna awal dikendalikan oleh program aplikasi. Anda akan memiliki urutan perintah seperti" Masukkan nama "," masukkan alamat "; Anda program akan mendorong prompt dan mengambil respons untuk masing-masing. Dengan grafis (atau bahkan berbasis layar) kerangka UI akan berisi loop utama ini dan program Anda sebagai gantinya menyediakan pengendali acara untuk berbagai bidang di layar. Kontrol utama dari program itu terbalik, pindah dari Anda ke kerangka kerja. "
Ashish Gupta

14
Sekarang saya mengerti mengapa kadang-kadang disebut sebagai "Prinsip Hollywood: Jangan panggil kami, kami akan memanggil Anda"
Alexander Suraphel

419

Apa itu Pembalikan Kontrol?

Jika Anda mengikuti dua langkah sederhana ini, Anda telah melakukan inversi kontrol:

  1. Pisahkan bagian apa yang harus dilakukan dan kapan yang harus dilakukan.
  2. Pastikan bahwa ketika bagian tahu sesedikit mungkin tentang bagian apa ; dan sebaliknya.

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

  • Penanganan Acara. Penangan Kejadian (bagian yang harus dikerjakan) - Mengangkat Acara (bagian yang harus dikerjakan)
  • Antarmuka. Klien komponen (bagian saat melakukan) - Implementasi Antarmuka Komponen (bagian tugas)
  • xUnit fixture. Setup dan TearDown (bagian yang harus dikerjakan) - kerangka kerja xUnit memanggil ke Setup di awal dan TearDown di bagian akhir (bagian saat melakukan)
  • Pola desain metode template. metode templat when-to-do part - bagian subclass implementasi primitif apa yang harus dilakukan
  • Metode wadah DLL di COM. DllMain, DllCanUnload, dll (bagian yang harus dikerjakan) - COM / OS (bagian yang harus dikerjakan)

Bagaimana Anda mengatakan Antarmuka. Klien komponen (bagian saat melakukan) sebagai "kapan" tidak masuk akal ketika kita menggunakan antarmuka (Mis: Injeksi Ketergantungan), kami hanya mengabstraksi dan memberikan fleksibilitas kepada klien tentang menambahkan implementasi apa pun tetapi tidak ada "kapan" terlibat di sana. Saya setuju dengan "kapan" dalam kasus Meningkatkan Acara Penanganan Acara.
OldSchool

Dengan 'klien komponen' yang saya maksud adalah pengguna / klien antarmuka. Klien tahu 'kapan' untuk memicu bagian 'apa yang harus dilakukan' apakah niatnya adalah untuk memperluas fungsi atau tidak.
rpattabi

Lihatlah artikel indah ini oleh Martin Fowler. Dia menunjukkan bagaimana antarmuka membuat bagian mendasar dari inversi kontrol: martinfowler.com/articles/injection.html#InversionOfControl
rpattabi

dua kalimat pertama itu brilian. luar biasa !! memisahkan sempurna dengan kapan harus dilakukan dan apa yang harus dilakukan !! Saya tidak tahu mengapa jawaban lain mendapatkan banyak upvotes. mereka hanya berbicara kode tanpa pemahaman.
Amir Ziarati

2
Saya suka penjelasannya what-to-dodanwhen-to-do
KimchiMan

164

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.


1
@Luo Jiong Hui penjelasan yang bagus.
Sachin

3
Sebagian besar pola Desain, jika tidak semua, memiliki rekanannya dalam kehidupan kita sehari-hari yang kita lihat dan pahami dengan baik. Cara paling efisien untuk memahami pola desain adalah dengan mengetahui kehidupan sehari-hari. Dan saya percaya ada banyak.
Luo Jiong Hui

6
Jawaban yang salah. Anda menjelaskan injeksi ketergantungan dan bukan IOC. Lihat komentar Rogério tentang jawaban di atas
MickyD

2
Saya setuju. Ini DI, bukan IOC. Masih mendapat dukungan dari, karena itu adalah pendekatan yang sederhana, namun membantu memperluas pemahaman topik.
Mark

Ini menjelaskan injeksi ketergantungan. Bukan Ioc. Tapi penjelasannya bagus dan jelas.
Chamin Wickramarathna

120

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).


21
Saya memilih untuk membandingkan DI untuk pernikahan dan IOC untuk bercerai.
Marek Bar

"Meskipun para pekerja memberikan kontrol untuk mengelola proyek di tingkat atas kepada para manajer (kerangka kerja). Tapi itu baik jika ada beberapa profesional yang membantu. Ini adalah konsep dari IoC yang benar-benar berasal." - Pertama kontrolnya adalah dengan Manajer. Bisakah Anda menjelaskan bagaimana kontrol itu dibalik? Dengan bantuan profesional (profesional seperti apa)? Bagaimana?
Istiaque Ahmed

@Istiaque Ahmed, membandingkan dengan garasi di mana para pekerja memiliki kendali penuh atas segalanya, manajer di pabrik mobil modern mengontrol produksi. Jadi sekarang pekerja dikontrol alih-alih mengendalikan. Sadarilah, manajer dalam konteks ini adalah bagian dari pabrik mobil modern, bukan bagian dari pekerja. Profesional adalah manajer yang profesional dalam perencanaan dan pembuatan mobil.
Luo Jiong Hui

2
Pesan untuk orang yang sudah menikah: jangan bercerai sekarang, kelas anak Anda juga dapat menerapkan IOC.
Julian

Ya, ini hanya visi saya tentang pernikahan juga IOC
balron

94

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:

  • Kode Anda akan dipisahkan sehingga Anda dapat dengan mudah bertukar implementasi antarmuka dengan implementasi alternatif
  • Ini adalah motivator yang kuat untuk pengkodean terhadap antarmuka, bukan implementasi
  • Sangat mudah untuk menulis unit test untuk kode Anda karena tergantung pada tidak lain dari objek yang diterimanya dalam konstruktor / setter dan Anda dapat dengan mudah menginisialisasi mereka dengan objek yang tepat secara terpisah.

Cons:

  • IoC tidak hanya membalikkan aliran kontrol dalam program Anda, tetapi juga membuatnya menjadi awan. Ini berarti Anda tidak bisa lagi hanya membaca kode Anda dan melompat dari satu tempat ke tempat lain karena koneksi yang biasanya ada dalam kode Anda tidak ada dalam kode lagi. Alih-alih itu dalam file konfigurasi XML atau anotasi dan dalam kode wadah IoC Anda yang menginterpretasikan metadata ini.
  • Muncul kelas bug baru di mana Anda mendapatkan konfigurasi XML atau penjelasan Anda salah dan Anda dapat menghabiskan banyak waktu mencari tahu mengapa wadah IoC Anda menyuntikkan referensi nol ke salah satu objek Anda dalam kondisi tertentu.

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.


3
Con pertama salah. Idealnya hanya ada 1 penggunaan wadah IOC dalam kode Anda, dan itu adalah metode utama Anda. Segala sesuatu yang lain harus mengalir turun dari sana
mwjackson

23
Saya pikir maksudnya adalah, Anda tidak bisa hanya membaca: myService.DoSomething () dan pergi ke definisi DoSomething, karena dengan IoC, myService hanyalah sebuah antarmuka, dan implementasi sebenarnya tidak diketahui oleh Anda, kecuali jika Anda melihat itu dalam file konfigurasi xml atau metode utama di mana ioc Anda mendapatkan pengaturan.
chrismay

7
Di situlah Resharper membantu - "klik buka implementasi" terhadap antarmuka. Menghindari IoC (atau lebih tepatnya DI dari contoh Anda) mungkin juga berarti Anda tidak menguji dengan benar
IThasTheAnswer

10
Re: ini 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 - saya pikir ini sangat menyesatkan. Hal yang sama dapat dikatakan tentang program apa pun yang ditulis di atas kerangka kerja. Perbedaannya dengan wadah IoC yang baik adalah bahwa Anda harus dapat, jika program Anda dirancang & ditulis dengan baik, keluarkan dan masukkan yang lain dengan sedikit perubahan pada kode Anda, atau buang IoC sama sekali dan buat objek Anda dengan tangan .
The Awnry Bear

7
Senang melihat jawaban dunia nyata seperti ini! Saya pikir ada banyak programmer yang berpengalaman, nyaman dengan desain berorientasi objek dan praktik TDD, sudah menggunakan antarmuka, pola pabrik, model yang didorong peristiwa dan mengejek di mana masuk akal, sebelum kata kunci "IoC" ini diciptakan. Sayangnya terlalu banyak pengembang / "arsitek" mengklaim praktik buruk jika Anda tidak menggunakan kerangka kerja pilihan mereka. Saya lebih suka desain yang lebih baik, penggunaan konsep dan alat bahasa bawaan, untuk mencapai tujuan yang sama dengan sebagian kecil dari kompleksitas, yaitu tanpa "mengaburkan" implementasi seperti yang Anda katakan :-)
Tony Wall

68
  1. 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.

  2. 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.

  3. 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.


37
Saya menemukan bahwa artikel Wikipedia sangat membingungkan dan perlu diperbaiki. Lihatlah halaman diskusi untuk tertawa.
devios1

Menulis loop acara Anda sendiri masih bisa menjadi inversi kontrol, jika loop peristiwa itu menggantikan kerangka kerja dan sisa kode menggunakan prinsip IoC Anda baru saja menulis kerangka kerja Anda sendiri. Ini sebenarnya bukan hal yang buruk, itu meningkatkan keterbacaan dengan harga hanya sedikit lebih banyak coding (bukan karena itu selalu tepat juga).
lijat

45

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.


3
Bagaimana Anda tahu bahwa Anda hanya akan memiliki satu pemeriksa ejaan?
Lacak

@ Jejak Anda bisa tahu bagaimana program yang akan Anda tulis akan digunakan misalnya. Masih beberapa teknik seperti injeksi ketergantungan sangat murah sehingga jarang ada alasan untuk tidak menggunakannya dalam kasus seperti ini.
lijat

44

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.


44

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.


26
  1. 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

  2. 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.

  3. 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.


2
Sebenarnya, IoC bukan terutama tentang mengelola dependensi. Silakan lihat martinfowler.com/articles/injection.html#InversionOfControl Secara khusus, perhatikan bagian yang mengatakan "Inversion of Control adalah istilah yang terlalu umum, dan dengan demikian orang-orang merasa membingungkan. Akibatnya dengan banyak diskusi dengan berbagai pendukung IoC kami menetap pada nama Ketergantungan Injeksi ".
Rogério

26

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 .


Ini bukan tentang pembuatan kelas atau objek, periksa martinfowler.com/articles/injection.html#InversionOfControl
Singh

22

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

Penjelasan detail


17

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 .


17

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 .


Wadah adalah konsep dalam IoC di mana model objek, termasuk dependensi (hubungan antara objek "pengguna" dan objek "bekas") dan instance objek, berada dan dikelola - misalnya, terkandung. Wadah biasanya disediakan oleh kerangka kerja IoC, seperti Spring. Anggap saja sebagai repositori runtime untuk objek yang membentuk aplikasi Anda.
The Awnry Bear

17

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: -


bukan objek statis tipe single?
Gokigooooks

16

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?


1
IoC! = Event driven. Persamaan (dan dalam beberapa kasus tumpang tindih), tetapi mereka pada dasarnya bukan paradigma yang sama.
The Awnry Bear

Pertanyaan bagus. Pemrograman yang digerakkan oleh IS tentunya adalah IOC. Kami menulis event handler dan mereka dipanggil dari loop acara. Tapi, IoC adalah konsep yang lebih umum daripada pemrograman yang digerakkan oleh acara .. Jika Anda mengganti metode dalam subkelas, itu juga semacam IoC. Anda menulis kode yang akan dipanggil ketika referensi yang sesuai (contoh) digunakan.
vi.su.

15

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.


5
Istri saya biasanya berbelanja dengan saya, tetapi saya setuju dengan pernyataan ini.
ha9u63ar

1
@ ha9u63ar Istri Anda berbelanja dengan Anda? Nah itu yang disebut agregasi.
Julian

2
Jika dia memberikan uang juga, itu disebut DI.
San

1
Kata Inversion - terbalik - berasal dari, ketika istri 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.
San

13

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:

  • Aplikasi membutuhkan Foo (misal pengontrol), jadi:
  • Aplikasi menciptakan Foo
  • Aplikasi memanggil Foo
    • Foo membutuhkan Bilah (misalnya layanan), jadi:
    • Foo menciptakan Bar
    • Foo memanggil Bar
      • Bar membutuhkan Bim (layanan, repositori, ...), jadi:
      • Bar menciptakan Bim
      • Bar melakukan sesuatu

Menggunakan injeksi ketergantungan

Berikut ini cara kerja kode menggunakan DI:

  • Aplikasi membutuhkan Foo, yang membutuhkan Bar, yang membutuhkan Bim, jadi:
  • Aplikasi menciptakan Bim
  • Aplikasi menciptakan Bar dan memberinya Bim
  • Aplikasi menciptakan Foo dan memberinya Bar
  • Aplikasi memanggil Foo
    • Foo memanggil Bar
      • Bar melakukan sesuatu

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 newkata 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 newobjek 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.


Ini harus menjadi jawaban yang paling benar karena satu-satunya yang menjelaskan bagaimana "kontrol" terbalik.
Yarimadam

Penjelasan terbaik sejauh ini
Ali80

12

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. "


12

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


Ini jawaban yang sangat jelas. Terima kasih untuk penjelasannya.
KunYu Tsai

11

IoC adalah tentang membalikkan hubungan antara kode Anda dan kode pihak ketiga (perpustakaan / kerangka kerja):

  • Dalam pengembangan s / w normal, Anda menulis metode utama () dan memanggil metode "pustaka". Anda memegang kendali :)
  • Di IoC "framework" mengontrol main () dan memanggil metode Anda. The Kerangka mengendalikan :(

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 :)


10

Saya suka penjelasan ini: http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/

Itu mulai sederhana dan menunjukkan contoh kode juga.

masukkan deskripsi gambar di sini

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.

masukkan deskripsi gambar di sini

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:

  • X tidak lagi bergantung pada Y
  • Lebih fleksibel, implementasi dapat diputuskan dalam runtime
  • Isolasi unit kode, pengujian lebih mudah

...


Tautan ini sangat membantu. Really Thanks :)
M Fuat NUROĞLU

10

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:

https://martinfowler.com/bliki/InversionOfControl.html

https://en.wikipedia.org/wiki/Inversion_of_control


1
Jawaban paling tepat yang saya temukan di sini.
blueray

8

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.


Tentang kelas / antarmuka yang membengkak: Anda tidak selalu harus menggunakan kembali setiap antarmuka. Terkadang masuk akal untuk membagi antarmuka yang besar menjadi banyak yang lebih kecil untuk melihat batas fungsionalnya. Antarmuka yang lebih kecil juga lebih mudah untuk digunakan kembali dalam implementasi lain. Juga mendorong Anda untuk kode ke antarmuka di mana pun masuk akal. Pertimbangkan "Segregasi Antarmuka". Hanya karena Anda menggunakan antarmuka bukan berarti Anda dipisahkan. Antarmuka gemuk tunggal tidak berguna. - Hanya 2 sen ku :)
MK

7

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).


6

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


5

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.


3
  1. Jadi nomor 1 di atas . Apa itu Pembalikan Kontrol?

  2. 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.



3

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.