luku käy läpi seitsemän ongelmia, joihin on puututtava, jotta voidaan asianmukaisesti suunnittelu Lexi, mukaan lukien mahdolliset rajoitukset, joita on noudatettava. Jokainen ongelma analysoidaan perusteellisesti, ja ratkaisuja ehdotetaan., Jokainen ratkaisu on selitetty kokonaisuudessaan, mukaan lukien pseudokoodi ja hieman muokattu versio Oliomallinnustekniikasta tarvittaessa.
lopulta jokainen liuos liittyy suoraan yhteen tai useampaan suunnittelukuvioon. On osoitettu, miten ratkaisu on suora täytäntöönpano tämän suunnittelumallin.
seitsemän ongelmat (ja niiden rajoitukset) ja niiden ratkaisut (mukaan lukien malli(s) viitataan), ovat seuraavat:
Asiakirjan StructureEdit
asiakirja on ”järjestely perus graafisia elementtejä”, kuten merkit, viivat, muut muotoja, jne.,, että ”kaapata koko tietosisältö asiakirjan” (s.35). Rakennetta asiakirjan, joka sisältää nämä elementit, ja jokainen elementti voi puolestaan olla alusrakenne muita elementtejä.
Ongelmat ja Rajoitteet
- Teksti ja grafiikka olisi kohdeltava samalla tavalla (eli näytönohjain ei ole johdettu esimerkiksi tekstiä, eikä päinvastoin)
- toteutus tulisi hoitaa monimutkaisia ja yksinkertaisia rakenteita samalla tavalla. Sen ei pitäisi joutua tietämään näiden kahden eroa.,
- abstraktien alkuaineiden erityisjohdannaisilla tulisi olla erikoistuneita analyyttisiä elementtejä.
Ratkaisu ja Malli
rekursiivinen koostumus on hierarkkinen rakenne-elementtejä, joka rakentaa ”yhä monimutkaisempia elementtejä pois yksinkertaisempi niistä” (s. 36). Jokainen solmukohta rakenteessa tuntee omat lapsensa ja vanhempansa. Jos toimenpide aiotaan suorittaa koko rakenteelle, jokainen solmu kutsuu operaatiota lapsilleen (rekursiivisesti).
kyseessä on komposiittikuvion toteutus, joka on joukko solmuja., Solmu on abstrakti perustaa luokan, ja johdannaiset voivat olla joko lehdet (yksikössä), tai kokoelmat muut solmut (joka puolestaan voi sisältää lehtiä tai kokoelma-solmut). Kun toimenpide suoritetaan vanhemmalle, kyseinen toimenpide siirtyy rekursiivisesti hierarkian alapuolelle.
FormattingEdit
Muotoilu eroaa rakenne. Formatointi on tapa rakentaa tietty esimerkki dokumentin fyysisestä rakenteesta. Tämä sisältää rikkomatta tekstiä linjat, käyttää väliviivoja, säätö-marginaali leveys, jne.,
Ongelmat ja Rajoitteet
- Tasapaino (alustus) laatua, nopeutta ja tallennustilaa
- Pitää muotoilua riippumaton (irti) asiakirjan rakenne.
Ratkaisu ja Malli
Latoja luokka kiteyttää käytetty algoritmi alustaa koostumus. Compositor on asiakirjan rakenteen primitiivisen kohteen alaluokka. Kompostorilla on siihen liittyvä instanssi Koostumusobjektista., Kun Latoja kulkee sen Compose(), se käy läpi jokaisen elementin siihen liittyvät Koostumus ja ryhmitellään rakenne, lisäämällä Rivi ja Sarake esineitä kuin tarvitaan.
Latoja itsessään on abstrakti luokka, mahdollistaa johdannainen luokat käyttää eri muotoilua algoritmit (kuten double-väli, leveämmät marginaalit, jne.)
strategian kaavaa käytetään tämän tavoitteen saavuttamiseksi. Strategia on menetelmä, jossa useita algoritmeja kapseloidaan muuttuvaan kontekstiin perustuen., Tällöin muotoilun pitäisi olla erilaista riippuen siitä, onko teksti, grafiikka, yksinkertaiset elementit jne., ovat alustettu.
käyttäjän Interfaceeditin
Kaunisteleminen kykyä muuttaa graafista käyttöliittymää, jota käyttäjä käyttää vuorovaikutuksessa dokumentin kanssa.,
Ongelmat ja Rajoitteet
- Rajata sivun tekstin reunuksen muokkaus alue
- vierityspalkit, joka antaa käyttäjän katsella eri osissa-sivu
- käyttöliittymän objektit pitäisi tietää koristeita
- Vältetään ”räjähdys luokat”, joka olisi aiheuttanut subclassing ”jokainen mahdollinen yhdistelmä koristeita” ja elementtejä (p. 44)
Ratkaisu ja Malli
avoin kotelo mahdollistaa elementtejä, jotka tukevat käyttäytymisen koostumus lisätään koostumus., Nämä elementit, kuten Border ja Scroller, ovat erityisiä alaluokkia yksikössä Elementti itse. Tämä mahdollistaa koostumuksen lisäämisen, lisäämällä tehokkaasti valtion kaltaisia elementtejä. Koska nämä muutokset ovat osa rakennetta, niiden asianmukainen Operation() kutsutaan, kun rakenne on Operation() kutsutaan. Tämä tarkoittaa sitä, että asiakkaan ei tarvitse mitään erityistä tietoa tai käyttöliittymän rakenne jotta voit käyttää koristeita.,
Tämä on Sisustusarkkitehti kuvio, joka lisää vastuuta esine muuttamatta esine itse.
Tukee Useita Look-Ja-tuntumaa StandardsEdit
Look-ja-tuntumaa viittaa platform-erityiset UI standardeja. Nämä standardit ”määrittelevät ohjeet, miten sovellukset näkyvät ja reagoivat käyttäjään” (s.47).
Ongelmat ja Rajoitteet
- toimittaja on pantava täytäntöön standardeja useilla eri alustoilla niin, että se on kannettava
- Helposti sopeutua uusiin ja uutena standardeja
- Mahdollistaa run-time muuttaminen look-ja-tuntumaa (ts.,: Ole kova-koodaus)
- On joukko abstrakteja alkuaine alaluokkia kunkin luokan elementtejä (ScrollBar, Painikkeet, jne.)
- On joukko konkreettisia alaluokkia kunkin abstrakti alaluokka, joka voi olla erilainen look-ja-tuntumaa standardi. (Vierityspalkki ottaa MotifScrollBar ja PresentationScrollBar varten Motiivi ja Esitys näyttää ja tuntuu)
Ratkaisu ja Malli
Koska objektin luominen erilaisia konkreettisia esineitä ei voi tehdä suorituksen, objektin luomisen prosessi on hajamielinen., Tämä tehdään abstraktilla guifactorylla, joka ottaa vastuulleen KÄYTTÖLIITTYMÄELEMENTTIEN luomisen. Abstrakti guiFactory on konkreettisia toteutuksia, kuten MotifFactory, joka luo konkreettisia elementtejä sopivaa tyyppiä (MotifScrollBar). Näin ohjelma tarvitsee vain pyytää ScrollBar ja, ajon aikana, se annetaan oikea konkreettinen Elementti.
Tämä on abstrakti tehdas. Tavallinen tehdas luo yhden tyypin betoniesineitä. Abstrakti tehdas luo erilaisia betoniesineitä riippuen itse tehtaan konkreettisesta toteutuksesta., Sen kyky keskittyä ei vain konkreettisia esineitä, mutta koko perheille konkreettisia esineitä ”erottaa sen muista creational patterns, joissa on mukana vain yksi sellainen tuote, esine” (s. 51).
Tukee Useita Ikkuna SystemsEdit
Aivan kuten look-ja-tuntumaa on erilainen eri alustoilla, joten on tapa käsitellä windows. Jokainen alusta näyttää, määrittää, käsittelee Tulo ja lähtö, ja kerrokset ikkunat eri tavalla.,
Ongelmat ja Rajoitteet
- asiakirja editori on ajaa monet ”tärkeää ja pitkälti ristiriidassa ikkunan järjestelmiä”, jotka ovat olemassa (p. 52)
- Abstrakti Tehdas ei voi käyttää. Erilaisten standardien vuoksi kullekin widget-tyypille ei ole yhteistä abstraktia luokkaa.
- Älä luo uutta, kirjakieleen ikkunointi järjestelmä
Ratkaisu ja Malli
on mahdollista kehittää ”omaa abstrakteja ja konkreettisia tuotteen luokat”, koska ”kaikki ikkuna järjestelmät eivät yleensä sama asia” (s. 52)., Jokainen ikkunajärjestelmä tarjoaa toimintoja primitiivisten muotojen piirtämiseen, ikonifiointiin / kuvakkeen poistamiseen, koon muuttamiseen ja ikkunan sisällön virkistämiseen.
abstrakti pohja Window luokka voi olla peräisin eri tyyppisten nykyisten windows, kuten sovellus, kuvakkeeksi, dialogi. Nämä luokat sisältävät Windowsiin liittyviä toimintoja, kuten uudelleenmuokkausta, graafisesti virkistävää jne. Jokainen ikkuna sisältää elementtejä, joiden Draw() toiminnot ovat kutsutaan, kun Windowomaa piirtää liittyviä toimintoja.,
jotta ei tarvitsisi luoda alustakohtaisia ikkunan alaluokkia jokaiselle mahdolliselle alustalle, käytetään käyttöliittymää. Window luokka toteuttaa Window toteutus (WindowImp) abstrakti luokka. Tämä luokka puolestaan johdetaan useiksi alustakohtaisiksi toteutuksiksi, joissa kussakin on alustakohtaisia toimintoja., Näin ollen vain yksi joukko Window luokat tarvitaan kullekin Window, ja vain yksi sarja WindowImp luokat tarvitaan kunkin alustan (pikemminkin kuin Karteesinen tuote kaikki käytettävissä olevat tyypit ja ympäristöissä). Lisäksi uuden ikkunatyypin lisääminen ei vaadi Alustan toteutuksen muuttamista tai päinvastoin.
Tämä on Siltakuvio. Window ja WindowImp ovat erilaisia, mutta liittyvät., Window käsittelee ikkunointi ohjelma, ja WindowImp käsittelee ikkunointi alustalla. Toinen niistä voi muuttua ilman, että tarvitsee koskaan muuttaa toista. Silta-malli mahdollistaa näiden kahden ”erillisen luokan hierarkiat toimimaan yhdessä, vaikka he kehittyä itsenäisesti” (s. 54).
Käyttäjä OperationsEdit
Kaikki toimet käyttäjä voi ottaa mukaan asiakirja, jotka vaihtelevat tekstin syöttäminen, muuttaminen muotoilu, lopettaa, säästö, jne.,
Ongelmat ja Rajoitteet
- Toiminnan on oltava saatavilla eri tuotantopanosten, kuten valikon ja näppäimistön oikotie sama komento
- Jokainen vaihtoehto on käyttöliittymä, jonka pitäisi olla muokattavissa
- Toiminnot ovat toteutettu useita eri luokat
- välttämiseksi kytkentä, siinä ei saa olla paljon välisiä riippuvuuksia toteutus ja käyttöliittymän luokat.,
- Kumoa ja tee uudelleen komentoja on tuettu useimmissa asiakirja muuttuvat toiminnot, joilla ei ole mielivaltainen rajoitettu määrä tasoja kumoa
- Toiminnot eivät ole kannattavia, koska ne eivät kumoa/tee uudelleen helposti, eivät ole helposti liittyy valtion, ja on vaikea laajentaa tai käyttää uudelleen.
- valikot tulisi käsitellä hierarkkisina komposiittirakenteina. Näin ollen valikko on valikkokohta, joka sisältää valikkokohtia, jotka voivat sisältää muita valikkokohtia, jne.,
Ratkaisu ja Malli
Jokainen valikkokohta, sen sijaan, että instantiated luettelo parametrit, on sen sijaan tehnyt Komento-objekti.
– Komento on abstrakti objekti, joka on vain yksi abstrakti Execute() menetelmä. Johdannainen esineitä laajentaa Execute() menetelmä asianmukaisesti (eli PasteCommand.Execute() olisi käyttää sisältöä leikepöydälle buffer). Näitä esineitä voidaan käyttää widgeteillä tai painikkeilla yhtä helposti kuin niitä voidaan käyttää valikkokohtien avulla.,
tukea kumoa ja tee uudelleen, Command annetaan myös Unexecute() ja Reversible(). Johdettuihin luokkiin, entinen sisältää koodia, joka tulee kumota, että komento, ja jälkimmäinen palauttaa boolean-arvon, joka määrittää, jos komento on auki. Reversible() sallii joidenkin komentojen olevan epäkelpoja, kuten Save-komennon.
Kaikki teloitettiin Commands pidetään luettelossa tapa pitää ”esittää” merkki välittömästi sen jälkeen, kun viimeksi teloitettiin komento., Perumispyyntö kutsuu Command.Unexecute() suoraan ennen ”present”, siirrä” present ” takaisin yksi komento. Päinvastoin, Redo pyyntö soittaa Command.Execute() jälkeen ”läsnä” ja siirrä ”läsnä” eteenpäin yksi.
Tämä Command lähestymistapa on täytäntöönpano Komento kuvio. Se kerää pyyntöjä esineisiin ja käyttää yhteistä rajapintaa kyseisiin pyyntöihin pääsemiseksi. Näin asiakas voi käsitellä erilaisia pyyntöjä, ja komentoja voidaan sirotella koko sovellukseen.,
Oikeinkirjoituksen tarkistus ja HyphenationEdit
– Tämä on asiakirja, toimittajan kyky sanallisesti analysoida dokumentin sisällön. Vaikka on olemassa monia analyysejä, jotka voidaan suorittaa, oikeinkirjoituksen tarkistus ja tavutus-muotoilu ovat painopiste.
Ongelmat ja Rajoitteet
- Mahdollistaa useita tapoja tarkistaa oikeinkirjoituksen ja tunnistaa paikkoja tavutus
- Jotta laajeneminen tulevaisuuden analyysi (esim, word count, kieliopin tarkastus)
- voi kerrata läpi tekstin sisällön ilman pääsyä tekstin varsinainen rakenne (esim.,, array, linked list, string)
- mahdollistavat minkä tahansa asiakirjan läpimenon (alusta loppuun, lopusta alkuun, aakkosjärjestykseen jne.)
Ratkaisu ja Malli
Poistaminen kokonaisluku-pohjainen indeksi perus elementti mahdollistaa eri iteraation käyttöliittymä toteutetaan. Tämä edellyttää ylimääräisiä menetelmiä läpivientiin ja esinehakuun. Nämä menetelmät laitetaan abstraktiin Iterator – rajapintaan., Jokainen elementti sitten toteuttaa johtaminen Iterator riippuen siitä, miten tämä elementti pitää sen list (ArrayIterator, LinkListIterator jne.).
läpiajon ja noutamisen funktiot laitetaan abstraktiin Iteraattorirajapintaan. Tulevat iteraattorit voidaan johtaa sen luettelon perusteella, jonka kautta ne iteroidaan, kuten matriisit tai linkitetyt luettelot. Näin ollen riippumatta siitä, minkä tyyppinen indeksointimenetelmä tahansa toteutuksen elementti käyttää, se on sopiva iteraattori.
Tämä on Iteraattorikuvion toteutus., Sen avulla asiakas voi kulkea läpi minkä tahansa esineen kokoelma, ilman, että tarvitsee käyttää sisällön kerääminen suoraan, tai olla huolissaan luettelon tyyppi kokoelman rakenne käyttää.
nyt kun traversal on käsitelty, on mahdollista analysoida rakenteen elementtejä. Se ei ole mahdollista rakentaa kunkin analyysin osaksi elementti rakenne itseään; jokaisen elementin täytyy olla koodattu, ja paljon koodia olisi sama vastaavia elementtejä.
sen Sijaan, geneerinen CheckMe() menetelmä on rakennettu elementti on abstrakti luokka., Jokaiselle Iteraattorille annetaan viittaus tiettyyn algoritmiin (kuten loitsutarkistus, kielioppitarkistus jne.). Kun Iteraattori käy läpi sen kokoelma, se vaatii jokaisen elementin CheckMe, kulkee tietyn algoritmin. CheckMe siirtää sitten viittauksen alkuaineeseensa takaisin kyseiseen algoritmiin analysoitavaksi.
Näin ollen suorittaa oikeinkirjoituksen tarkistus, front-to-end-iteraattori olisi annettava viittaus SpellCheck objekti., Iteraattori olisi sitten käyttää jokaisen elementin, sen suorittamista CheckMe() menetelmä, jossa SpellCheck parametri. Jokainen CheckMe olisi sitten soittaa SpellCheck, kulkee viittaus sopiva elementti.
tällä tavalla, mikä tahansa algoritmi voidaan käyttää minkä tahansa läpikäynti-menetelmällä, ilman kovaa-koodi kytkimen toistensa kanssa. Esimerkiksi Find voidaan käyttää muodossa ”find next” tai ” find previous ”riippuen siitä, käytetäänkö” forward ”iteraattoria vai” takaperin ” iteraattoria.,
lisäksi algoritmit itse voivat olla vastuussa erilaisten elementtien käsittelystä. Esimerkiksi SpellCheck algoritmi huomioisi Graphic elementti, pikemminkin kuin ottaa ohjelma, joka Graphicjohdettu elementti ei lähetä itse SpellCheck.