Mga pattern ng istruktura

2.1 Adapter

Ang Adapter (Adapter) ay isang pattern ng disenyo ng istruktura na idinisenyo upang ayusin ang paggamit ng mga function ng isang bagay na hindi magagamit para sa pagbabago sa pamamagitan ng isang espesyal na nilikha na interface.

Ang opisyal na kahulugan ay medyo nakakalito, ngunit kung ilalagay mo ito sa iyong sariling mga salita, ang isang adaptor ay isang pattern ng disenyo na nagbibigay-daan sa mga bagay na may mga hindi tugmang interface na gumana nang magkasama .

Ginagamit upang ayusin ang paggamit ng mga function ng isang bagay na hindi magagamit para sa pagbabago sa pamamagitan ng isang espesyal na nilikha na interface. Ang isang karagdagang klase ay nilikha na may kinakailangang interface, at ang klase na ito naman ay tumatawag sa mga pamamaraan ng nais na bagay (na walang kinakailangang interface).

Mahalaga! Kung sa code ay natutugunan mo ang suffix Adapter para sa isang klase, mayroon kang lahat ng karapatan na isaalang-alang na ang klase na ito ay gumaganap bilang isang adaptor at nauugnay sa isang pangkat ng mga klase na gumagana ayon sa scheme na inilarawan sa itaas.

Ginagamit ito sa mga kaso kung saan sinusuportahan ng system ang kinakailangang data at gawi, ngunit may hindi naaangkop na interface. Ang pinakakaraniwang paggamit ng Adapter pattern ay kapag gusto mong lumikha ng klase na nagmana mula sa bago o umiiral nang abstract na klase.

Mga kalakasan:

• Ang paglipat sa paggamit ng iba pang mga panlabas na klase ay hindi nangangailangan ng muling paggawa ng system mismo, ito ay sapat na upang ipatupad ang isa pang klase ng Adapter.
• Kalayaan mula sa pagpapatupad ng mga panlabas na klase (mga klase mula sa mga aklatan na ang code ay hindi natin mababago). Nagiging independyente ang iyong programa sa interface ng mga panlabas na klase.

2.2 Mga Dekorador

Ang dekorador ay isang structural design pattern para sa dynamic na pag-attach ng karagdagang pag-uugali sa isang bagay. Ang pattern ng Dekorador ay nagbibigay ng isang mahusay at nababaluktot na alternatibo sa pagsasanay ng subclassing upang mapalawak ang functionality.

Ginagamit upang dynamic na ikonekta ang mga karagdagang obligasyon sa isang bagay.

Marami sa inyo ang magtatanong: paano ka magdadagdag (habang tumatakbo ang programa) ng bagong pag-uugali sa isang bagay? Ang isang bagay ay maaaring tipunin mula sa mga piraso, iyon ay, maliliit na bagay. Tandaan ang mga chain ng filter sa mga servlet? O ang Stream API kapag nagsulat ka ng query gamit ang filter(), map(), list()?

IntStream.of(50, 60, 70, 80, 90).filter(x -> x < 90).map(x -> x + 10).limit(3).forEach(System.out::print);

Mga lakas ng pattern ng Dekorador:

• Hindi na kailangang lumikha ng mga subclass upang mapalawak ang pag-andar ng isang bagay.
• Ang kakayahang dynamic na ikonekta ang bagong functionality kahit saan: bago o pagkatapos ng pangunahing functionality ng ConcreteComponent object.

2.3 Mga proxy

Ang proxy ay isang structural design pattern na nagbibigay ng object na kumokontrol ng access sa isa pang object, humaharang at pumasa sa lahat ng tawag nito.

Ang Proxy pattern ay nagbibigay ng isang kapalit na bagay sa halip ng tunay na bagay. Kinokontrol ng object na ito ang pag-access sa orihinal na object. Madalas na ginagamit.

Tandaan kung paano namin ginamit ang Mockito framework at naharang ang isang tawag sa isang tunay na bagay gamit ang Mockito.spy() na paraan o ang @Spy annotation? Noon ay nilikha ang isang espesyal na bagay na Proxy, kung saan dumaan ang lahat ng mga tawag sa orihinal na bagay.

At pagkatapos ay maaari naming pamahalaan ang mga tawag na ito sa pamamagitan ng pagdaragdag ng mga panuntunan sa bagay. Tama iyon - ang orihinal na bagay ay hindi nagbabago, at ang pagtatrabaho dito ay nagiging mas nababaluktot. Ito ay lalong kapaki-pakinabang kapag hindi namin tinawag ang proxy object mula sa aming code, ngunit ipinapasa ito sa isang lugar. Kaya kinokontrol ang komunikasyon ng dalawang bagay na independyente sa atin.

Mga uri ng proxy ayon sa layunin:

• Pag-log proxy : nila-log ang lahat ng tawag sa “Subject” kasama ng kanilang mga parameter.
• Remote proxy (remote proxy): nagbibigay ng komunikasyon sa "Subject", na nasa ibang address space o sa isang remote na makina. Maaari rin itong maging responsable para sa pag-encode ng kahilingan at mga argumento nito at pagpapadala ng naka-encode na kahilingan sa tunay na "Paksa".
• Virtual proxy (virtual proxy): tinitiyak na ang tunay na "Subject" ay nilikha lamang kapag ito ay talagang kinakailangan. Maaari din nitong i-cache ang ilan sa impormasyon tungkol sa totoong "Paksa" upang maantala ang paglikha nito.
• Copy-on-write : Nagbibigay ng kopya ng "paksa" kapag nagsagawa ang kliyente ng ilang partikular na pagkilos (isang espesyal na kaso ng "virtual proxy").
• Proxies ng proteksyon : Maaaring suriin kung ang tumatawag ay may mga kinakailangang pahintulot upang gawin ang kahilingan.
• Caching Proxy : Nagbibigay ng pansamantalang imbakan ng mga resulta ng pagkalkula bago ihatid ang mga ito sa maraming kliyente na maaaring magbahagi ng mga resulta.
• Screening Proxy: Pinoprotektahan ang "Subject" mula sa mga mapanganib na kliyente (o vice versa).
• Synchronization Proxy : nagsasagawa ng naka-synchronize na access control sa "Subject" sa isang asynchronous na multi-threaded na kapaligiran.
• "Smart" na link (smart reference proxy): nagsasagawa ng mga karagdagang pagkilos kapag ang isang link sa "Subject" ay ginawa, halimbawa, kinakalkula ang bilang ng mga aktibong link sa "Subject".

2.4 Tulay

Ang Bridge pattern ay isang structural design pattern na ginagamit para "paghiwalayin ang abstraction at implementasyon para sila ay makapag-iba ng pagbabago."

Ang bridge pattern ay gumagamit ng encapsulation, aggregation, at maaaring gumamit ng inheritance para magbahagi ng responsibilidad sa pagitan ng mga klase.

Kapag pinaghiwalay ang abstraction at pagpapatupad, maaari silang magbago nang nakapag-iisa. Sa madaling salita, kapag ipinatupad sa pamamagitan ng pattern ng tulay, ang pagbabago ng istraktura ng interface ay hindi makagambala sa pagbabago ng istraktura ng pagpapatupad.

Isaalang-alang ang gayong abstraction bilang isang figure. Mayroong maraming mga uri ng mga hugis, bawat isa ay may sariling mga katangian at pamamaraan. Gayunpaman, mayroong isang bagay na nagkakaisa sa lahat ng mga numero. Halimbawa, ang bawat hugis ay dapat na kayang iguhit ang sarili, sukat, at iba pa.

Kasabay nito, ang pagguhit ng mga graphics ay maaaring mag-iba depende sa uri ng OS o graphics library. Ang mga hugis ay dapat na iguhit ang kanilang mga sarili sa iba't ibang mga kapaligiran ng graphics. Ngunit hindi praktikal na ipatupad ang lahat ng paraan ng pagguhit sa bawat hugis, o baguhin ang hugis sa tuwing nagbabago ang paraan ng pagguhit.

Sa kasong ito, nakakatulong ang pattern ng tulay, na nagpapahintulot sa iyo na lumikha ng mga bagong klase na magpapatupad ng pagguhit sa iba't ibang mga graphical na kapaligiran. Gamit ang diskarteng ito, napakadaling magdagdag ng parehong mga bagong hugis at mga paraan upang iguhit ang mga ito.

Ang koneksyon na kinakatawan ng arrow sa mga diagram ay maaaring magkaroon ng 2 kahulugan: a) "isang uri", alinsunod sa prinsipyo ng pagpapalit ng Liskov, at b) isa sa mga posibleng pagpapatupad ng abstraction. Ang mga wika ay karaniwang gumagamit ng mana upang ipatupad ang parehong a) at b), na may posibilidad na lumaki ang mga hierarchy ng klase.

Ang tulay ay nagsisilbi nang eksakto upang malutas ang problemang ito: ang mga bagay ay nilikha sa mga pares mula sa isang bagay ng isang klase ng hierarchy A at hierarchy B, ang mana sa loob ng hierarchy A ay may kahulugan ng "iba't-ibang" ayon kay Liskov, at para sa konsepto ng "pagpapatupad. of abstraction” ginagamit ang isang link mula sa object A hanggang sa ipinares nitong object B.

2.5 Harapan

Ang Facade pattern ay isang structural design pattern na nagtatago sa pagiging kumplikado ng isang system sa pamamagitan ng pagbabawas ng lahat ng posibleng external na tawag sa isang object na nagdedelegate sa kanila sa mga naaangkop na object sa system.

Paano magbigay ng pinag-isang interface na may hanay ng magkakaibang mga pagpapatupad o mga interface, halimbawa, sa isang subsystem, kung hindi kanais-nais ang malakas na pagkabit sa subsystem na iyon, o maaaring magbago ang pagpapatupad ng subsystem?

Tukuyin ang isang punto ng pakikipag-ugnayan sa subsystem - isang facade object na nagbibigay ng karaniwang interface sa subsystem, at italaga dito ang responsibilidad para sa pakikipag-ugnayan sa mga bahagi nito. Ang facade ay isang panlabas na bagay na nagbibigay ng isang entry point para sa mga serbisyo ng subsystem.

Ang pagpapatupad ng iba pang mga bahagi ng subsystem ay pribado at hindi nakikita ng mga panlabas na bahagi. Ang facade object ay nagbibigay ng pagpapatupad ng pattern ng GRASP na Lumalaban sa mga pagbabago sa mga tuntunin ng proteksyon laban sa mga pagbabago sa pagpapatupad ng subsystem.

Mahalaga! Ang pattern na ito ay ginagamit kapag gusto naming ganap na itago ang ilang grupo ng mga bagay at ipasa ang lahat ng komunikasyon sa kanila sa pamamagitan ng aming bagay. Kung gusto mo lang magbigay ng kontrol sa proseso ng komunikasyon ng mga bagay at hindi kinakailangang itago ang mga ito, mas mainam na gamitin ang Proxy pattern.