Madame Lelica

kapitlet går gjennom syv problemer som må løses for å riktig design Lexi, herunder eventuelle begrensninger som må følges. Hver problemet er analysert i dybden, og løsningene som er foreslått., Hver løsning er forklart i sin helhet, inkludert pseudo-kode og en litt modifisert versjon av Object Modeling Technique der det er hensiktsmessig.

til Slutt, hver løsning er direkte forbundet med en eller flere design mønstre. Det er vist hvordan løsningen er en direkte implementering av at design mønster.

De syv problemer (inkludert deres begrensninger) og deres løsninger (inkludert mønster(s) som det refereres til), er som følger:

Dokument StructureEdit

dokumentet er «et arrangement av grunnleggende grafiske elementer» som tegn, linjer, andre former, etc., at «fange den totale informasjon om innholdet i dokumentet»(s. 35). Strukturen i dokumentet inneholder en samling av disse elementene, og hvert element kan i sin tur være et underlag av andre elementer.

Problemer og Begrensninger

1. Tekst og grafikk bør behandles på samme måte (som er, grafikk ikke er en avledet forekomst av teksten, eller vice versa)
2. gjennomføringen bør behandle komplekse og enkle strukturer på samme måte. Det skal ikke være nødt til å vite forskjell mellom de to.,
3. Spesifikke derivater av abstrakte elementer bør ha spesialisert analytiske elementer.

Løsningen og Mønster

En rekursiv sammensetning er en hierarkisk ordning av elementene, som bygger «stadig mer komplekse elementer ut av enklere seg» (s. 36). Hver node i strukturen vet av sine egne barn og sin forelder. Hvis en operasjon skal utføres på hele strukturen, hver node samtaler operasjonen på sine barn (med undermapper).

Dette er en implementering av kompositt-mønster, som er en samling av noder., Noden er en abstrakt base klasse, og derivater kan enten være blader (entall), eller samlinger av andre noder (som i sin tur kan inneholde blader eller samling-noder). Når en operasjon utføres på foreldrene, at operasjonen er undermapper gått ned i hierarkiet.

FormattingEdit

Formatering er forskjellig fra strukturen. Formatering er en metode for å konstruere en bestemt forekomst av dokumentets fysiske struktur. Dette inkluderer å bryte tekst i linjer, ved hjelp av bindestrek, for å justere for-margin bredder, etc.,

Problemer og Begrensninger

1. Balanse mellom (formatering) kvalitet, hastighet og lagringsplass
2. Beholde formatering uavhengige (uncoupled) fra dokumentet struktur.

Løsningen og Mønster

En Compositor klasse vil kapsle algoritmen som brukes til å formatere en komposisjon. Compositor er en underklassen av primitive objekt av dokumentets struktur. En Compositor har en tilknyttet forekomst av en Sammensetning objekt., Når en Setter driver sin Compose() det-koden gjennom hvert element på den tilhørende Sammensetning, og ordner strukturen ved å sette inn Rad-og Kolonne-objekter som trengs.

Compositor seg selv er en abstrakt klasse, slik at for avledede klasser å bruke forskjellig formatering algoritmer (for eksempel dobbel linjeavstand, større marginer, etc.)

Strategi Mønsteret er brukt for å oppnå dette målet. En Strategi er en metode for å vise flere algoritmer som skal brukes basert på en endret kontekst., I dette tilfellet, formatering bør være forskjellig, avhengig av om tekst, grafikk, enkle elementer, etc. blir formatert.

Embellishing Brukeren InterfaceEdit

evnen til å endre det grafiske grensesnittet som brukeren benytter for å samhandle med dokumentet.,

Problemer og Begrensninger

1. Markere en side av teksten med en ramme rundt redigering område
2. Bla barer som lar brukeren vise forskjellige deler av siden som
3. brukergrensesnitt gjenstander bør ikke vet om utsmykking
4. Unngå en «eksplosjon av klasser» som kunne være forårsaket av subclassing for «alle mulige kombinasjoner av pynt» og elementer (s. 44)

Løsningen og Mønster

bruk av et gjennomsiktig kabinett tillater elementer som forsterker atferden til sammensetningen skal være lagt til en komposisjon., Disse elementene, slik som Grensen og Scroller, er spesielle underklasser av den fantastiske element i seg selv. Dette gjør at sammensetningen til å bli utvidet, effektivt å legge til staten-som elementer. Siden disse forsterkninger er en del av strukturen, deres passende Operation() vil bli kalt når strukturen er Operation() kalles. Dette betyr at klienten ikke trenger noen spesiell kunnskap eller grensesnitt med strukturen for å bruke til pynt.,

Dette er en Dekoratør mønster, en som legger ansvar til et objekt uten å endre selve objektet.

som Støtter Flere Se-Og-Føle StandardsEdit

Se-og-føle refererer til plattform-UI-standarder. Disse standardene «definerer retningslinjer for hvordan applikasjoner dukker opp og reagere på brukeren» (s. 47).

Problemer og Begrensninger

1. redaktøren må implementere standarder for flere plattformer slik at den er bærbar
2. Enkelt å tilpasse seg nye og eksisterende standarder
3. Tillat for run-time endring av utseende (dvs.,: Ingen hard-koding)
4. Ha et sett av abstrakte elemental underklasser for hver kategori av elementer (Rullefeltet, Knapper, etc.)
5. Ha et sett av konkrete underklasser for hver abstrakt underklassen som kan ha forskjellig utseende og følelsen standard. (Rullefeltet å ha MotifScrollBar og PresentationScrollBar for Motiv og Presentasjon som ser ut og føles)

Løsningen og Mønster

Siden objekt opprettelse av ulike konkrete objekter kan ikke gjøres under kjøring objekt prosessen må abstraheres., Dette er gjort med et abstrakt guiFactory, som tar på seg ansvaret for å skape UI-elementer. Det abstrakte guiFactory har konkrete implementasjoner, for eksempel MotifFactory, noe som skaper konkrete elementer av riktig type (MotifScrollBar). På denne måten, programmet må bare be om et Rullefelt og, på run-time, vil det bli gitt riktig betong element.

Dette er en Abstrakt Fabrikken. En vanlig fabrikk skaper konkrete objekter av en type. Et abstract factory skaper konkrete objekter i ulike typer, avhengig av den konkrete implementeringen av fabrikken i seg selv., Dens evne til å fokusere på, ikke bare konkrete objekter, men hele familier av konkrete objekter «som skiller den fra andre creational mønstre, som involverer bare én type produkt objekt» (s. 51).

som Støtter Flere Vinduet SystemsEdit

Akkurat som utseende er forskjellig på tvers av plattformer, så er metoden for håndtering av windows. Hver plattform viser, legger ut, håndterer input til og output fra, og lag windows på en annen måte.,

Problemer og Begrensninger

1. dokument editor må kjøre på mange av de «viktige og i stor grad uforenlig vindu systemer» som eksisterer (s. 52)
2. Et Abstrakt Fabrikken kan ikke brukes. På grunn av ulik standarder, vil det ikke være en felles abstrakt klasse for hver type widget.
3. du Må ikke opprette en ny, ikke-standarisert windowing system

Løsningen og Mønster

Det er mulig å utvikle «våre egne abstrakte og konkrete produkt-klasser», fordi «alle vindu systemer gjør vanligvis det samme» (s. 52)., Hvert vindu system gir operasjoner for tegning primitive former, iconifying/de-iconifying, størrelse, og forfriskende innholdet i et vindu.

En abstrakt base Window klassen kan være avledet til forskjellige typer eksisterende windows, for eksempel program, iconified, dialog. Disse klassene vil inneholde virksomhet som er forbundet med windows, for eksempel omforming, grafisk forfriskende, etc. Hvert vindu inneholder elementer som Draw() funksjoner blir kalt på av Window‘s egen tegne-relaterte funksjoner.,

for å unngå å måtte lage plattform-spesifikke Vinduet underklasser for hver mulig plattform, et grensesnitt som vil bli brukt. Window klassen skal implementere en Window implementering (WindowImp) abstrakt klasse. Denne klassen vil så i sin tur bli hentet inn flere plattform-spesifikke implementeringer, hver med plattform-spesifikke operasjoner., Derfor, bare ett sett av Window klasser er nødvendig for hver type Window, og bare ett sett av WindowImp klasser er nødvendig for hver plattform (snarere enn Kartesiske produktet av alle tilgjengelige typer og plattformer). I tillegg legger til en ny type vindu krever ikke endring av plattform gjennomføring, eller vice versa.

Dette er en Bro mønster. Window og WindowImp er ulike, men relaterte., Window avtaler med windowing i programmet, og WindowImp avtaler med windowing på en plattform. En av dem kan endres uten at du trenger å endre på noe annet. Broen mønster gjør at disse to «egen klasse hierarkier å jobbe sammen selv som de utvikler seg uavhengig av hverandre» (s. 54).

Bruker OperationsEdit

Alle handlinger som brukeren kan ta med dokumentet, alt fra å skrive inn tekst, endre formatering, røykeslutt, lagring, etc.,

Problemer og Begrensninger

1. Operasjoner må nås gjennom ulike innganger, for eksempel et menyvalg, og en hurtigtast for den samme kommandoen
2. Hvert alternativ har et grensesnitt, som bør være modifiserbare
3. Operasjoner er gjennomført i flere forskjellige klasser
4. for å unngå koplingen, må det ikke være mye av avhengigheter mellom implementering og brukergrensesnitt klasser.,
5. Angre og gjør om-kommandoer må støttes på de fleste dokumentet endrer operasjoner, med ingen vilkårlig grense på antall nivåer av angre
6. Funksjoner er ikke levedyktig, siden de ikke angre/gjøre om lett, er ikke lett assosiert med en tilstand, og det er vanskelig å utvide eller gjenbruk.
7. Menyer bør behandles som hierarkisk sammensatte strukturer. Derfor, en meny er et menyelement som inneholder menyen elementer som kan inneholde andre menyelementer, etc.,

Løsningen og Mønster

Hvert menyelement, snarere enn å være startet med en liste over parametere, er i stedet gjort med en Kommando objekt.

– Kommandoen, er et abstrakt objekt som kun har en enkelt abstrakt Execute() metode. Derivat objekter utvide Execute() metoden på riktig måte (dvs., PasteCommand.Execute() ville utnytte innholdet på utklippstavlen buffer). Disse objektene kan brukes av widgets eller knapper like enkelt som de kan brukes av menyelementer.,

for Å støtte angre og gjør om, Command er også gitt Unexecute() og Reversible(). I avledede klasser, den tidligere inneholder koden som du vil angre på at kommandoen, og sistnevnte returnerer en boolsk verdi som angir om kommandoen er angrast. Reversible() kan noen kommandoer for å være ikke-angrast, for eksempel en Lagre-kommandoen.

Alle henrettet Commands er holdt i en liste med en metode for å holde en «tilstede» markør rett etter den siste utførte kommandoen., En forespørsel om å angre vil ringe Command.Unexecute() rett før «til stede», og deretter flytte «til stede» tilbake én kommando. I motsatt fall, en Redo forespørsel vil kalle Command.Execute() etter «tilstede», og flytte «til stede» frem.

Denne Command tilnærming er en implementering av Kommandoen mønster. Det omslutter forespørsler i objekter, og bruker et felles grensesnitt for å få tilgang til disse forespørsler. Dermed klienten kan håndtere ulike forespørsler, og kommandoer som kan være spredt over hele programmet.,

stavekontroll og HyphenationEdit

Dette er dokument editor ‘ s evne til å textually analysere innholdet av et dokument. Selv om det er mange analyser som kan utføres, stavekontroll og orddeling-formatering er i fokus.

Problemer og Begrensninger

1. Tillate flere måter å sjekke stavemåte og identifisere steder for orddeling
2. Tillate ekspansjon for fremtidige analyser (f.eks., word count, grammatikkontrollen)
3. Være i stand til å gå gjennom en tekstens innhold uten tilgang til tekst faktiske struktur (f.eks.,, array, lenket liste, string)
4. Tillat for alle slags traversal av dokumentet (start til slutt, slutten til begynnelsen, alfabetisk rekkefølge, etc.)

Løsningen og Mønster

å Fjerne heltall-basert indeks fra grunnleggende element åpner for en annen iterasjon grensesnitt for å bli implementert. Dette vil kreve ekstra metoder for traversal og objekt henting. Disse metodene er satt inn i en abstrakt Iterator grensesnitt., Hvert element deretter implementerer en avledning av Iterator, avhengig av hvordan dette elementet holder sin liste (ArrayIterator, LinkListIterator, osv.).

Funksjoner for traversal og gjenfinning er satt inn i det abstrakte Iterator-grensesnitt. Fremtiden Iterators kan utledes basert på type liste de vil være iterating gjennom, for eksempel Tabeller eller Lenkede Lister. Derfor, uansett hva slags indeksering metode for implementering av elementet bruker, vil den ha riktig Iterator.

Dette er en implementering av Iterator pattern., Det gjør det mulig for klienten å gå gjennom alle objekter samling, uten at du trenger å få tilgang til innholdet i samlingen direkte, eller være bekymret for den type liste samlingen struktur bruker.

Nå som traversal har blitt håndtert på, er det mulig å analysere elementene i en struktur. Det er ikke mulig å bygge hver type analyse inn i elementet strukturere seg; hvert element må være kodet, og mye av koden vil være den samme for like elementer.

i Stedet er det en generisk CheckMe() metoden er bygget inn i elementet er en abstrakt klasse., Hver Iterator er gitt en referanse til en bestemt algoritme (for eksempel stavekontroll, grammatikkontroll kontroller, etc.). Når det Iterator-koden gjennom sin samling, det kaller hvert element er CheckMe, passerer angitte algoritmen. CheckMe deretter går en referanse til element tilbake å sa algoritme for analyse.

Derfor, for å utføre en spell check, en front-til-ende-iterator ville bli gitt en referanse til en SpellCheck objekt., Den iterator vil da få tilgang til hvert element, og utfører sin CheckMe() metode med SpellCheck – parameteren. Hver CheckMe da ville ringe SpellCheck, passerer en referanse til riktig element.

På denne måten, noen algoritme kan brukes med alle traversal metode, uten hard-kode kopling ene med det andre. For eksempel, kan du Finne kan brukes som «finn neste» eller «finne tilbake», avhengig av om en «forward» iterator ble brukt, eller en «bakover» iterator.,

I tillegg algoritmer kan selv være ansvarlig for å håndtere forskjellige elementer. For eksempel, en SpellCheck algoritmen ville ignorere en Graphic – element, snarere enn å måtte program hver Graphic-avledet element hvis du ikke vil sende seg selv til en SpellCheck.