9.1 Inversi Dependensi
Elinga, kita nate ujar manawa ing aplikasi server sampeyan ora bisa nggawe stream liwat new Thread().start()? Mung wadhah sing kudu nggawe benang. Saiki kita bakal ngembangake ide iki luwih maju.
Kabeh obyek uga kudu digawe mung dening wadhah . Mesthine, kita ora ngomong babagan kabeh obyek, nanging babagan obyek sing diarani bisnis. Dheweke uga asring diarani tong sampah. Sikil pendekatan iki tuwuh saka prinsip SOLID kaping lima, sing mbutuhake nyisihake kelas lan pindhah menyang antarmuka:
- Modul tingkat ndhuwur ngirim ora gumantung ing modul tingkat ngisor. Loro-lorone, lan liya-liyane kudu gumantung ing abstraksi.
- Abstraksi ngirim ora gumantung ing rincian. Implementasine kudu gumantung saka abstraksi.
Modul ngirim ora ngemot referensi kanggo implementasine tartamtu, lan kabeh dependensi lan interaksi antarane wong-wong mau kudu dibangun mung ing basis saka abstraksi (yaiku, antarmuka). Inti saka aturan iki bisa ditulis ing siji frase: kabeh dependensi kudu ing wangun antarmuka .
Senadyan sifat dhasar lan kesederhanaan sing katon, aturan iki paling kerep dilanggar. Yaiku, saben-saben kita nggunakake operator anyar ing kode program / modul lan nggawe obyek anyar saka jinis tartamtu, saéngga, tinimbang gumantung ing antarmuka, katergantungan ing implementasine kawangun.
Cetha yen iki ora bisa dihindari lan obyek kudu digawe ing endi wae. Nanging, paling ora, sampeyan kudu nyilikake jumlah papan sing ditindakake lan kelas sing ditemtokake kanthi jelas, uga lokalisasi lan ngisolasi papan kasebut supaya ora kasebar ing kode program.
Solusi sing apik banget yaiku ide gila kanggo konsentrasi nggawe obyek anyar ing obyek lan modul khusus - pabrik, lokasi layanan, wadah IoC.
Ing pangertèn, kaputusan kuwi nderek Prinsip Pilihan Tunggal, kang ngandika: "Nalika sistem piranti lunak kudu ndhukung akeh alternatif, dhaptar lengkap kudu ngerti mung siji modul saka sistem" .
Mulane, yen ing mangsa ngarep perlu kanggo nambah opsi anyar (utawa implementasi anyar, kaya ing kasus nggawe obyek anyar kita considering), banjur bakal cukup kanggo nganyari mung modul sing ngemot informasi iki, lan kabeh modul liyane. bakal tetep ora kena pengaruh lan bakal bisa nerusake karyane.kaya biasane.
Tuladha 1
new ArrayList Tinimbang nulis kaya , iku bakal nggawe pangertèn List.new()kanggo JDK kanggo nyedhiyani sampeyan karo implementasine bener saka rwaning: ArrayList, LinkedList, utawa malah ConcurrentList.
Contone, kompiler ndeleng manawa ana panggilan menyang obyek saka benang sing beda-beda lan nempatake implementasi aman thread ing kana. Utawa akeh banget sisipan ing tengah sheet, banjur implementasine bakal adhedhasar LinkedList.
Tuladha 2
Iki wis kedaden karo limo, contone,. Nalika pungkasan sampeyan nulis algoritma pangurutan kanggo ngurutake koleksi? Nanging, saiki kabeh wong nggunakake cara Collections.sort(), lan unsur koleksi kudu ndhukung antarmuka Comparable (comparable).
Yen sort()sampeyan pass koleksi kurang saka 10 unsur kanggo cara, iku cukup bisa kanggo Ngurutake karo urutan gelembung (Gelembung Urut), lan ora Quicksort.
Tuladha 3
Compiler wis nonton carane sampeyan concatenate strings lan bakal ngganti kode karo StringBuilder.append().
9.2 Inversi dependensi ing laku
Saiki sing paling menarik: ayo dipikirake carane bisa nggabungake teori lan praktik. Kepiye modul bisa nggawe lan nampa "ketergantungan" kanthi bener lan ora nglanggar Inversi Dependensi?
Kanggo nindakake iki, nalika ngrancang modul, sampeyan kudu mutusake dhewe:
- apa modul ora, apa fungsi nindakake;
- banjur modul perlu saka lingkungane, yaiku, obyek / modul apa sing kudu ditangani;
- Lan carane dheweke bakal entuk?
Kanggo netepi prinsip Inversi Dependensi, sampeyan kudu mutusake obyek eksternal apa sing digunakake modul sampeyan lan kepiye entuk referensi.
Lan ing ngisor iki pilihan ing ngisor iki:
- modul dhewe nggawe obyek;
- modul njupuk obyek saka wadhah;
- modul wis ora idea saka ngendi obyek teka saka.
Masalahe yaiku kanggo nggawe obyek, sampeyan kudu nelpon konstruktor saka jinis tartamtu, lan minangka asil, modul ora gumantung ing antarmuka, nanging ing implementasine tartamtu. Nanging yen kita ora pengin obyek digawe kanthi jelas ing kode modul, mula kita bisa nggunakake pola Metode Pabrik .
"Ing ngisor iki tinimbang langsung instantiating obyek liwat anyar, kita nyedhiyani kelas klien karo sawetara antarmuka kanggo nggawe obyek. Wiwit antarmuka kuwi tansah bisa ditindhes karo desain tengen, kita njaluk sawetara keluwesan nalika nggunakake modul-tingkat kurang. ing modul tingkat dhuwur " .
Ing kasus sing perlu kanggo nggawe klompok utawa kulawarga obyek sing gegandhengan, pabrik Abstrak digunakake tinimbang Cara Pabrik .
9.3 Nggunakake Service Locator
Modul njupuk obyek sing dibutuhake saka sing wis duwe. Dianggep sistem kasebut duwe sawetara repositori obyek, ing ngendi modul bisa "nyelehake" obyek lan "njupuk" obyek saka gudang.
Pendekatan iki dileksanakake dening pola Service Locator , gagasan utama yaiku program kasebut nduweni obyek sing ngerti carane entuk kabeh dependensi (layanan) sing bisa uga dibutuhake.
Bentenipun utama saka pabrik iku Service Locator ora nggawe obyek, nanging bener wis ngemot obyek instantiated (utawa ngerti ngendi / carane njaluk, lan yen nggawe, banjur mung sapisan ing telpon pisanan). Pabrik ing saben telpon nggawe obyek anyar sing entuk kepemilikan lengkap lan sampeyan bisa nindakake apa wae sing dikarepake.
Penting ! Locator layanan ngasilake referensi kanggo obyek sing wis ana . Mulane, sampeyan kudu ati-ati banget karo obyek sing ditanggepi dening Service Locator, amarga wong liya bisa nggunakake ing wektu sing padha.
Obyek ing Service Locator bisa ditambahake langsung liwat file konfigurasi, lan tenan ing sembarang cara trep kanggo programmer. Service Locator dhewe bisa dadi kelas statis kanthi sakumpulan metode statis, singleton, utawa antarmuka, lan bisa dikirim menyang kelas sing dibutuhake liwat konstruktor utawa metode.
Service Locator kadhangkala disebut anti-pola lan pundung (amarga nggawe sambungan implisit lan mung menehi tampilan desain apik). Sampeyan bisa maca liyane saka Mark Seaman:
9.4 Injeksi gumantung
Modul kasebut ora peduli babagan dependensi "tambang". Iki mung nemtokake apa sing kudu ditindakake, lan kabeh dependensi sing dibutuhake diwenehake (dikenalake) saka njaba dening wong liya.
Iki sing diarani - Injeksi Ketergantungan . Biasane, dependensi sing dibutuhake diterusake minangka parameter konstruktor (Injeksi Konstruktor) utawa liwat metode kelas (injeksi Setter).
Pendekatan iki ngowahi proses nggawe dependensi - tinimbang modul dhewe, nggawe dependensi dikontrol dening wong saka njaba. Modul saka emitor aktif obyek dadi pasif - dudu dheweke sing nggawe, nanging wong liya nggawe kanggo dheweke.
Owah-owahan arah iki diarani Inversion of Control , utawa Prinsip Hollywood - "Aja nelpon kita, kita bakal nelpon sampeyan."
Iki minangka solusi sing paling fleksibel, menehi modul otonomi paling gedhe . Kita bisa ujar manawa mung ngetrapake "Prinsip Tanggung Jawab Tunggal" - modul kasebut kudu fokus banget kanggo nindakake tugas kanthi apik lan ora kuwatir babagan liya.
Nyedhiyakake modul karo kabeh sing perlu kanggo karya minangka tugas sing kapisah, sing kudu ditangani dening "spesialis" sing cocog (biasane wadhah tartamtu, wadhah IoC, tanggung jawab kanggo ngatur dependensi lan implementasine).
Nyatane, kabeh ing kene kaya urip: ing perusahaan sing wis diatur kanthi apik, program programer, lan meja, komputer lan kabeh sing dibutuhake kanggo kerja dituku lan diwenehake dening manajer kantor. Utawa, yen sampeyan nggunakake metafora program minangka konstruktor, modul ora kudu mikir bab kabel, wong liya melu ngrakit konstruktor, lan ora bagean dhewe.
Iku ora bakal exaggeration ngomong sing nggunakake antarmuka kanggo njlèntrèhaké dependensi antarane modul (Dependency Inversion) + nggawe bener lan injeksi dependensi iki (utamané Dependency Injection) Techniques tombol kanggo decoupling .
Padha ngawula minangka pondasi sing kopling ngeculke kode, keluwesan sawijining, resistance kanggo owah-owahan, nggunakake maneh, lan tanpa kang kabeh Techniques liyane nggawe sethitik pangertèn. Iki minangka pondasi kopling sing longgar lan arsitektur sing apik.
Prinsip Inversion of Control (bebarengan karo Dependency Injection lan Service Locator) dibahas kanthi rinci dening Martin Fowler. Ana terjemahan saka loro artikel kasebut: "Inversion of Control Containers and the Dependency Injection pattern" lan "Inversion of Control" .