CodeGym /Java Course /Modul 3 /Cara alternatif untuk menghubungkan modul perangkat lunak...

Cara alternatif untuk menghubungkan modul perangkat lunak

Modul 3
Level 14 , Pelajaran 9
Tersedia

Mengganti ketergantungan langsung dengan perpesanan

Terkadang modul hanya perlu memberi tahu orang lain bahwa beberapa peristiwa/perubahan telah terjadi di dalamnya, dan tidak masalah apa yang terjadi pada informasi ini nanti.

Dalam hal ini, modul sama sekali tidak perlu "saling mengenal", yaitu berisi tautan langsung dan berinteraksi secara langsung, tetapi cukup hanya bertukar pesan (pesan) atau peristiwa (peristiwa).

Terkadang tampaknya komunikasi modul melalui perpesanan jauh lebih lemah daripada ketergantungan langsung. Memang, karena metodenya tidak dipanggil, tidak ada informasi tentang kelasnya. Tapi ini tidak lebih dari ilusi.

Alih-alih nama metode, logika mulai diikat ke jenis pesan, parameternya, dan data yang dikirimkan. Konektivitas modul semacam itu tercoreng.

Dulu seperti: kami memanggil metode - ada konektivitas, kami tidak memanggil metode - tidak ada konektivitas. Sekarang bayangkan modul A mulai mengirimkan data yang sedikit berbeda dalam pesannya. Dan pada saat yang sama, semua modul yang bergantung pada pesan ini tidak akan berfungsi dengan benar.

Misalkan, sebelumnya, saat menambahkan pengguna baru, modul otorisasi mengirim pesan USER_ADDED, dan setelah pembaruan, mulai mengirim pesan ini saat mencoba mendaftar dan juga menunjukkan pendaftaran berhasil atau tidak di parameter.

Oleh karena itu, sangat penting untuk mengimplementasikan mekanisme pesan dengan sangat kompeten. Ada berbagai template untuk ini.

Pengamat. Ini digunakan dalam kasus ketergantungan satu-ke-banyak, ketika banyak modul bergantung pada keadaan satu - yang utama. Ini menggunakan mekanisme surat, yang berarti bahwa modul utama hanya mengirimkan pesan yang sama ke semua pelanggannya, dan modul yang tertarik dengan informasi ini mengimplementasikan antarmuka "pelanggan" dan berlangganan milis.

Pendekatan ini banyak digunakan dalam sistem dengan antarmuka pengguna, yang memungkinkan inti aplikasi (model) tetap independen sambil menginformasikan antarmuka terkait bahwa ada sesuatu yang telah berubah dan perlu diperbarui.

Di sini format pesan distandarisasi pada tingkat sistem operasi, yang pengembangnya harus menjaga kompatibilitas mundur dan dokumentasi yang baik.

Organisasi interaksi melalui distribusi pesan memiliki "bonus" tambahan - keberadaan opsional "pelanggan" untuk pesan "diterbitkan" (yaitu, dikirim). Sistem yang dirancang dengan baik seperti ini memungkinkan modul ditambahkan/dihapus kapan saja.

Bus pesan

Anda dapat mengatur pertukaran pesan dan menggunakan pola Mediator untuk ini dengan cara yang berbeda .

Ini digunakan ketika ada ketergantungan banyak-ke-banyak antar modul. Mediator bertindak sebagai perantara dalam komunikasi antar modul, bertindak sebagai pusat komunikasi dan menghilangkan kebutuhan modul untuk secara eksplisit merujuk satu sama lain.

Akibatnya, interaksi modul satu sama lain ("semua dengan semua") digantikan oleh interaksi modul hanya dengan perantara ("satu dengan semua"). Mediator dikatakan merangkum interaksi antara beberapa modul.

Bus pesan

Inilah yang disebut perantara pintar . Di sanalah pengembang paling sering mulai menambahkan kruk mereka, yang memengaruhi perilaku masing-masing modul dengan menghidupkan / mematikan penerimaan pesan tertentu.

Contoh kehidupan nyata yang khas adalah kontrol lalu lintas bandara. Semua pesan dari pesawat dikirim ke menara kontrol pengontrol alih-alih dikirim langsung antar pesawat. Dan pengontrol sudah membuat keputusan tentang pesawat mana yang bisa lepas landas atau mendarat, dan, pada gilirannya, mengirim pesan ke pesawat.

Penting! Modul dapat saling mengirim tidak hanya pesan sederhana, tetapi juga objek perintah. Interaksi seperti itu dijelaskan oleh templat Perintah . Intinya adalah merangkum permintaan untuk melakukan tindakan tertentu sebagai objek terpisah.

Faktanya, objek ini berisi satu metode execution() , yang kemudian memungkinkan Anda meneruskan tindakan ini ke modul lain untuk dieksekusi sebagai parameter dan umumnya melakukan operasi apa pun dengan objek perintah yang dapat dilakukan pada objek biasa.

Hukum Demeter

Hukum Demeter melarang penggunaan dependensi implisit: "Objek A tidak boleh langsung mengakses objek C jika objek A memiliki akses ke objek B dan objek B memiliki akses ke objek C."

Ini berarti bahwa semua dependensi dalam kode harus "eksplisit" - kelas / modul hanya dapat menggunakan "ketergantungan mereka" dalam pekerjaan mereka dan tidak boleh memanjatnya ke orang lain. Contoh yang baik adalah arsitektur tiga tingkat. Lapisan antarmuka harus bekerja dengan lapisan logika, tetapi tidak boleh berinteraksi langsung dengan lapisan basis data.

Singkatnya, prinsip ini juga dirumuskan sebagai berikut: "Berinteraksi hanya dengan teman dekat, bukan dengan teman dari teman." Ini mencapai koherensi kode yang lebih sedikit, serta visibilitas dan transparansi desain yang lebih besar.

Hukum Demeter mengimplementasikan "prinsip pengetahuan minimum" yang telah disebutkan, yang merupakan dasar dari kopling longgar dan terdiri dari fakta bahwa objek / modul harus mengetahui sesedikit mungkin detail tentang struktur dan properti objek / modul lain dan apa pun secara umum, termasuk komponennya sendiri .

Sebuah analogi dari kehidupan: jika Anda ingin anjing berlari, itu bodoh untuk memerintahkan cakarnya, lebih baik memberi perintah kepada anjing, dan dia akan menangani cakarnya sendiri.

Komposisi bukannya warisan

Ini adalah topik yang sangat besar dan menarik dan setidaknya membutuhkan kuliah terpisah. Banyak salinan yang rusak tentang topik ini di Internet sampai konsensus tercapai - kami menggunakan warisan seminimal mungkin, komposisi - maksimal.

Intinya adalah bahwa pewarisan sebenarnya memberikan koneksi terkuat antar kelas, sehingga harus dihindari. Topik ini tercakup dengan baik dalam artikel Herb Sutter " Lebih Memilih Komposisi Daripada Warisan ".

Saat Anda mulai mempelajari pola desain, Anda akan menemukan banyak sekali pola yang mengatur pembuatan objek atau struktur internalnya. Omong-omong, saya dapat menyarankan dalam konteks ini untuk memperhatikan pola Delegasi / Delegasi dan pola Komponen , yang berasal dari games .

Kami akan berbicara lebih banyak tentang pola nanti.

3
Опрос
Software architecture, client-server architecture, MVC,  14 уровень,  9 лекция
недоступен
Software architecture, client-server architecture, MVC
Software architecture, client-server architecture, MVC
Komentar
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION