2.1 Estado
Ang estado ay isang pattern ng disenyo ng pag-uugali. Ginagamit ito sa mga kasong iyon kapag, sa panahon ng pagpapatupad ng programa, dapat baguhin ng object ang pag-uugali nito depende sa estado nito.
Ang pattern ay binubuo ng 3 mga bloke:
Ang konteksto ay isang klase na ang mga bagay ay dapat magbago ng kanilang pag-uugali depende sa estado.
Ang estado ay ang interface na dapat ipatupad ng bawat kongkretong estado. Sa pamamagitan ng interface na ito, nakikipag-ugnayan ang object ng Konteksto sa estado sa pamamagitan ng pagtatalaga ng mga tawag dito. Ang interface ay dapat maglaman ng mga paraan para sa feedback sa bagay na ang pag-uugali ay dapat baguhin.
Para dito, ginagamit ang isang kaganapan (pattern Publisher - Subscriber). Ito ay kinakailangan upang mapalitan ang object ng estado sa panahon ng pagpapatupad ng programa kapag nangyari ang mga kaganapan. Maaaring may mga kaso kung saan ang mismong Konteksto ay pana-panahong nag-poll sa object ng estado para sa isang transition.
ConcreteState1, ConcreteState2 - mga klase ng kongkretong estado. Dapat maglaman ng impormasyon sa ilalim ng kung anong mga kundisyon at sa anong mga estado ang bagay ay maaaring pumasa mula sa kasalukuyang estado. Halimbawa, mula sa ConcreteState1, ang isang bagay ay maaaring pumunta sa ConcreteState2 at ConcreteState3, at mula sa ConcreteState2 pabalik sa ConcreteState1, at iba pa. Ang bagay ng isa sa mga ito ay dapat maglaman ng Konteksto kapag ginawa.
Halimbawa, nagsusulat ka ng isang laro kung saan ang isang karakter ay maaaring tumakbo, lumangoy at lumipad. Kung ang iyong karakter ay nahuhulog sa tubig, kung gayon makatuwirang limitahan ang kanyang pag-uugali sa tubig: ngayon ay hindi siya maaaring mag-shoot, ngunit mayroon pa rin siyang ilang mga aksyon: lumangoy pasulong, kanan, kaliwa, atbp.
Ang estado ng iyong karakter ay maaaring ilarawan sa pamamagitan ng isang bagay ng Estado, na may mga pamamaraan na matatawag at may gagawin. At pagkatapos na pumasok ang iyong karakter sa tubig, babaguhin mo lang ang sanggunian sa isa pang bagay ng Estado sa loob nito - at binabago nito ang estado nito.
2.2 diskarte
Ang diskarte ay isang pattern ng disenyo ng pag-uugali para sa pagtukoy ng isang pamilya ng mga algorithm, pag-encapsulate sa bawat isa, at paggawa ng mga ito na maaaring palitan. Pinapayagan ka nitong pumili ng isang algorithm sa pamamagitan ng pagtukoy sa naaangkop na klase.
Binibigyang-daan ka ng pattern ng Strategy na baguhin ang napiling algorithm anuman ang mga bagay ng kliyente na gumagamit nito.
Binibigyang-daan ka ng pattern ng Strategy na gumamit ng iba't ibang panuntunan o algorithm ng negosyo depende sa konteksto. Ito ay ginagamit sa mga kaso kung saan ang iba't ibang mga algorithm ay dapat gamitin sa parehong lugar depende sa kasalukuyang estado ng system (o sa kapaligiran nito).
Mga kalakasan:
- encapsulation ng pagpapatupad ng iba't ibang mga algorithm, ang sistema ay nagiging independiyente ng mga posibleng pagbabago sa mga patakaran ng negosyo;
- pagtawag sa lahat ng mga algorithm sa isang karaniwang paraan;
- hindi gumagamit ng mga switch at/o conditional statement.
Ang pattern na ito ay medyo katulad sa pattern ng Estado, ngunit dito ang diin ay hindi sa estado, ngunit sa pag-uugali. Sabihin nating ang isang karakter sa iyong laro ay maaaring magpalit ng mga armas. Pagkatapos kapag nagpapalit ng mga armas, maaari mo lamang baguhin ang reference sa bagay na naglalarawan kung paano gumagana ang sandata na ito.
2.3 Paraan ng Template
Abstract class (abstract class) - tumutukoy sa abstract operations na pinapalitan sa mga tagapagmana upang ipatupad ang mga hakbang ng algorithm; nagpapatupad ng paraan ng template na tumutukoy sa balangkas ng algorithm. Tinatawag ng pamamaraan ng template ang pinalitan at iba pang mga operasyon na tinukoy sa klase ng Abstract.
Concrete class (concrete class) - ipinapatupad ang mga pinalit na operasyon sa paraang kinakailangan para sa pagpapatupad. Ipinapalagay ng Concrete class na ang mga invariant na hakbang ng algorithm ay isasagawa sa AbstractClass.
Ang pattern na ito ay madalas na ginagamit kapag kinakailangan:
- Isang paggamit ng invariant na bahagi ng algorithm, na iniiwan ang nagbabagong bahagi sa pagpapasya ng mga tagapagmana.
- Lokalisasyon at paghihiwalay ng code na karaniwan sa ilang mga klase upang maiwasan ang pagdoble.
- Pahintulutan ang mga tagapagmana na mag-extend ng code sa ilang partikular na lugar lang.
Oo, inilalarawan ng pattern na ito ang paggamit ng isang pares: isang abstract na klase at ang pagpapatupad nito.
2.4 Kadena ng Pananagutan
Ang chain of responsibility ay isang pattern ng disenyo ng pag-uugali na idinisenyo upang ayusin ang mga antas ng responsibilidad sa isang sistema.
Ang template ay inirerekomenda para sa paggamit sa mga kondisyon kung saan:
- sa binuo na sistema mayroong isang pangkat ng mga bagay na maaaring magproseso ng mga mensahe ng isang tiyak na uri;
- ang lahat ng mga mensahe ay dapat iproseso ng hindi bababa sa isang object ng system;
- Ang mga mensahe sa system ay pinoproseso ayon sa scheme na "iproseso ito sa iyong sarili o ipasa ito sa iba", iyon ay, ang ilang mga mensahe ay naproseso sa antas kung saan sila natanggap, habang ang iba ay ipinapasa sa mga bagay ng ibang antas.
2.5 Alaala
Ang Keeper (Memento) ay isang pattern ng disenyo ng pag-uugali na nagbibigay-daan sa iyong ayusin at i-save ang panloob na estado ng isang bagay nang hindi lumalabag sa encapsulation upang maibalik ito sa ganitong estado sa ibang pagkakataon.
Ginagamit ang pattern ng Guardian kapag:
- ito ay kinakailangan upang i-save ang isang snapshot ng estado ng bagay (o bahagi nito) para sa kasunod na pagpapanumbalik;
- Ang direktang interface para sa pagkuha ng estado ng isang bagay ay naglalantad ng mga detalye ng pagpapatupad at sinisira ang object encapsulation.