Paano paluwagin ang pagkakabit sa pagitan ng mga module ng software

8.1 Ang pagkabulok ay lahat

Para sa kalinawan, isang larawan mula sa isang magandang artikulong "Decoupling of Object-Oriented Systems", na naglalarawan ng mga pangunahing punto na tatalakayin.

Sa palagay mo ba ay madali ang pagdidisenyo ng isang arkitektura ng aplikasyon?

8.2 Mga interface, pagtatago ng pagpapatupad

Ang mga pangunahing prinsipyo para sa pagbabawas ng pagkabit ng system ay ang mga prinsipyo ng OOP at ang prinsipyo ng Encapsulation + Abstraction + Polymorphism sa likod ng mga ito.

Kaya naman:

• Ang mga module ay dapat na "mga itim na kahon" para sa bawat isa (encapsulation) . Nangangahulugan ito na ang isang module ay hindi dapat "umakyat" sa isa pang module at alam ang anumang bagay tungkol sa panloob na istraktura nito. Ang mga bagay sa isang subsystem ay hindi dapat direktang ma-access ang mga bagay sa isa pang subsystem.
• Ang mga module/subsystem ay dapat makipag-ugnayan sa isa't isa lamang sa pamamagitan ng mga interface (iyon ay, mga abstraction na hindi nakadepende sa mga detalye ng pagpapatupad). Alinsunod dito, ang bawat module ay dapat magkaroon ng isang mahusay na tinukoy na interface o mga interface para sa pakikipag-ugnayan sa iba pang mga module.

Ang prinsipyo ng "itim na kahon" (encapsulation) ay nagpapahintulot sa amin na isaalang-alang ang istraktura ng bawat subsystem nang independiyenteng ng iba pang mga subsystem. Ang module, na isang "itim na kahon", ay maaaring malayang mapalitan. Ang mga problema ay maaaring lumitaw lamang sa junction ng iba't ibang mga module (o isang module at isang kapaligiran).

At ang pakikipag-ugnayan na ito ay dapat na inilarawan sa pinaka-pangkalahatang (abstract) na anyo, iyon ay, sa anyo ng isang interface. Sa kasong ito, gagana ang code sa anumang pagpapatupad na umaayon sa kontrata ng interface. Ito ang kakayahang magtrabaho sa iba't ibang mga pagpapatupad (mga module o mga bagay) sa pamamagitan ng isang pinag-isang interface na tinatawag na polymorphism.

Iyon ang dahilan kung bakit ang Servlet ay isang interface : ang lalagyan ng web ay walang alam tungkol sa mga servlet, dahil ito ang ilang mga bagay na nagpapatupad ng interface ng Servlet at iyon lang. Alam din ng mga Servlet ang kaunti tungkol sa istraktura ng lalagyan. Ang interface ng Servlet ay ang kontratang iyon, ang pamantayang iyon, ang pinakamababang pakikipag-ugnayan na kailangan para masakop ng mga Java web application ang mundo.

Ang polymorphism ay hindi lahat ng overriding ng mga pamamaraan, tulad ng kung minsan ay maling pinaniniwalaan, ngunit una sa lahat, ang pagpapalitan ng mga module / bagay na may parehong interface o "isang interface, maraming mga pagpapatupad". Upang ipatupad ang polymorphism, ang mekanismo ng pamana ay hindi kinakailangan. Mahalagang maunawaan ito dahil ang pamana sa pangkalahatan ay dapat na iwasan hangga't maaari .

Salamat sa mga interface at polymorphism, ito ay tiyak ang kakayahang baguhin at pahabain ang code nang hindi binabago kung ano ang nakasulat na (Open-Closed Principle) ay nakakamit.

Hangga't ang pakikipag-ugnayan ng mga module ay eksklusibong inilarawan sa anyo ng mga interface at hindi nakatali sa mga partikular na pagpapatupad, mayroon kang pagkakataon na ganap na "walang sakit" para sa system na palitan ang isang module ng anumang iba pang nagpapatupad ng parehong interface, pati na rin magdagdag ng bago at sa gayon ay mapalawak ang pag-andar.

Ito ay tulad ng sa LEGO constructor - ang interface ay nag-standardize ng pakikipag-ugnayan at nagsisilbing isang uri ng connector kung saan anumang module na may angkop na connector ay maaaring konektado.

Ang kakayahang umangkop ng taga-disenyo ay sinisiguro sa pamamagitan ng katotohanan na maaari lamang nating palitan ang isang module o bahagi sa isa pa na may parehong mga konektor (na may parehong interface), pati na rin magdagdag ng maraming mga bagong bahagi na gusto namin (sa parehong oras, umiiral na. ang mga bahagi ay hindi binago o binago sa anumang paraan).

Binibigyang-daan ka ng mga interface na bumuo ng isang mas simpleng sistema, isinasaalang-alang ang bawat subsystem sa kabuuan at binabalewala ang panloob na istraktura nito. Pinapayagan nila ang mga module na makipag-ugnayan at sa parehong oras ay walang alam tungkol sa panloob na istraktura ng bawat isa, sa gayon ganap na pagpapatupad ng prinsipyo ng minimal na kaalaman, na siyang batayan ng maluwag na pagkabit.

Kung mas pangkalahatan/abstract ang mga interface ay tinukoy at mas kaunting mga paghihigpit na ipinapataw nila sa pakikipag-ugnayan, mas nababaluktot ang system. Mula dito, isa pa sa mga prinsipyo ng SOLID ang aktwal na sumusunod - ang Interface Segregation Principle , na sumasalungat sa "mga makapal na interface".

Sinabi niya na ang malalaki at malalaking interface ay dapat na hatiin sa mas maliit, mas tiyak, para ang mga kliyente ng maliliit na interface (depende sa mga module) ay alam lamang ang tungkol sa mga pamamaraan na kailangan nilang gamitin.

Ang prinsipyong ito ay binuo bilang mga sumusunod: "Ang mga kliyente ay hindi dapat umasa sa mga pamamaraan (magkaroon ng kamalayan sa mga pamamaraan) na hindi nila ginagamit" o "Maraming mga dalubhasang interface ay mas mahusay kaysa sa isang unibersal na isa".

Lumalabas na ang mahinang koneksyon ay ibinibigay lamang kapag ang pakikipag-ugnayan at mga dependency ng mga module ay inilarawan lamang sa tulong ng mga interface, iyon ay, mga abstraction, nang hindi gumagamit ng kaalaman tungkol sa kanilang panloob na istraktura at istraktura. At sa katunayan, ipinatupad ang encapsulation. Dagdag pa, mayroon kaming kakayahang palawakin / baguhin ang pag-uugali ng system sa pamamagitan ng pagdaragdag at paggamit ng iba't ibang mga pagpapatupad, iyon ay, dahil sa polymorphism. Oo, muli kaming dumating sa OOP - Encapsulation, Abstraction, Polymorphism.

8.3 Facade: interface ng module

Narito ang isang bihasang programmer ay magtatanong: kung ang disenyo ay wala sa antas ng mga bagay na sila mismo ang nagpapatupad ng kaukulang mga interface, ngunit sa antas ng mga module, kung gayon ano ang pagpapatupad ng interface ng module?

Sagot: nagsasalita sa wika ng mga pattern ng disenyo, kung gayon ang isang espesyal na bagay ay maaaring maging responsable para sa pagpapatupad ng interface ng module - Facade . Kung tumatawag ka ng mga pamamaraan sa isang bagay na naglalaman ng Gateway suffix (halimbawa, MobileApiGateway), malamang na ito ay isang harapan.

Ang facade ay isang interface object na nag-iipon ng mataas na antas na hanay ng mga operasyon para sa pagtatrabaho sa isang partikular na subsystem, na itinatago ang panloob na istraktura at tunay na pagiging kumplikado sa likod nito . Nagbibigay ng proteksyon laban sa mga pagbabago sa pagpapatupad ng subsystem. Nagsisilbing iisang entry point - "sipain mo ang harapan, at alam niya kung sino ang kailangang sipain sa subsystem na ito para makuha ang kailangan niya."

Ipinakilala ka pa lang sa isa sa pinakamahalagang pattern ng disenyo na nagbibigay-daan sa iyong gamitin ang konsepto ng mga interface kapag nagdidisenyo ng mga module at sa gayon ay i-decouple ang mga ito - "Facade".

Bilang karagdagan, ginagawang posible ng "Facade" na magtrabaho sa mga module sa parehong paraan tulad ng sa mga ordinaryong bagay at ilapat ang lahat ng mga kapaki-pakinabang na prinsipyo at diskarte na ginagamit sa disenyo ng mga klase kapag nagdidisenyo ng mga module.

Tandaan : Bagama't naiintindihan ng karamihan sa mga programmer ang kahalagahan ng mga interface kapag nagdidisenyo ng mga klase (mga bagay), tila marami ang nakatuklas ng ideya ng paggamit ng mga interface sa antas ng module din.