Tarkvara arhitektuur ja disain Loeng 8 Ants Torim

Eelmise loengu sisu Polümorfism - klassiti varieeruva käitumise eest vastutavad klassid ise. Puhas väljamõeldis - vahel on kasulik tekitada disaini klass, mis probleemvaldkonnas vastet ei oma. Kaudsus - välissüsteemi äriloogikast lahutamiseks on kasulik kasutada klasse, mis peidavad konkreetse välissüsteemi üldise liidese taha. Kaitstud variatsioonid - fundamentaalne printsiip, eriti polümorfismi ja kaudsuse taga.

Millest selles loengus juttu tuleb? Gang of Four (GoF) disainimustrid: Šabloonmeetod (Template Method) Tehase meetod (Factory Method) Strateegia (Strategy) Olek (State) Adapter (Adapter) Sild (Bridge)

GoF mustrid GoF mustrid kirjeldati disainimustrite vallas teedrajavas raamatus Design Patterns; Gamma, Helms, Johnson, Vlissides; 1995. (Nimetus Gang of Four tuli neljast autorist.) GoF mustrid on konkreetsemad kui GRASP mustrid, kirjeldades lahendust vajalike klasside ja meetodite täpsusega. GoF mustrid tegelevad tavaliselt süsteemi kaitsmisega teatud tüüpi variatsioonide vastu OO viisil. GoF mustrite sõnavara on OO maailmas laialt kasutusel.

Struktuuriga seotud GoF mustrid Tüüpsisu: Objektidest suurte struktuuride koostamine. Adapter (Adapter) Sild (Bridge) Ühend (Composite) Dekoraator (Decorator) Fassaad (Facade) Kärbeskaal (Flyweight) Vahendusobjekt (Proxy)

Käitumisega seotud GoF mustrid Tüüpsisu: algoritmid ja vastutuste jaotus. Käsuliin (Chain of Responsibility) Käsk (Command) Interpretaator (Interpreter) Iteraator (Iterator) Vahendaja (Mediator) Memento (Memento) Vaatleja (Observer) Olek (State) Strateegia (Strategy) Šabloonmeetod (Template Method) Külastaja (Visitor)

Loomisega seotud GoF mustrid Tüüpsisu: Isoleerida teadmine tekitatava objekti tüübist. Kõigi nende mustrite juures on tegemist ühe või rohkema meetodiga, mis tagastab uue objekti. Klienttarkvara peab sellise objekti tekitamiseks kasutama mustri poolt pakutavat mehhanismi (meetodit), mitte objekti otse initsialiseerima. Abstraktne tehas (Abstract Factory) Ehitaja (Builder) Tehase meetod (Factory Method) Prototüüp (Prototype) Singel (Singleton)

Klassidiagrammide legend Värv näitab kuidas teatud muudatus disaini mõjutab.

Šabloonmeetod (Template Method) Probleem: Kuidas eraldada üldine algoritm varieeruvatest alamosadest? Lahendus: Defineeri algoritmi karkass Šabloonmeetodis jättes mõned sammud alamklassidele defineerimiseks. Šabloonmeetod lubab alamklassidel mõningaid algoritmi samme ümber defineerida ilma algoritmi struktuuri muutmata.

Šabloonmeetod Koostöö: KonkreetsedKlassid lasevad AbstraktselKlassil defineerida algoritmi muutumatud osad (šabloonmeetod) defineerides ise varieeruvad osad (primitiivneOp1-2). NB! Variantideks on siin alamklassid A ja B, mitte operatsioonid Op1 ja Op2. Op1 ja Op2 on mõlemad vajalikud sammud üldises algoritmis.

Šabloonmeetod koodis public abstract class AbstraktneKlass { public void shabloonmeetod(){ … primitiivneop1(); primitiivneop2(); } protected abstract void primitiivneop1(); protected abstract void primitiivneop2(); public class KonkreetneKlassA extends AbstraktneKlass { protected void primitiivneop1(){ // primitiivse op-i kood, mis vastab variandile A ….

Šabloonmeetod koodis, variandi valik ja väljakutse AbstraktneKlass k; if (teatudTingimus){ k= new KonkreetneKlassA(); } else { k = new KonkreetneKlassB(); } … k.shabloonmeetod(); // see väljakutse toimub tavaliselt // teises meetodis kui initsialiseerimine

Installeerimise näide Näiteprobleemiks on teatud tarkvara installeerimine erinevatele operatsioonisüsteemidele (Windows, Unix, ..). Üldine installeerimisprotseduur jääb kõigi operatsioonisüsteemide puhul samaks. Erinevad detailsed sammud - kataloogi olemasolu kontroll, kataloogi loomine, failide kirjutamine kataloogi. Kuidas vältida üldise installeerimisprotseduuri dubleerimist?

Installeerimise näide Šabloonmeetod installeeri kutsub välja abstraktseid meetodeid, mis defineeritakse konkreetsele operatsioonisüsteemile vastavates alamklassides.

Installeerimise kontranäide 15

Hinnapoliitika näide Näiteprobleemiks on poodides kasutavad erinevad allahindlusskeemid - fikseeritud protsent, fikseeritud läve ületavalt tehingult fikseeritud allahindlus jne. Kuidas peaks erinevaid allahindlusskeeme lubav disain välja nägema?

Hinnapoliitika näide

Hinnapoliitika näide

Tehase meetod (Factory Method) Probleem: Kes peaks vastutama objektide loomise eest, kui on tegemist erinõudmistega, nagu keerukas loomisprotsess, soov eristada objekti loomine kõrgema kokkukuuluvuse saavutamiseks, soov vältida sõltuvust konkreetsest loodavast klassist jne? Lahendus: Defineeri liides objekti loomiseks, aga lase alamklassidel otsustada, mis klassist eksemplar tekitada.

Tehase meetod Koostöö: Looja jätab oma alamklassidele defineerimiseks tehase meetodi(d), mis tagastavad sobiva KonkreetseToote eksemplari. Looja konkreetsed operatsioonid (Operatsioon) võivad TehaseMeetodit välja kutsuda.

Labürindimängu näide Meil on tegemist labürindimänguga. Labürint koosneb seintest ja ustest. Kuidas kasutada sama labürindi põhiplaani loomise algoritmi, erinevat klassi kuuluvatest seintest ja ustest koosnevate labürintide loomiseks? Eeldus on, et ühes ja samas labürindis on kõik seinad ja uksed sama klassi.

Labürindimängu näide

Strateegia (Strategy) Probleem: Kuidas eraldada üldine algoritm varieeruvatest alamosadest? Kuidas muuta objekti käitumine täitmisajal muudetavaks ja erinevad käitumisstrateegiad korduvkasutatavateks? Lahendus: Defineeri varieeruvale käitumisele vastav Strateegiate klassihierarhia. Üldist käitumist defineerivad Konteksti objektid on seotud Strateegia objektidega ja kutsuvad välja nende meetodeid.

Strateegia

Koostöö Strateegia ja Kontekst suhtlevad, et Šabloonmeetodit realiseerida. Kontekst võib anda primitiivse operatsiooni jaoks vajalikud andmed Strateegiale parameetrina. Alternatiivina võib Kontekst iseennast parameetrina Strateegiale anda. Kontekst saadab sõnumid oma klientidelt edasi oma Strateegiale. Kliendid loovad tavaliselt KonkreetseStrateegia objekti ja seovad selle Kontekstiga; edaspidi suhtlevad kliendid ainult Kontekstiga.

Strateegia koodis public class Kontekst { private Strateegia strat; public void shabloonmeetod(){ … strat.primitiivneop1(); strat.primitiivneop2(); …} } public interface Strateegia { public void primitiivneOp1(); public void primitiivneOp2(); public class KonkreetneStrateegiaA implements Strateegia { protected void primitiivneop1(){ // primitiivse op-i kood

Strateegia koodis, variandi valik ja väljakutse Kontekst k = new Kontekst(); if (TeatudTingimus){ k.setStrat(new KonkreetneStrateegiaA()); } else { k.setStrat(new KonkreetneStrateegiaB()); } … k.shabloonmeetod(); // see väljakutse toimub tavaliselt // teises meetodis kui konteksti seadistus

Installeerimise näide

Hinnapoliitika näide

Hinnapoliitika näide

Strateegia või Šabloonmeetod? Delegeerimine (Strateegia) või pärimine (Šabloonmeetod)? Pärimine on lihtsamalt defineeritav, kuid objekt elutsükli jooksul oma klassi vahetada ei saa. Objekti, millele ülesanded delegeeritakse, saab delegeerija elutsükli jooksul vahetada. Kui on vaja objekti elutsükli käigus algoritme vahetada, siis tuleks kasutada keerukamat Strateegiat. Kui varieerub objekti mitu aspekti, siis erinevaid Strateegiaid on lihtsam kombineerida. Strateegiaid on võimalik eraldi korduvkasutada.

Olek (State) Probleem: Objekti käitumine sõltub tema olekust ja tema meetodid sisaldavad olekust sõltuvaid tegevusi peegeldavat tingimusloogikat. Milline oleks alternatiiv tingimusloogikale? Lahendus: Loo ühist liidest realiseerivad oleku klassid iga oleku tarvis. Delegeeri olekust sõltuvad operatsioonid konteksti objektilt tema hetke oleku objektile. Taga konteksti objekti seotus õige oleku objektiga üle oleku muutuste.

Olek

Koostöö Kontekst saadab olekust sõltuvad palved edasi Oleku objektile. Kontekst võib anda ennast parameetrina Oleku objektile. Kontekst on klientidele peamine liides. Kliendid võivad Konteksti olekuga konfigureerida, aga pärast seda kliendid enam olekuga ei suhtle. Kas Kontekst või KonkreetseOleku alamklassid otsustavad, mis olek järgneb teisele ja mis tingimustel.

Pöördvärava näide Meil on tegemist tasulist pöördväravat kontrolliva tarkvaraga. Olekud: avatud, suletud Registreeritavad sündmused: münt, möödumine Tegevused: ava, sule, täna maksjat, alarmeeri. Kuidas vältida tingimusloogikat pöördvärava klassis?

Pöördvärava näide

Pöördvärava näide

Adapter (Adapter) Probleem: Kuidas lahendada kokkusobimatute liideste probleem või pakkuda stabiilset ühist liidest erinevate liidestega, sisult sarnastele, komponentidele? Lahendus: Konverteeri komponendi algne liides teiseks liideseks läbi vahepealse Adapter objekti.

Adapter Koostöö: Kliendid kutsuvad välja Adapteri operatsioone. KonkreetneAdapter kutsub välja sobivaid Adapteeritava operatsioone.

Maksukalkulaatori näide On vaja pakkuda võimalust suhelda välise maksukalkulaatori tarkvaraga (TaxMaster, TaxPro). Kõik välised tarkvarakomponendid realiseerivad erinevat liidest. Kuidas oleks võimalik luua disaini, mis oleks sõltumatu konkreetsest välisest maksukalkulaatorist?

Maksukalkulaatori näide

Maksukalkulaatori näide

Maksukalkulaatori näide

Maksukalkulaatori näide

Lineaaralgebra paketi vektorid punktina

Sild (Bridge) Probleem: Klassi liides (abstraktsioon) ja meetodite realisatsioon võivad sõltumatult varieeruda. Igale liidese / realisatsiooni kombinatsioonile ei ole mõtet vastavat alamklassi defineerida. Kuidas kaitsta disaini mõlema aspekti varieerumise vastu? Lahendus: Loo abstraktsioonile ja realisatsioonile vastavad klassihierarhia. Abstraktsioonile vastavad objektid delegeerivad oma ülesanded realisatsioonile vastavatele objektidele.

Sild Koostöö: Abstraktsioon saadab Operatsiooni läbiviimise sõnumid edasi Realiseerijale (OperatsiooniImp()).

GUI raamistiku näide Ülesandeks on luua GUI raamistik, mis sisaldab klasse nagu Aken, Nupp, Menüü ja mis on piisavalt üldine, et joosta erinevate operatsioonisüsteemide ja raamistike peal. Varieeruda võib nii Akna abstraktsioon - meil on erinevat tüüpi aknad - kui ka API, millega akna kuvamiseks suhelda. Milline disain oleks kaitstud nende kahe aspekti varieerumise vastu?

Sild: GUI raamistiku näide

Strateegia: tarkvara installeerimise näide

Sild: Tarkvara installeerimise näide Erinevalt Strateegia näitest samal teemal, kus varieerus ainult OS, varieerub siin lisaks ka Tarkvara tüüp.

Kokkuvõte Šabloonmeetod, Strateegia - käitumise varieerimine läbi pärimise või delegeerimise. Tehase meetod - Alamklassis defineeritakse soovitud objekti loov meetod. Olek - varieerub olekust sõltuv käitumine. Adapter - liideste struktuuri ühtlustamine. Sild - abstraktsioon ja realisatsioon varieeruvad sõltumatult.

Viited Gamma, Helms, Johnson, Vlissides. Design Patterns. 1995. Larman, C. Applying UML and Patterns, 2002 Jezequel, Train, Mingins. Design Patterns and Contracts, 2000 Object Mentor: Articles: Patterns: http://www.objectmentor.com/resources/publishedArticles.html