9.1 Penyongsangan Ketergantungan
Ingat, kami pernah berkata bahawa dalam aplikasi pelayan anda tidak boleh membuat strim melalui new Thread().start()? Hanya bekas yang harus mencipta benang. Kami kini akan mengembangkan idea ini lebih jauh lagi.
Semua objek juga harus dibuat hanya oleh bekas . Sudah tentu, kita tidak bercakap tentang semua objek, tetapi lebih kepada apa yang dipanggil objek perniagaan. Mereka juga sering dirujuk sebagai tong sampah. Kaki pendekatan ini berkembang daripada prinsip kelima SOLID, yang memerlukan menyingkirkan kelas dan beralih ke antara muka:
- Modul peringkat atas tidak boleh bergantung pada modul peringkat rendah. Kedua-dua itu, dan lain-lain harus bergantung pada abstraksi.
- Abstraksi tidak boleh bergantung pada butiran. Pelaksanaan mesti bergantung kepada abstraksi.
Modul tidak boleh mengandungi rujukan kepada pelaksanaan tertentu, dan semua kebergantungan dan interaksi antara mereka hendaklah dibina semata-mata berdasarkan abstraksi (iaitu, antara muka). Intipati peraturan ini boleh ditulis dalam satu frasa: semua kebergantungan mestilah dalam bentuk antara muka .
Walaupun sifat asasnya dan kesederhanaan yang jelas, peraturan ini paling kerap dilanggar. Iaitu, setiap kali apabila kita menggunakan operator baru dalam kod program/modul dan mencipta objek baharu jenis tertentu, oleh itu, bukannya bergantung pada antara muka, pergantungan pada pelaksanaan terbentuk.
Adalah jelas bahawa ini tidak boleh dielakkan dan objek mesti dicipta di suatu tempat. Tetapi, sekurang-kurangnya, anda perlu meminimumkan bilangan tempat di mana ini dilakukan dan di mana kelas dinyatakan secara eksplisit, serta menyetempatkan dan mengasingkan tempat tersebut supaya ia tidak bertaburan di seluruh kod program.
Penyelesaian yang sangat baik ialah idea gila untuk menumpukan penciptaan objek baharu dalam objek dan modul khusus - kilang, pencari perkhidmatan, bekas IoC.
Dari satu segi, keputusan sedemikian mengikut Prinsip Pilihan Tunggal, yang mengatakan: "Apabila sistem perisian mesti menyokong banyak alternatif, senarai lengkapnya hendaklah diketahui hanya oleh satu modul sistem" .
Oleh itu, jika pada masa akan datang adalah perlu untuk menambah pilihan baru (atau pelaksanaan baru, seperti dalam hal mencipta objek baru yang sedang kita pertimbangkan), maka sudah cukup untuk mengemas kini hanya modul yang mengandungi maklumat ini, dan semua modul lain. akan kekal tidak terjejas dan akan dapat meneruskan kerja mereka.seperti biasa.
Contoh 1
new ArrayList Daripada menulis sesuatu seperti , adalah masuk akal List.new()untuk JDK menyediakan anda dengan pelaksanaan daun yang betul: ArrayList, LinkedList atau ConcurrentList.
Sebagai contoh, pengkompil melihat bahawa terdapat panggilan ke objek daripada benang yang berbeza dan meletakkan pelaksanaan selamat benang di sana. Atau terlalu banyak sisipan di tengah helaian, maka pelaksanaan akan berdasarkan LinkedList.
Contoh 2
Ini telah berlaku dengan pelbagai, sebagai contoh. Bilakah kali terakhir anda menulis algoritma pengisihan untuk mengisih koleksi? Sebaliknya, kini semua orang menggunakan kaedah Collections.sort(), dan elemen koleksi mesti menyokong antara muka Sebanding (sebanding).
Jika sort()anda menghantar koleksi kurang daripada 10 elemen kepada kaedah, adalah agak mungkin untuk mengisihnya dengan jenis gelembung (Isih gelembung), dan bukan Quicksort.
Contoh 3
Pengkompil sudah melihat cara anda menggabungkan rentetan dan akan menggantikan kod anda dengan StringBuilder.append().
9.2 Penyongsangan kebergantungan dalam amalan
Sekarang yang paling menarik: mari kita fikirkan bagaimana kita boleh menggabungkan teori dan amalan. Bagaimanakah modul boleh mencipta dan menerima "kebergantungan" dengan betul dan tidak melanggar Penyongsangan Ketergantungan?
Untuk melakukan ini, apabila mereka bentuk modul, anda mesti membuat keputusan sendiri:
- apa yang modul lakukan, apakah fungsi yang dilakukannya;
- maka modul memerlukan dari persekitarannya, iaitu, objek / modul apa yang perlu ditanganinya;
- Dan bagaimana dia akan mendapatkannya?
Untuk mematuhi prinsip Penyongsangan Ketergantungan, anda pastinya perlu memutuskan objek luaran yang modul anda gunakan dan cara ia akan mendapat rujukan kepada mereka.
Dan berikut adalah pilihan berikut:
- modul itu sendiri mencipta objek;
- modul mengambil objek dari bekas;
- modul tidak tahu dari mana objek itu datang.
Masalahnya ialah untuk mencipta objek, anda perlu memanggil pembina jenis tertentu, dan sebagai hasilnya, modul tidak bergantung pada antara muka, tetapi pada pelaksanaan khusus. Tetapi jika kita tidak mahu objek dibuat secara eksplisit dalam kod modul, maka kita boleh menggunakan corak Kaedah Kilang .
"Intinya ialah daripada membuat instantiate secara langsung objek melalui baharu, kami menyediakan kelas pelanggan dengan beberapa antara muka untuk mencipta objek. Memandangkan antara muka sedemikian sentiasa boleh ditindih dengan reka bentuk yang betul, kami mendapat sedikit fleksibiliti apabila menggunakan modul peringkat rendah dalam modul peringkat tinggi" .
Dalam kes di mana perlu untuk membuat kumpulan atau keluarga objek berkaitan, kilang Abstrak digunakan dan bukannya Kaedah Kilang .
9.3 Menggunakan Pencari Perkhidmatan
Modul mengambil objek yang diperlukan daripada yang sudah memilikinya. Diandaikan bahawa sistem mempunyai beberapa repositori objek, di mana modul boleh "meletakkan" objek mereka dan "mengambil" objek dari repositori.
Pendekatan ini dilaksanakan oleh corak Service Locator , idea utamanya ialah program ini mempunyai objek yang mengetahui cara mendapatkan semua kebergantungan (perkhidmatan) yang mungkin diperlukan.
Perbezaan utama dari kilang ialah Service Locator tidak mencipta objek, tetapi sebenarnya sudah mengandungi objek instantiated (atau tahu di mana / bagaimana untuk mendapatkannya, dan jika ia mencipta, maka hanya sekali pada panggilan pertama). Kilang pada setiap panggilan mencipta objek baharu yang anda mendapat pemilikan penuh dan anda boleh melakukan apa sahaja yang anda mahu dengannya.
penting ! Pencari perkhidmatan menghasilkan rujukan kepada objek sedia ada yang sama . Oleh itu, anda perlu berhati-hati dengan objek yang dikeluarkan oleh Service Locator, kerana orang lain boleh menggunakannya pada masa yang sama dengan anda.
Objek dalam Pencari Perkhidmatan boleh ditambah terus melalui fail konfigurasi, dan sememangnya dalam apa jua cara yang sesuai untuk pengaturcara. Service Locator itu sendiri boleh menjadi kelas statik dengan satu set kaedah statik, tunggal atau antara muka, dan boleh dihantar ke kelas yang diperlukan melalui pembina atau kaedah.
Pencari Perkhidmatan kadangkala dipanggil anti-corak dan tidak digalakkan (kerana ia mewujudkan sambungan tersirat dan hanya memberikan rupa reka bentuk yang baik). Anda boleh membaca lebih lanjut dari Mark Seaman:
9.4 Suntikan Ketergantungan
Modul ini tidak mengambil berat tentang kebergantungan "perlombongan" sama sekali. Ia hanya menentukan perkara yang diperlukan untuk berfungsi, dan semua kebergantungan yang diperlukan dibekalkan (diperkenalkan) dari luar oleh orang lain.
Inilah yang dipanggil - Suntikan Ketergantungan . Biasanya, kebergantungan yang diperlukan diluluskan sama ada sebagai parameter pembina (Constructor Injection) atau melalui kaedah kelas (Setter injection).
Pendekatan ini menyongsangkan proses mencipta kebergantungan - bukannya modul itu sendiri, penciptaan kebergantungan dikawal oleh seseorang dari luar. Modul dari pemancar aktif objek menjadi pasif - bukan dia yang mencipta, tetapi orang lain mencipta untuknya.
Perubahan arah ini dipanggil Inversion of Control , atau Prinsip Hollywood - "Jangan hubungi kami, kami akan hubungi anda."
Ini adalah penyelesaian yang paling fleksibel, memberikan modul autonomi terbesar . Kita boleh katakan bahawa hanya ia melaksanakan sepenuhnya "Prinsip Tanggungjawab Tunggal" - modul harus memberi tumpuan sepenuhnya untuk melakukan tugasnya dengan baik dan tidak membimbangkan tentang perkara lain.
Menyediakan modul dengan semua yang diperlukan untuk kerja adalah tugas yang berasingan, yang harus dikendalikan oleh "pakar" yang sesuai (biasanya bekas tertentu, bekas IoC, bertanggungjawab untuk mengurus kebergantungan dan pelaksanaannya).
Sebenarnya, segala-galanya di sini adalah seperti dalam kehidupan: dalam syarikat yang teratur, program pengaturcara, dan meja, komputer dan semua yang mereka perlukan untuk bekerja dibeli dan disediakan oleh pengurus pejabat. Atau, jika anda menggunakan metafora program sebagai pembina, modul tidak sepatutnya memikirkan wayar, orang lain terlibat dalam memasang pembina, dan bukan bahagian itu sendiri.
Tidaklah keterlaluan untuk mengatakan bahawa penggunaan antara muka untuk menerangkan kebergantungan antara modul (Penyongsangan Ketergantungan) + penciptaan dan suntikan kebergantungan yang betul ini (terutamanya Suntikan Ketergantungan) ialah teknik utama untuk penyahgandingan .
Ia berfungsi sebagai asas di mana gandingan longgar kod, fleksibilitinya, ketahanan terhadap perubahan, penggunaan semula, dan tanpanya semua teknik lain tidak masuk akal. Ini adalah asas gandingan longgar dan seni bina yang baik.
Prinsip Penyongsangan Kawalan (bersama Suntikan Ketergantungan dan Pencari Perkhidmatan) dibincangkan secara terperinci oleh Martin Fowler. Terdapat terjemahan kedua-dua artikelnya: "Penyongsangan Bekas Kawalan dan corak Suntikan Ketergantungan" dan "Penyongsangan Kawalan" .