Mga generative pattern

3.1 Singleton

Ang Singleton ay isang generic na pattern ng disenyo na ginagarantiyahan na ang isang single-threaded na application ay magkakaroon ng iisang instance ng ilang klase, at nagbibigay ng pandaigdigang access point sa pagkakataong ito.

Kadalasan, ang mga baguhang programmer ay gustong mag-assemble ng mga pamamaraan ng utility sa ilang static na klase - isang klase na naglalaman lamang ng mga static na pamamaraan. Ang diskarte na ito ay may isang bilang ng mga disadvantages - halimbawa, hindi ka maaaring magpasa ng isang sanggunian sa isang bagay ng naturang klase, ang mga naturang pamamaraan ay mahirap subukan, at iba pa.

Bilang kahalili, iminungkahi ang isang solong solusyon sa klase: isang klase na maaaring magkaroon lamang ng isang bagay. Kapag sinusubukang likhain ang bagay na ito, gagawin lamang ito kung hindi pa ito umiiral, kung hindi, ibabalik ang isang reference sa isang umiiral nang instance.

Mahalaga na posible na gumamit ng isang instance ng klase, dahil sa maraming kaso ay nagiging available ang mas malawak na functionality. Halimbawa, ang klase na ito ay maaaring magpatupad ng ilang mga interface at ang object nito ay maaaring maipasa sa iba pang mga pamamaraan bilang isang pagpapatupad ng interface. Ano ang hindi maaaring gawin sa isang hanay ng mga static na pamamaraan.

Mga kalamangan:

• Ang mga pamamaraan ay nakatali sa isang bagay, hindi isang static na klase - maaari mong ipasa ang isang bagay sa pamamagitan ng sanggunian.
• Ang mga pamamaraan ng bagay ay mas madaling subukan at kutyain.
• Ang isang bagay ay nilikha lamang kapag kinakailangan: lazy object initialization.
• Pagpapabilis ng paunang paglulunsad ng programa kung maraming single na hindi kailangan para sa paglulunsad.
• Ang nag-iisa ay maaaring higit pang gawing isang template-diskarte o ilang mga naturang bagay.

Minuse:

• Nagiging mas mahirap na kontrolin ang mga inter-thread na karera at pagkaantala.
• Mahirap magsulat ng isang multi-threaded na "loner" "mula sa ulo": ang pag-access sa isang matagal nang singleton, sa isip, ay hindi dapat magbukas ng isang mutex. Mas mahusay na napatunayang solusyon.
• Ang salungatan sa pagitan ng dalawang thread sa isang hindi natapos na solong thread ay magreresulta sa pagkaantala.
• Kung ang bagay ay ginagawa sa loob ng mahabang panahon, ang pagkaantala ay maaaring makagambala sa gumagamit o makagambala sa real time. Sa kasong ito, mas mahusay na ilipat ang paglikha nito sa yugto ng pagsisimula ng programa.
• Kinakailangan ang mga espesyal na feature para sa unit testing - halimbawa, para ilagay ang library sa "non-lonely" mode at ganap na ihiwalay ang mga pagsubok sa isa't isa.
• Ang isang espesyal na taktika para sa pagsubok sa natapos na programa ay kinakailangan, dahil kahit na ang konsepto ng "pinakasimpleng launchability" ay nawawala, dahil ang launchability ay nakasalalay sa pagsasaayos.

3.2 Pabrika [Paraan]

Ang factory method ay isang generic na pattern ng disenyo na nagbibigay ng mga subclass (classes-inheritors) na may interface para sa paglikha ng mga instance ng isang partikular na klase. Sa oras ng paglikha, matutukoy ng mga inapo kung aling klase ang gagawin.

Sa madaling salita, itinatalaga ng template na ito ang paglikha ng mga bagay sa mga inapo ng parent class. Pinapayagan ka nitong gumamit ng hindi mga kongkretong klase sa code ng programa, ngunit upang manipulahin ang mga abstract na bagay sa isang mas mataas na antas.

Ang pattern na ito ay tumutukoy sa isang interface para sa paglikha ng isang bagay, ngunit ipinauubaya ito sa mga subclass upang magpasya kung aling klase ang pagbabasehan ng object. Ang isang factory method ay nagpapahintulot sa isang klase na italaga ang paglikha ng mga subclass. Ginagamit kapag:

• hindi alam ng klase nang maaga kung aling mga bagay kung aling mga subclass ang kailangan nitong gawin.
• ang isang klase ay idinisenyo upang ang mga bagay na nilikha nito ay tinukoy ng mga subclass.
• itinatalaga ng klase ang mga responsibilidad nito sa isa sa ilang mga subclass ng helper, at pinlano itong tukuyin kung aling klase ang kukuha sa mga responsibilidad na ito.

3.3 Abstract na Pabrika

Ang abstract factory ay isang generic na pattern ng disenyo na nagbibigay ng interface para sa paglikha ng mga pamilya ng magkakaugnay o magkakaugnay na mga bagay nang hindi tinukoy ang kanilang mga kongkretong klase.

Ang pattern ay ipinatupad sa pamamagitan ng paglikha ng abstract class Factory, na isang interface para sa paglikha ng mga bahagi ng system (halimbawa, para sa isang window interface, maaari itong lumikha ng mga bintana at mga pindutan). Pagkatapos ay isinulat ang mga klase na nagpapatupad ng interface na ito.

Ginagamit ito sa mga kaso kung saan ang programa ay dapat na independyente sa proseso at mga uri ng mga bagong bagay na nilikha. Kapag kinakailangan na lumikha ng mga pamilya o grupo ng mga kaugnay na bagay, hindi kasama ang posibilidad ng sabay-sabay na paggamit ng mga bagay mula sa iba't ibang hanay ng mga ito sa parehong konteksto.

Mga kalakasan:

• ihiwalay ang mga partikular na klase;
• pinapasimple ang pagpapalit ng mga pamilya ng produkto;
• ginagarantiyahan ang pagiging tugma ng produkto.

Sabihin nating gumagana ang iyong program sa file system. Pagkatapos upang gumana sa Linux kailangan mo ng LinuxFile, LinuxDirectory, LinuxFileSystem objects. At para magtrabaho sa Windwos, kailangan mo ang mga klase ng WindowsFile, WindowsDirectory, WindowsFileSystem.

Ang klase ng Path, na nilikha sa pamamagitan ng Path.of(), ay isang ganoong kaso. Ang Path ay hindi talaga isang klase, ngunit isang interface, at mayroon itong mga pagpapatupad ng WindowsPath at LinuxPath. At kung anong uri ng bagay ang gagawin ay nakatago sa iyong code at pagpapasya sa runtime.

3.4 Prototype

Ang prototype ay isang generative na pattern ng disenyo.

Tinutukoy ng pattern na ito ang mga uri ng mga bagay na nilikha gamit ang isang halimbawa ng prototype at lumilikha ng mga bagong bagay sa pamamagitan ng pagkopya sa prototype na ito. Pinapayagan ka nitong lumayo mula sa pagpapatupad at sundin ang prinsipyo ng "pagprograma sa pamamagitan ng mga interface".

Ang isang interface/abstract na klase sa tuktok ng hierarchy ay tinukoy bilang ang bumabalik na uri, at ang mga descendant na klase ay maaaring palitan ang isang tagapagmana na nagpapatupad ng ganitong uri doon. Sa madaling salita, ito ang pattern ng paglikha ng isang bagay sa pamamagitan ng pag-clone ng isa pang bagay sa halip na likhain ito sa pamamagitan ng isang constructor.

Ang pattern ay ginagamit upang:

• pag-iwas sa karagdagang pagsisikap ng paglikha ng isang bagay sa isang karaniwang paraan (ibig sabihin ay ang paggamit ng isang constructor, dahil sa kasong ito ang mga constructor ng buong hierarchy ng ninuno ng object ay tatawagin din), kapag ito ay ipinagbabawal na mahal para sa aplikasyon.
• iwasang mamana ang object creator sa client application, gaya ng ginagawa ng abstract factory pattern.

Gamitin ang pattern ng disenyo na ito kapag walang pakialam ang iyong program kung paano ito lumilikha, bumubuo, at naglalahad ng mga produkto:

• ang mga instant na klase ay tinutukoy sa oras ng pagtakbo, halimbawa, gamit ang dynamic na paglo-load;
• gusto mong iwasan ang pagbuo ng mga hierarchy ng klase o factory na kahanay ng hierarchy ng klase ng produkto;
• ang mga instance ng klase ay maaaring nasa isa sa ilang magkakaibang estado. Maaaring mas maginhawang itakda ang naaangkop na bilang ng mga prototype at i-clone ang mga ito, sa halip na manu-manong i-instantiate ang klase sa naaangkop na estado sa bawat oras.