Pinapalitan ang mga direktang dependency ng pagmemensahe
Minsan kailangan lang ipaalam ng isang module sa iba na may ilang kaganapan/pagbabago na naganap dito, at hindi mahalaga kung ano ang mangyayari sa impormasyong ito sa ibang pagkakataon.
Sa kasong ito, ang mga module ay hindi kailangang "alam sa isa't isa" sa lahat, iyon ay, naglalaman ng mga direktang link at direktang nakikipag-ugnayan, ngunit sapat lamang na makipagpalitan ng mga mensahe (mensahe) o mga kaganapan (mga kaganapan).
Minsan tila mas mahina ang komunikasyon ng module sa pamamagitan ng pagmemensahe kaysa sa direktang dependency. Sa katunayan, dahil ang mga pamamaraan ay hindi tinatawag, walang impormasyon tungkol sa mga klase. Ngunit ito ay walang iba kundi isang ilusyon.
Sa halip na mga pangalan ng pamamaraan, ang lohika ay nagsisimulang maiugnay sa mga uri ng mensahe, kanilang mga parameter, at ipinadalang data. Ang pagkakakonekta ng naturang mga module ay smeared.
Dati ay tulad ng: tinatawag namin ang mga pamamaraan - mayroong koneksyon, hindi kami tumawag ng mga pamamaraan - walang koneksyon. Ngayon isipin na ang module A ay nagsimulang magpadala ng bahagyang naiibang data sa mga mensahe nito. At kasabay nito, ang lahat ng mga module na nakasalalay sa mga mensaheng ito ay hindi gagana nang tama.
Ipagpalagay, mas maaga, kapag nagdagdag ng bagong user, ang authorization module ay nagpadala ng mensaheng USER_ADDED, at pagkatapos ng pag-update, nagsimula itong ipadala ang mensaheng ito kapag sinusubukang magrehistro at bilang karagdagan ay nagpapahiwatig ng matagumpay na pagpaparehistro o wala sa mga parameter.
Samakatuwid, napakahalaga na ipatupad ang mekanismo ng mensahe nang napakahusay. Mayroong iba't ibang mga template para dito.
Tagamasid. Ginagamit ito sa kaso ng isa-sa-maraming dependency, kapag maraming mga module ang nakasalalay sa estado ng isa - ang pangunahing isa. Ginagamit nito ang mekanismo ng pag-mail, na nangangahulugan na ang pangunahing module ay nagpapadala lamang ng parehong mga mensahe sa lahat ng mga subscriber nito, at ang mga module na interesado sa impormasyong ito ay nagpapatupad ng interface ng "subscriber" at mag-subscribe sa mailing list.
Ang diskarte na ito ay malawakang ginagamit sa mga system na may user interface, na nagpapahintulot sa core ng application (modelo) na manatiling independiyente habang ipinapaalam sa mga nauugnay na interface nito na may nagbago at kailangang i-update.
Dito ang format ng mensahe ay na-standardize sa antas ng operating system, na ang mga developer ay dapat mag-ingat sa backward compatibility at magandang dokumentasyon.
Ang organisasyon ng pakikipag-ugnayan sa pamamagitan ng pamamahagi ng mga mensahe ay may karagdagang "bonus" - ang opsyonal na pagkakaroon ng "mga subscriber" sa "na-publish" (iyon ay, ipinadala) na mga mensahe. Ang isang mahusay na idinisenyong sistema na tulad nito ay nagbibigay-daan sa mga module na maidagdag/maalis anumang oras.
Bus ng pagmemensahe
Maaari mong ayusin ang pagpapalitan ng mga mensahe at gamitin ang pattern ng Tagapamagitan para dito sa ibang paraan .
Ito ay ginagamit kapag mayroong maraming-sa-maraming dependency sa pagitan ng mga module. Ang tagapamagitan ay gumaganap bilang isang tagapamagitan sa komunikasyon sa pagitan ng mga module, kumikilos bilang isang sentro ng komunikasyon at inaalis ang pangangailangan para sa mga module na tahasang sumangguni sa isa't isa.
Bilang resulta, ang pakikipag-ugnayan ng mga module sa isa't isa ("lahat sa lahat") ay pinalitan ng pakikipag-ugnayan ng mga module lamang sa isang tagapamagitan ("isa sa lahat"). Sinasabing ang tagapamagitan ay nagpapaloob sa pakikipag-ugnayan sa pagitan ng maraming mga module.
Ito ang tinatawag na smart intermediary . Doon ang mga developer ay madalas na nagsisimulang magdagdag ng kanilang mga saklay, na nakakaimpluwensya sa pag-uugali ng mga indibidwal na module sa pamamagitan ng pag-on / off sa pagtanggap ng ilang mga mensahe.
Ang isang karaniwang halimbawa sa totoong buhay ay ang kontrol sa trapiko sa paliparan. Ang lahat ng mga mensahe mula sa sasakyang panghimpapawid ay pumupunta sa control tower ng controller sa halip na direktang ipadala sa pagitan ng sasakyang panghimpapawid. At ang controller ay gumagawa na ng mga desisyon tungkol sa kung aling mga eroplano ang maaaring lumipad o lumapag, at, sa turn, magpadala ng mga mensahe sa mga eroplano.
Mahalaga! Ang mga module ay maaaring magpadala sa isa't isa hindi lamang ng mga simpleng mensahe, kundi pati na rin ng mga command object. Ang ganitong pakikipag-ugnayan ay inilalarawan ng Command template . Ang ilalim na linya ay upang i-encapsulate ang isang kahilingan upang magsagawa ng isang partikular na aksyon bilang isang hiwalay na bagay.
Sa katunayan, ang object na ito ay naglalaman ng isang solong execute() method , na nagbibigay-daan sa iyo na ipasa ang aksyon na ito sa iba pang mga module para sa execution bilang isang parameter at sa pangkalahatan ay magsagawa ng anumang mga operasyon gamit ang command object na maaaring isagawa sa mga ordinaryong bagay.
Batas ng Demeter
Ipinagbabawal ng Batas ng Demeter ang paggamit ng mga implicit na dependency: "Hindi dapat direktang ma-access ng object A ang object C kung may access ang object A sa object B at may access ang object B sa object C."
Nangangahulugan ito na ang lahat ng mga dependency sa code ay dapat na "hayagan" - ang mga klase / module ay maaari lamang gumamit ng "kanilang mga dependency" sa kanilang trabaho at hindi dapat umakyat sa kanila sa iba. Ang isang magandang halimbawa ay isang three-tier architecture. Ang interface layer ay dapat gumana sa logic layer, ngunit hindi dapat direktang makipag-ugnayan sa database layer.
Sa madaling sabi, ang prinsipyong ito ay binabalangkas din sa ganitong paraan: "Makipag-ugnayan lamang sa mga kagyat na kaibigan, at hindi sa mga kaibigan ng mga kaibigan." Nakakamit nito ang mas kaunting pagkakaugnay ng code, pati na rin ang higit na kakayahang makita at transparency ng disenyo nito.
Ang Batas ng Demeter ay nagpapatupad ng nabanggit na "prinsipyo ng pinakamababang kaalaman", na siyang batayan ng maluwag na pagkabit at binubuo sa katotohanan na ang isang bagay / module ay dapat malaman ang ilang mga detalye hangga't maaari tungkol sa istraktura at mga katangian ng iba pang mga bagay / module at anumang bagay sa pangkalahatan, kabilang ang sarili nitong mga bahagi .
Isang pagkakatulad mula sa buhay: kung gusto mong tumakbo ang aso, hangal na utusan ang mga paa nito, mas mahusay na ibigay ang utos sa aso, at haharapin niya ang kanyang mga paa mismo.
Komposisyon sa halip na mana
Ito ay isang napakalaking at kawili-wiling paksa at ito ay nararapat kahit isang hiwalay na panayam. Maraming mga kopya ang nasira sa paksang ito sa Internet hanggang sa maabot ang isang pinagkasunduan - gumagamit kami ng mana sa pinakamababa, komposisyon - hanggang sa maximum.
Ang punto ay ang pamana ay talagang nagbibigay ng pinakamatibay na koneksyon sa pagitan ng mga klase, kaya dapat itong iwasan. Ang paksang ito ay mahusay na sakop sa artikulo ng Herb Sutter na " Mas gusto ang Komposisyon kaysa Mana ".
Kapag nagsimula kang mag-aral ng mga pattern ng disenyo, makakatagpo ka ng isang buong grupo ng mga pattern na namamahala sa paglikha ng isang bagay o panloob na istraktura nito. Sa pamamagitan ng paraan, maaari kong payuhan sa kontekstong ito na bigyang-pansin ang pattern ng Delegate / Delegate at ang pattern ng Component , na nagmula sa mga laro .
Pag-uusapan natin ang higit pa tungkol sa mga pattern sa ibang pagkakataon.