a fejezet hét problémán megy keresztül, amelyekkel foglalkozni kell A Lexi megfelelő megtervezése érdekében, beleértve a követendő korlátozásokat is. Minden problémát részletesen elemeznek, megoldásokat javasolnak., Minden megoldás teljes egészében kifejtésre kerül, beleértve a pszeudo-kódot és adott esetben az Objektummodellezési technika kissé módosított változatát is.
végül minden megoldás közvetlenül egy vagy több tervezési mintához kapcsolódik. Megmutatják, hogy a megoldás hogyan valósítja meg a tervezési mintát.
a hét probléma (beleértve azok korlátait is) és megoldásaik (beleértve a hivatkozott mintát is) a következők:
Document StructureEdit
a dokumentum “alapvető grafikus elemek elrendezése”, például karakterek, vonalak, egyéb formák stb.,, hogy “rögzítse a dokumentum teljes információtartalmát” (35.oldal). A dokumentum szerkezete ezen elemek gyűjteményét tartalmazza, minden elem pedig más elemek alszerkezete lehet.
problémák és korlátok
- a szöveget és a grafikát ugyanúgy kell kezelni (vagyis a grafika nem a szöveg származtatott példánya, sem fordítva)
- a megvalósításnak ugyanúgy kell kezelnie a komplex és egyszerű struktúrákat. Nem kell tudnia a kettő közötti különbséget.,
- az absztrakt elemek specifikus származékainak speciális analitikai elemekkel kell rendelkezniük.
megoldás és minta
a rekurzív összetétel az elemek hierarchikus szerkezete, amely “egyre összetettebb elemeket épít ki az egyszerűbbekből” (PP.36). A szerkezet minden csomópontja ismeri saját gyermekeit és szüleit. Ha egy műveletet az egész szerkezeten kell végrehajtani, akkor minden csomópont a gyermekeire hívja a műveletet (rekurzívan).
Ez az összetett minta megvalósítása, amely csomópontok gyűjteménye., A csomópont absztrakt alaposztály, a származékok lehetnek levelek (egyes szám), vagy más csomópontok gyűjteményei (amelyek viszont tartalmazhatnak leveleket vagy gyűjteménycsomópontokat). Ha egy műveletet a szülőn hajtanak végre, ez a művelet rekurzív módon átadja a hierarchiát.
FormattingEdit
a formázás eltér a struktúrától. A formázás egy módszer a dokumentum fizikai szerkezetének egy adott példányának felépítésére. Ez magában foglalja a szöveg sorokra bontását, kötőjelek használatával, a margó szélességének beállításával stb.,
problémák és korlátok
- egyensúly a (formázás) minőség, sebesség és tárhely között
- tartsa a formázást független (nem csoportosítva) a dokumentumstruktúrától.
megoldás és minta
egy kompozit osztály a kompozíció formázásához használt algoritmust foglalja magába. A Compositor a dokumentum struktúrájának primitív objektumának alosztálya. A Kompozitornak van egy Kompozícióobjektum társított példánya., Amikor a Kompozitor fut a Compose()
, akkor iterálja át minden eleme a kapcsolódó készítmény, és átrendezi a szerkezet behelyezésével sor és oszlop objektumokat, ha szükséges.
maga a Kompozitor egy absztrakt osztály, amely lehetővé teszi a származékos osztályok számára, hogy különböző formázási algoritmusokat használjanak (például kettős távolság, szélesebb margók stb.)
A stratégia mintáját használják e cél eléréséhez. A stratégia egy olyan módszer, amely több algoritmust tartalmaz, amelyeket változó kontextus alapján kell használni., Ebben az esetben a formázásnak másnak kell lennie, attól függően, hogy szöveg, grafika, egyszerű elemek stb., vannak formázva.
A felhasználói felület díszítése
a felhasználó által a dokumentummal való interakcióhoz használt grafikus felület megváltoztatásának képessége.,
a Problémák, Korlátok
- Kijelölni egy oldalnyi szöveget egy határ körül a szerkesztési terület
- görgetősávok, hogy a felhasználó tekintse meg a különböző részein a oldal
- Felhasználói felület a tárgyak nem tudom, a díszítmények
- Elkerülni egy “robbanás osztályok” lenne által okozott subclassing a “minden lehetséges kombinációt díszítmények” elemek (p. 44)
a Megoldást, Minta
A használata egy átlátszó burkolat lehetővé teszi az elemek, hogy fokozza az a viselkedés, a kompozíció, hogy ki a kompozíció., Ezek az elemek, mint például a Border and Scroller, a szinguláris elem speciális alosztályai. Ez lehetővé teszi a kompozíció kibővítését, hatékonyan hozzáadva az állapotszerű elemeket. Mivel ezek az augmentációk a szerkezet részét képezik, a megfelelő Operation()
akkor kerül meghívásra, amikor a szerkezet Operation()
neve. Ez azt jelenti, hogy az ügyfélnek nincs szüksége speciális ismeretekre vagy interfészre a szerkezettel a díszítések használatához.,
Ez egy dekorációs minta, amely feladatokat ad egy objektumhoz anélkül, hogy maga az objektum módosítaná.
támogatása több Look-and-Feel Szabványokszerkesztés
Look-and-feel utal platform-specifikus UI szabványoknak. Ezek a szabványok “iránymutatásokat határoznak meg az alkalmazások megjelenésére és a felhasználóra való reagálásra vonatkozóan” (47.oldal).
problémák és korlátok
- a szerkesztőnek több platformra vonatkozó szabványokat kell végrehajtania, hogy hordozható legyen
- könnyen alkalmazkodjon az új és megjelenő szabványokhoz
- lehetővé tegye a futási idő megváltoztatását (pl.,: No hard-coding)
- van egy sor absztrakt elemi alosztályok minden kategóriában elemek(görgetősáv, gombok, stb .. )
- van egy sor konkrét alosztályok minden absztrakt alosztály, hogy lehet egy másik look-and-feel szabvány. (ScrollBar having MotifScrollBar and PresentationScrollBar for Motif and Presentation look-and-feels)
Solution and Pattern
mivel az objektum létrehozása különböző konkrét objektumok nem lehet tenni futásidőben, az objektum létrehozásának folyamatát ki kell vonni., Ez egy absztrakt guiFactory-val történik, amely vállalja az UI elemek létrehozásának felelősségét. Az absztrakt guiFactory konkrét megvalósításokkal rendelkezik, mint például a MotifFactory, amely a megfelelő típusú konkrét elemeket hozza létre (MotifScrollBar). Ily módon a programnak csak egy görgetősávot kell kérnie, futásidőben pedig a megfelelő konkrét elemet kell megadnia.
Ez egy absztrakt gyár. A rendszeres gyár egy típusú konkrét tárgyakat hoz létre. Az absztrakt gyár különböző típusú konkrét objektumokat hoz létre, a gyár konkrét megvalósításától függően., Az a képesség, hogy ne csak konkrét tárgyakra összpontosítson, hanem a konkrét tárgyak egész családjaira “megkülönbözteti azt a többi kreatív mintától, amelyek csak egyfajta terméktárgyat tartalmaznak” (51.oldal).
több ablakrendszer Támogatásaszerkesztés
ugyanúgy, mint a look-and-feel különböző platformokon, így a Windows kezelésének módja is. Minden platform megjeleníti, meghatározza, kezeli bemenet és kimenet, és rétegek ablakok másképp.,
problémák és kényszerek
- a dokumentumszerkesztőnek számos létező “fontos és nagyrészt inkompatibilis ablakrendszeren” kell futnia (p. 52)
- egy absztrakt gyár nem használható. Mivel a különböző szabványok, nem lesz egy közös absztrakt osztály minden típusú widget.
- ne hozzon létre új, nem szabványos ablakos rendszert
megoldás és minta
lehetséges a “saját absztrakt és konkrét termékosztályaink” fejlesztése, mivel “az összes ablakrendszer általában ugyanazt teszi” (52. o.)., Minden ablakrendszer primitív alakzatok rajzolásához, ikonizáláshoz/ikonizáláshoz, átméretezéshez és az ablak tartalmának frissítéséhez nyújt műveleteket.
egy absztrakt bázis Window
osztály származtatható a különböző típusú meglévő ablakok, például alkalmazás, ikonosított, párbeszédablak. Ezek az osztályok olyan műveleteket tartalmaznak, amelyek a Windowshoz kapcsolódnak, mint például az átformálás, a grafikusan frissítő stb. Minden ablak olyan elemeket tartalmaz, amelyekDraw()
függvényeit aWindow
saját rajzolással kapcsolatos funkciói hívják fel.,
annak elkerülése érdekében, hogy platformspecifikus ablak alosztályokat kell létrehozni minden lehetséges platformon, egy interfész kerül felhasználásra. AWindow
osztály egyWindow
implementációt hajt végre (WindowImp
) absztrakt osztály. Ez az osztály ezután több platformspecifikus implementációvá válik, amelyek mindegyike platformspecifikus műveletekkel rendelkezik., Ezért a Window
osztályok mindegyik típusához csak egy sor Window
osztály szükséges, és minden egyes platformhoz csak egy sor WindowImp
osztály szükséges (az összes rendelkezésre álló típus és platform Karteziai terméke helyett). Ezenkívül egy új ablaktípus hozzáadása nem igényli a platform megvalósításának módosítását, vagy fordítva.
Ez egy Hídminta. Window
és WindowImp
különböző, de rokon., Window
a Program ablakokkal foglalkozik, és WindowImp
a platformon történő ablakozással foglalkozik. Az egyik megváltozhat anélkül, hogy valaha módosítania kellene a másikat. A Hídmintázat lehetővé teszi, hogy ez a két “különálló osztály hierarchiák együtt működjenek, még akkor is, ha önállóan fejlődnek” (54. oldal).
felhasználói Műveletekszerkesztés
minden olyan művelet, amelyet a felhasználó elvégezhet a dokumentummal, a szöveg beírásától, a formázás megváltoztatásától, a kilépéstől, a mentéstől stb.,
a Problémák, Korlátok
- Műveletek kell eltérõ bemenet, például a menü lehetőséget, majd egy billentyűparancsot ugyanarra a parancs
- Minden lehetőség van egy felület, amely módosítható
- Műveletek végrehajtása több különböző osztályok
- annak érdekében, hogy elkerüljék a csatlakozó, ott nem kell sok függőségek között végrehajtása, valamint a felhasználói felület osztályok.,
- Undo és redo parancsokat kell támogatni a legtöbb dokumentum változó műveletek, nincs önkényes korlátozást a szintek száma undo
- funkciók nem életképes, mivel nem vonja vissza/újra könnyen, nem könnyen társítható egy állam, és nehéz kiterjeszteni vagy újra.
- a menüket hierarchikus összetett struktúraként kell kezelni. Ezért a menü egy menüpont, amely menüelemeket tartalmaz, amelyek más menüelemeket is tartalmazhatnak stb.,
megoldás és minta
minden menüpont, ahelyett, hogy a paraméterek listájával példányosítanák, ehelyett egy Parancsobjektummal történik.
parancs egy absztrakt objektum, amely csak egyetlen absztrakt Execute()
módszerrel rendelkezik. A derivatív objektumok a Execute()
metódust megfelelő módon kiterjesztik (azaz a PasteCommand.Execute()
A tartalom vágólap pufferét használja). Ezeket az objektumokat a widgetek vagy gombok ugyanolyan könnyen használhatják, mint a menüpontok.,
a visszavonás és újratervezés támogatásához Command
Unexecute()
és Reversible()
. A derivatív osztályokban az előbbi olyan kódot tartalmaz, amely visszavonja ezt a parancsot, az utóbbi pedig logikai értéket ad vissza, amely meghatározza, hogy a parancs visszavonhatatlan-e. Reversible()
lehetővé teszi, hogy egyes parancsok nem visszavonhatók legyenek, például egy mentési parancs.
az összes végrehajtott Commands
egy listában tárolódnak, amelynek módja a” jelen ” jelölő közvetlenül a legutóbb végrehajtott parancs után tartása., A visszavonási kérelem a Command.Unexecute()
– t közvetlenül a “jelen” előtt hívja, majd a “jelen” vissza egy parancsot. Ezzel szemben aRedo
kérés aCommand.Execute()
“present” után hívja a “present” – et, és a “present” – et előre mozgatja.
Ez a Command
megközelítés a Parancsminta végrehajtása. A kéréseket objektumokba ágyazza, és egy közös felületet használ a kérések eléréséhez. Így az ügyfél képes kezelni a különböző kéréseket, a parancsok pedig szétszóródhatnak az egész alkalmazásban.,
Helyesírás-ellenőrzés és Elválasztásszerkesztés
Ez a dokumentumszerkesztő azon képessége, hogy szövegesen elemezze a dokumentum tartalmát. Bár sok elemzés elvégezhető, helyesírás-ellenőrzés és elválasztás-a formázás a hangsúly.
a Problémák, Korlátok
- Lehetővé teszi a többféle módon, hogy a helyesírás-ellenőrzés, illetve azonosítani helyek elválasztás
- megdagadjon a későbbi elemzés (pl. szavak száma, nyelvtan ellenőrzés)
- Legyen képes halad végig a szöveges tartalmát anélkül, hogy a szöveg általában a szerkezet (pl.,, array, linked list, string)
- lehetővé teszi a dokumentum bármilyen áthaladását (elejétől a végéig, a végéig, ábécé sorrendben stb.)
megoldás és minta
az egész alapú index eltávolítása az alapelemből lehetővé teszi egy másik iterációs felület megvalósítását. Ehhez további módszerekre lesz szükség a keresztirányú és az objektum visszakereséséhez. Ezek a módszerek kerülnek egy absztrakt Iterator
interfész., Ezután minden elem végrehajtja a Iterator
származtatását, attól függően, hogy az elem hogyan tartja a listáját (ArrayIterator
, LinkListIterator
stb.).
a keresztirányú és visszakeresési funkciók az absztrakt Iterátor interfészbe kerülnek. A jövőbeli iterátorok származtathatók azon lista típusa alapján, amelyen keresztül iterálódnak, például tömbök vagy kapcsolt listák. Így, függetlenül attól, hogy milyen típusú indexelési módszert alkalmaz az elem bármely megvalósítása, megfelelő Iterátorral rendelkezik.
Ez az Iterátor minta megvalósítása., Ez lehetővé teszi, hogy az ügyfél áthalad minden olyan tárgy, gyűjtemény, anélkül, hogy belépjen a tartalmát a gyűjtemény közvetlenül, vagy aggódik a típusú listát a gyűjtemény szerkezetét használja.
most, hogy a traversal kezelése megtörtént, lehetőség van egy struktúra elemeinek elemzésére. Nem kivitelezhető, hogy az egyes típusú elemzéseket maguk építsék be az elemszerkezetbe; minden elemet kódolni kell, és a kód nagy része azonos lenne a hasonló elemeknél.
ehelyett egy általános CheckMe()
módszer van beépítve az elem absztrakt osztályába., Minden Iterátor egy adott algoritmusra utal (például helyesírás-ellenőrzés, nyelvtan-ellenőrzés stb.).). Amikor ez az Iterátor a gyűjteményén keresztül iterálódik, minden elem CheckMe
– nak hívja, átadva a megadott algoritmust. CheckMe
ezután átadja az elemre való hivatkozást az említett elemzési algoritmushoz.
így egy helyesírás-ellenőrzés elvégzéséhez egy front-to-end iterátor hivatkozást kap egy SpellCheck
objektumra., Az iterátor ezután hozzáférne minden elemhez, végrehajtva CheckMe()
metódusát a SpellCheck
paraméterrel. Mindegyik CheckMe
ezután hívja a SpellCheck
hivatkozást a megfelelő elemre.
ilyen módon bármilyen algoritmus használható bármilyen keresztirányú módszerrel, anélkül, hogy a kemény kód összekapcsolódna egymással. Például a Find lehet használni, mint” find next “vagy” find previous”, attól függően, hogy egy” forward “iterátor használták, vagy egy” visszafelé ” iterátor.,
ezenkívül maguk az algoritmusok felelősek a különböző elemek kezeléséért. Például egySpellCheck
algoritmus figyelmen kívül hagyná aGraphic
elemet, ahelyett, hogy mindenGraphic
-származtatott elemet be kellene programozni, hogy ne küldjék magukatSpellCheck
.