Madame Lelica

kapitlet gennemgår syv problemer, der skal løses for at kunne designe Le .i korrekt, inklusive eventuelle begrænsninger, der skal følges. Hvert problem analyseres i dybden, og løsninger foreslås., Hver løsning forklares fuldt ud, herunder pseudokode og en let modificeret version af Objektmodelleringsteknik, hvor det er relevant.

endelig er hver løsning forbundet direkte med et eller flere designmønstre. Det vises, hvordan løsningen er en direkte implementering af dette designmønster.

De syv problemer (herunder deres begrænsninger) og deres løsninger (herunder mønster(s), der refereres til), er som følger:

Dokument StructureEdit

Det dokument, der er “en ordning for grundlæggende grafiske elementer”, såsom figurer, linjer, andre former osv.,, at “fange den samlede information indhold af dokumentet”(s. 35). Dokumentets struktur indeholder en samling af disse elementer, og hvert element kan igen være en understruktur af andre elementer.

Problemer og Begrænsninger

1. Tekst og grafik skal behandles på samme måde (det er, grafik er ikke en afledt forekomst af teksten, eller vice versa)
2. gennemførelsen bør behandle komplekse og simple konstruktioner på samme måde. Det skal ikke være nødvendigt at kende forskellen mellem de to.,
3. specifikke derivater af abstrakte elementer skal have specialiserede analytiske elementer.

løsning og mønster

en rekursiv sammensætning er en hierarkisk struktur af elementer, der bygger “stadig mere komplekse elementer ud af enklere” (s.36). Hver knude i strukturen kender til sine egne børn og dets forælder. Hvis en operation skal udføres på hele strukturen, kalder hver knude operationen på sine børn (rekursivt).

Dette er en implementering af det sammensatte mønster, som er en samling af noder., Noden er en abstrakt baseklasse, og derivater kan enten være blade (ental) eller samlinger af andre knuder (som igen kan indeholde blade eller samlingsnoder). Når en operation udføres på forælderen, overføres denne operation rekursivt ned i hierarkiet.

FormattingEdit

formatering adskiller sig fra struktur. Formatering er en metode til at konstruere en bestemt forekomst af dokumentets fysiske struktur. Dette inkluderer at bryde tekst i linjer, bruge bindestreger, justere for marginbredder osv.,

problemer og begrænsninger

1. Balance mellem (formatering) kvalitet, hastighed og lagerplads
2. hold formatering uafhængig (afkoblet) fra dokumentstrukturen.

opløsning og mønster

en Kompositorklasse indkapsler algoritmen, der bruges til at formatere en sammensætning. Kompositor er en underklasse af det primitive objekt i dokumentets struktur. En Kompositor har en tilknyttet forekomst af et Kompositionsobjekt., Når en Kompositor kører sin Compose(), gentager den gennem hvert element i den tilhørende sammensætning og omarrangerer strukturen ved at indsætte række-og Kolonneobjekter efter behov.

Kompositoren selv er en abstrakt klasse, der giver mulighed for afledte klasser til at bruge forskellige formateringsalgoritmer (såsom dobbeltafstand, bredere margener osv.)

Strategimønsteret bruges til at nå dette mål. En strategi er en metode til at indkapsle flere algoritmer, der skal bruges baseret på en skiftende kontekst., I dette tilfælde skal formatering være anderledes, afhængigt af om tekst, grafik, enkle elementer osv., bliver formateret.

udsmykke Brugergrænsefladeedit

evnen til at ændre den grafiske grænseflade, som brugeren bruger til at interagere med dokumentet.,

Problemer og Begrænsninger

1. Afgrænse en side med tekst med en ramme omkring redigering af området
2. Scroll-barer, der lader brugeren få vist forskellige dele af side
3. brugergrænseflade objekter bør ikke vide, om de dekorationer
4. Undgå en “eksplosion af klasser”, der kan være forårsaget af subclassing for enhver mulig kombination af dekorationer”, og elementer (s. 44)

Løsning og Mønster

brug af en transparent kabinet tillader elementer, der forstærker den adfærd sammensætning til at blive tilføjet til en komposition., Disse elementer, såsom Border og Scroller, er specielle underklasser af selve singularelementet. Dette gør det muligt at forøge sammensætningen, hvilket effektivt tilføjer statslignende elementer. Da disse udbygninger er en del af strukturen, vil deres passende Operation() blive kaldt, når strukturens Operation() kaldes. Det betyder, at klienten ikke har brug for nogen særlig viden eller grænseflade med strukturen for at kunne bruge udsmykningen.,

Dette er et Dekoratormønster, der tilføjer ansvar til et objekt uden at ændre selve objektet.

understøttelse af flere Look-And-Feel StandardsEdit

Look-and-feel refererer til platformspecifikke BRUGERGRÆNSEFLADESTANDARDER. Disse standarder “definerer retningslinjer for, hvordan applikationer vises og reagerer på brugeren” (s. 47).

Problemer og Begrænsninger

1. editor skal indføre standarder på flere platforme, så det er, bærbare
2. Nemt tilpasse sig til nye og kommende standarder
3. Giver mulighed for run-time ændring af look-and-feel (dvs,: Ingen hårdkodning)
4. har et sæt abstrakte elementære underklasser for hver kategori af elementer (rullebjælke, knapper osv.)
5. har et sæt konkrete underklasser for hver abstrakt underklasse, der kan have en anden look-and-feel standard. (ScrollBar der MotifScrollBar og PresentationScrollBar for Motiv og Præsentation se-og-føler)

Løsning og Mønster

Da objekt oprettelse af forskellige konkrete objekter ikke kan gøres på kørselstidspunktet, object creation proces, der skal udvindes., Dette gøres med et abstrakt guiFactory, der påtager sig ansvaret for at skabe UI-elementer. Den abstrakte guiFactory har konkrete implementeringer, såsom MotifFactory, som skaber konkrete elementer af den passende type (Motivercrollbar). På denne måde behøver programmet kun bede om en rullebjælke, og ved køretid får det det rigtige Betonelement.

Dette er en abstrakt fabrik. En almindelig fabrik skaber konkrete genstande af en type. En abstrakt fabrik skaber konkrete genstande af forskellige typer afhængigt af selve fabrikkens konkrete implementering., Dens evne til at fokusere på ikke kun konkrete genstande ,men hele familier af konkrete genstande “adskiller det fra andre skabelsesmønstre, der kun involverer en slags produktobjekt” (S.51).

Understøtter flere Vinduessystemeredit

ligesom udseende og følelse er forskellig på tværs af platforme, så er metoden til håndtering af windowsindo .s. Hver platform viser, lægger ud, håndterer input til og output fra, og lag vinduer forskelligt.,

Problemer og Begrænsninger

1. dokument editor skal køre på mange af de “vigtige og stort set uforenelige vindue systemer”, der findes (p. 52)
2. En Abstrakt Fabrik kan ikke bruges. På grund af forskellige standarder vil der ikke være en fælles abstrakt klasse for hver type wididget.
3. ikke oprette en ny, nonstandard windowing system

Løsning og Mønster

Det er muligt at udvikle “vores egen abstrakte og konkrete produkt klasser”, fordi “alle vindues-systemer generelt de samme ting” (s. 52)., Hvert vindue system giver operationer for at tegne primitive former, iconifying/de-iconifying, resizing, og forfriskende vinduet indhold.

en abstrakt base Window klasse kan udledes til de forskellige typer af eksisterende vinduer, såsom applikation, ikonificeret, dialog. Disse klasser vil indeholde operationer, der er forbundet med windowsindo .s, såsom omformning, Grafisk forfriskende osv. Hvert vindue indeholder elementer, hvis Draw() funktioner kaldes med Window‘s egne tegne-relaterede funktioner.,

for at undgå at skulle oprette platformspecifikke Vinduesunderklasser for enhver mulig platform, vil en grænseflade blive brugt. Window klassen implementerer enWindow implementering (WindowImp) abstrakt klasse. Denne klasse vil derefter igen blive afledt i flere platformspecifikke implementeringer, hver med platformspecifikke operationer., Derfor, er kun et sæt af Window klasser er nødvendig for hver type af Window, og kun et sæt af WindowImp klasser, der er nødvendige for hver platform (snarere end det Kartesiske produkt af alle tilgængelige typer og-platforme). Derudover kræver tilføjelse af en ny vinduetype ingen ændring af platformimplementering eller omvendt.

Dette er et Bromønster. Window og WindowImp er forskellige, men relaterede., Window omhandler windindo .ing i programmet, og WindowImp omhandler windindo .ing på en platform. En af dem kan ændre sig uden nogensinde at skulle ændre den anden. Bromønsteret gør det muligt for disse to” separate klassehierarkier at arbejde sammen, selv når de udvikler sig uafhængigt ” (s. 54).

Brugeroperationerrediger

alle handlinger, som brugeren kan tage med dokumentet, lige fra at indtaste tekst, ændre formatering, afslutte, gemme osv.,

Problemer og Begrænsninger

1. Operationer, der skal tilgås via forskellige indgange, som et menupunkt, og en tastaturgenvej til den samme kommando
2. Hver option har en grænseflade, som bør kunne ændres
3. Operationer gennemføres i flere forskellige klasser
4. for at undgå kobling, skal der ikke være en masse afhængigheder mellem gennemførelse og brugergrænsefladen klasser.,
5. Fortryd og redo kommandoer skal understøttes på de fleste dokument skiftende operationer, med ingen vilkårlig grænse for antallet af niveauer af Fortryd
6. funktioner er ikke levedygtige, da de ikke fortryde/redo nemt, er ikke let forbundet med en tilstand, og er svære at udvide eller genbruge.
7. menuer skal behandles som hierarkiske sammensatte strukturer. Derfor er en menu et menupunkt, der indeholder menupunkter, der kan indeholde andre menupunkter osv.,

løsning og mønster

hvert menupunkt, i stedet for at blive instantieret med en liste over parametre, udføres i stedet med et Kommandoobjekt.

Kommando er et abstrakt objekt, der kun har en enkelt abstrakt Execute() metode. Afledte objekter udvider Execute() metoden korrekt (dvs. PasteCommand.Execute() ville udnytte indholdets udklipsholder buffer). Disse objekter kan bruges af buttonsidgets eller knapper lige så let som de kan bruges af menupunkter.,

for at understøtte Fortryd og gentag, Command gives også Unexecute() og Reversible(). I afledte klasser indeholder førstnævnte kode, der vil fortryde denne kommando, og sidstnævnte returnerer en boolsk værdi, der definerer, om kommandoen er umulig. Reversible() tillader, at nogle kommandoer ikke kan åbnes, f.eks.

alle udførte Commands opbevares på en liste med en metode til at holde en “nuværende” markør direkte efter den senest udførte kommando., En anmodning om at fortryde vil kalde Command.Unexecute() direkte før “present”, og derefter flytte “present” tilbage en kommando. Omvendt vil en Redo anmodning kalde Command.Execute() efter “present” og flytte “present” fremad en.

denneCommand tilgang er en implementering af Kommandomønsteret. Det indkapsler anmodninger i objekter, og bruger en fælles grænseflade til at få adgang til disse anmodninger. Klienten kan således håndtere forskellige anmodninger, og kommandoer kan spredes gennem hele applikationen.,

stavekontrol og Bindestregedit

Dette er dokumenteditorens evne til tekstmæssigt at analysere indholdet af et dokument. Selv om der er mange analyser, der kan udføres, stavekontrol og orddeling-formatering er i fokus.

Problemer og Begrænsninger

1. Giver mulighed for flere måder at kontrollere stavning og med at identificere steder for orddeling
2. Give mulighed for ekspansion til fremtidige analyser (fx ord tæller, grammatikkontrol)
3. Være i stand til at gennemgå en tekst, indhold uden adgang til tekstens faktiske struktur (fx,
4. Tillad enhver form for gennemgang af dokument (begyndelse til ende, ende til begyndelse, alfabetisk rækkefølge osv.)

løsning og mønster

fjernelse af det heltalsbaserede indeks fra basiselementet gør det muligt at implementere en anden iterationsgrænseflade. Dette vil kræve ekstra metoder til traversal og objekt hentning. Disse metoder sættes i et abstraktIterator interface., Hvert element, der gennemfører en afledning af Iterator, afhængigt af hvordan det element, der holder sin liste (ArrayIterator LinkListIterator osv.).

funktioner til traversal og hentning sættes i den abstrakte Iterator interface. Fremtidige iteratorer kan udledes baseret på den type liste, de vil iterere gennem, såsom Arrays eller linkede lister. Uanset hvilken type indekseringsmetode enhver implementering af elementet bruger, vil den have den passende Iterator.

Dette er en implementering af Iteratormønsteret., Det giver klienten mulighed for at krydse gennem enhver objektsamling uden at skulle få adgang til indholdet af samlingen direkte eller være bekymret for den type liste, som samlingens struktur bruger.

nu hvor traversal er blevet håndteret, er det muligt at analysere elementerne i en struktur. Det er ikke muligt at bygge hver type analyse i selve elementstrukturen; hvert element skal kodes, og meget af koden ville være den samme for lignende elementer.

i stedet er en generisk CheckMe() metode indbygget i elementets abstrakte klasse., Hver Iterator får en henvisning til en bestemt algoritme (såsom stavekontrol, grammatik kontrol, etc.). Når denne Iterator gentager sig gennem sin samling, kalder den hvert element CheckMe, der passerer den angivne algoritme. CheckMe sender derefter en henvisning til dens element tilbage til algoritmen til analyse.

for at udføre en stavekontrol ville en front-to-end iterator få en henvisning til et SpellCheck objekt., Iterator vil derefter få adgang til hvert element, udførelse af sin CheckMe() metode med SpellCheck parameter. Hver CheckMe vil derefter kalde SpellCheck, idet der henvises til det relevante element.

på denne måde kan enhver algoritme bruges med enhver traversal metode uden hardkodekobling den ene med den anden. For eksempel kan Find bruges som “find ne .t” eller “find previous”, afhængigt af om en “fremad” iterator blev brugt eller en “baglæns” iterator.,

derudover kan algoritmerne selv være ansvarlige for at håndtere forskellige elementer. For eksempel, en SpellCheck algoritme vil ignorere en Graphic – element, snarere end at skulle programmere hvert Graphic-afledte element til ikke at sende sig selv til en SpellCheck.