Cara alternatif kanggo nyambungake modul piranti lunak

Ngganti dependensi langsung karo olahpesen

Kadhangkala modul mung kudu ngabari liyane sing sawetara acara / owah-owahan wis dumadi ing, lan ora Matter apa mengkono informasi iki mengko.

Ing kasus iki, modul ora perlu "ngerti saben liyane", yaiku, ngemot pranala langsung lan sesambungan langsung, nanging cukup mung kanggo ngganti pesen (pesen) utawa acara (acara).

Kadhangkala komunikasi modul liwat olahpesen luwih lemah tinimbang ketergantungan langsung. Pancen, amarga metode kasebut ora diarani, ora ana informasi babagan kelas kasebut. Nanging iki ora luwih saka khayalan.

Tinimbang jeneng metode, logika wiwit disambungake menyang jinis pesen, paramèter, lan data sing dikirim. Konektivitas modul kasebut diolesake.

Biyen kaya: kita nelpon metode - ana konektivitas, kita ora nelpon metode - ora ana konektivitas. Saiki mbayangno modul A wiwit ngirim data sing rada beda ing pesen kasebut. Lan ing wektu sing padha, kabeh modul sing gumantung ing pesen kasebut ora bakal bisa digunakake kanthi bener.

Umpamane, sadurunge, nalika nambah pangguna anyar, modul wewenang ngirim pesen USER_ADDED, lan sawise nganyari, mula ngirim pesen iki nalika nyoba ndhaptar lan uga nuduhake registrasi sing sukses utawa ora ing paramèter.

Mulane, penting banget kanggo ngetrapake mekanisme pesen kanthi cekap. Ana macem-macem template kanggo iki.

Pengamat. Digunakake ing kasus dependensi siji-kanggo-akeh, nalika akeh modul gumantung ing negara siji - sing utama. Iki nggunakake mekanisme mailing, sing tegese modul utama mung ngirim pesen sing padha menyang kabeh pelanggan, lan modul sing kasengsem ing informasi iki ngetrapake antarmuka "pelanggan" lan langganan mailing list.

Pendekatan iki akeh digunakake ing sistem kanthi antarmuka panganggo, saéngga inti saka aplikasi (model) tetep mandiri nalika ngandhani antarmuka sing ana gandhengane yen ana sing wis diganti lan kudu dianyari.

Ing kene format pesen standar ing tingkat sistem operasi, sing pangembang kudu ngurus kompatibilitas mundur lan dokumentasi sing apik.

Organisasi interaksi liwat distribusi pesen duwe "bonus" tambahan - eksistensi opsional saka "pelanggan" kanggo "diterbitake" (yaiku, dikirim) pesen. Sistem sing dirancang kanthi apik kaya iki ngidini modul bisa ditambah/dibusak kapan wae.

Bus pesen

Sampeyan bisa ngatur ijol-ijolan pesen lan nggunakake pola Mediator kanggo iki kanthi cara sing beda .

Iki digunakake nalika ana ketergantungan akeh-kanggo-akeh antarane modul. Mediator tumindak minangka perantara ing komunikasi antarane modul, tumindak minangka pusat komunikasi lan mbusak perlu kanggo modul kanggo eksplisit nuduhake siji liyane.

Akibaté, interaksi modul karo saben liyane ("kabeh karo kabeh") diganti dening interaksi modul mung karo perantara ("siji karo kabeh"). Mediator ngandika encapsulate interaksi antarane sawetara modul.

Iki sing diarani perantara pinter . Ing kana, pangembang asring miwiti nambah crutches, sing mengaruhi prilaku modul individu kanthi nguripake / mateni nampa pesen tartamtu.

Conto nyata sing khas yaiku kontrol lalu lintas bandara. Kabeh pesen saka pesawat menyang menara kontrol controller tinimbang dikirim langsung antarane pesawat. Lan pengontrol wis nggawe keputusan babagan pesawat sing bisa mabur utawa ndharat, lan uga ngirim pesen menyang pesawat kasebut.

Penting! Modul bisa ngirim saben liyane ora mung pesen prasaja, nanging uga prentah obyek. Interaksi kasebut diterangake dening cithakan Command . Ing ngisor iki kanggo encapsulate panjalukan kanggo nindakake tumindak tartamtu minangka obyek kapisah.

Ing kasunyatan, obyek iki ngandhut siji cara eksekusi () , sing banjur ngijini sampeyan kanggo pass tumindak iki kanggo modul liyane kanggo eksekusi minangka parameter lan umume nindakake operasi sembarang karo obyek printah sing bisa dileksanakake ing obyek biasa.

Hukum Demeter

Hukum Demeter nglarang nggunakake dependensi implisit: "Obyek A kudu ora bisa ngakses obyek C kanthi langsung yen obyek A nduweni akses menyang obyek B lan obyek B nduweni akses menyang obyek C."

Iki tegese kabeh dependensi ing kode kudu "eksplisit" - kelas / modul mung bisa nggunakake "dependensi" ing karya lan ora kudu pindhah menyang wong liya. Conto sing apik yaiku arsitektur telung tingkat. Lapisan antarmuka kudu bisa digunakake karo lapisan logika, nanging ora kudu sesambungan langsung karo lapisan basis data.

Secara ringkes, prinsip iki uga dirumusake kanthi cara iki: "Sesambungan mung karo kanca-kanca langsung, lan ora karo kanca-kanca." Iki entuk kurang koherensi kode, uga visibilitas lan transparansi desain sing luwih gedhe.

Hukum Demeter ngetrapake "prinsip kawruh minimal" sing wis kasebut, sing dadi basis kopling sing longgar lan kalebu kasunyatan manawa obyek / modul kudu ngerti sawetara rincian babagan struktur lan sifat obyek / modul liyane lan apa wae ing umum, kalebu komponen dhewe .

Analogi saka urip: yen sampeyan pengin asu mlayu, bodho mrentahake paws, luwih becik menehi prentah marang asu, lan dheweke bakal ngatasi paws dhewe.

Komposisi tinimbang warisan

Iki minangka topik sing gedhe banget lan menarik lan paling ora ana kuliah sing kapisah. Akeh salinan sing rusak ing topik iki ing Internet nganti konsensus tekan - kita nggunakake warisan minimal, komposisi - maksimal.

Intine yaiku warisan sejatine nyedhiyakake sambungan sing paling kuat ing antarane kelas, mula kudu dihindari. Topik iki uga dibahas ing artikel Herb Sutter " Prefer Composition Over Inheritance ".

Nalika sampeyan miwiti sinau pola desain, sampeyan bakal nemokake akeh pola sing ngatur nggawe obyek utawa struktur internal. Miturut cara, aku bisa menehi saran ing konteks iki kanggo mbayar manungsa waé menyang pola Delegasi / Delegasi lan pola Komponen , sing teka saka game .

Kita bakal ngomong luwih akeh babagan pola mengko.