Madame Lelica

Il capitolo passa attraverso sette problemi che devono essere affrontati per progettare correttamente Lexi, inclusi eventuali vincoli che devono essere seguiti. Ogni problema viene analizzato in profondità e vengono proposte soluzioni., Ogni soluzione è spiegata per intero, incluso lo pseudo-codice e una versione leggermente modificata della tecnica di modellazione degli oggetti, se del caso.

Infine, ogni soluzione è associata direttamente a uno o più pattern di progettazione. Viene mostrato come la soluzione è un’implementazione diretta di quel modello di progettazione.

I sette problemi (inclusi i loro vincoli) e le loro soluzioni (inclusi i pattern a cui si fa riferimento), sono i seguenti:

Struttura del documentedit

Il documento è “una disposizione di elementi grafici di base” come caratteri, linee, altre forme, ecc.,, che “catturano il contenuto informativo totale del documento” (pp. 35). La struttura del documento contiene una raccolta di questi elementi e ogni elemento può a sua volta essere una sottostruttura di altri elementi.

Problemi e vincoli

1. Testo e grafica dovrebbero essere trattati allo stesso modo (cioè, la grafica non è un’istanza derivata di testo, né viceversa)
2. L’implementazione dovrebbe trattare le strutture complesse e semplici allo stesso modo. Non dovrebbe essere necessario conoscere la differenza tra i due.,
3. Derivati specifici di elementi astratti dovrebbero avere elementi analitici specializzati.

Soluzione e Pattern

Una composizione ricorsiva è una struttura gerarchica di elementi, che costruisce “elementi sempre più complessi da quelli più semplici” (pp. 36). Ogni nodo nella struttura conosce i propri figli e il suo genitore. Se un’operazione deve essere eseguita sull’intera struttura, ogni nodo chiama l’operazione sui suoi figli (ricorsivamente).

Questa è un’implementazione del modello composito, che è una raccolta di nodi., Il nodo è una classe base astratta e le derivate possono essere foglie (singolari) o raccolte di altri nodi (che a loro volta possono contenere foglie o nodi di raccolta). Quando viene eseguita un’operazione sul genitore, tale operazione viene trasmessa ricorsivamente nella gerarchia.

FormattingEdit

La formattazione differisce dalla struttura. La formattazione è un metodo per costruire una particolare istanza della struttura fisica del documento. Ciò include l’interruzione del testo in righe, l’uso di trattini,la regolazione delle larghezze dei margini, ecc.,

Problemi e vincoli

1. Equilibrio tra (formattazione) qualità, velocità e spazio di archiviazione
2. Mantenere la formattazione indipendente (disaccoppiata) dalla struttura del documento.

Soluzione e Pattern

Una classe Compositor incapsulerà l’algoritmo utilizzato per formattare una composizione. Compositor è una sottoclasse dell’oggetto primitivo della struttura del documento. A un Compositor è associata un’istanza di un oggetto Composition., Quando un compositore esegue il suo Compose(), itera ogni elemento della sua composizione associata e riorganizza la struttura inserendo oggetti di riga e colonna secondo necessità.

Il Compositore stesso è una classe astratta, che consente alle classi derivate di utilizzare diversi algoritmi di formattazione (come doppia spaziatura, margini più ampi, ecc.)

Il modello di strategia viene utilizzato per raggiungere questo obiettivo. Una strategia è un metodo per incapsulare più algoritmi da utilizzare in base a un contesto che cambia., In questo caso, la formattazione dovrebbe essere diversa, a seconda che testo, grafica, elementi semplici, ecc., sono formattati.

Abbellire l’interfaccia utentemodifica

La possibilità di modificare l’interfaccia grafica che l’utente utilizza per interagire con il documento.,

Problemi e Vincoli

1. Demarcare una pagina di testo con un bordo intorno all’area di modifica
2. barre di Scorrimento che consentono all’utente di visualizzare le diverse parti della pagina
3. oggetti dell’interfaccia Utente non deve conoscere gli abbellimenti
4. Evitare di “un’esplosione di classi” che potrebbe essere causato da una sottoclasse di “ogni possibile combinazione di abbellimenti” e gli elementi (p. 44)

la Soluzione e Pattern

L’uso di una custodia trasparente consente di elementi che aumentano il comportamento di composizione per essere aggiunto ad una composizione., Questi elementi, come Border e Scroller, sono sottoclassi speciali dell’elemento singolare stesso. Ciò consente di aumentare la composizione, aggiungendo efficacemente elementi di stato. Poiché questi aumenti fanno parte della struttura, il loro Operation() appropriato verrà chiamato quando viene chiamato Operation() della struttura. Ciò significa che il cliente non ha bisogno di alcuna conoscenza speciale o interfaccia con la struttura per utilizzare gli abbellimenti.,

Questo è un modello di Decoratore, uno che aggiunge responsabilità a un oggetto senza modificare l’oggetto stesso.

Supporto di più standard di Look-and-Feeledit

Look-and-feel si riferisce a standard UI specifici della piattaforma. Questi standard “definiscono le linee guida per il modo in cui le applicazioni appaiono e reagiscono all’utente” (pp. 47).

Problemi e vincoli

1. L’editor deve implementare gli standard di più piattaforme in modo che sia portatile
2. Adattarsi facilmente a standard nuovi ed emergenti
3. Consentire il cambio di runtime di look-and-feel (cioè,: No hard-coding)
4. Hanno un insieme di sottoclassi elementari astratte per ogni categoria di elementi (barra di scorrimento, pulsanti, ecc.)
5. Hanno un insieme di sottoclassi concrete per ogni sottoclasse astratta che può avere uno standard di aspetto e sensazione diverso. (ScrollBar con MotifScrollBar e PresentationScrollBar per Motif e Presentation look-and-feels)

Soluzione e Pattern

Poiché la creazione di oggetti di diversi oggetti concreti non può essere eseguita in fase di esecuzione, il processo di creazione dell’oggetto deve essere astratto., Questo viene fatto con una guiFactory astratta, che si assume la responsabilità di creare elementi dell’interfaccia utente. L’abstract guiFactory ha implementazioni concrete, come MotifFactory, che crea elementi concreti del tipo appropriato (MotifScrollBar). In questo modo, il programma deve solo chiedere una barra di scorrimento e, in fase di esecuzione, verrà fornito l’elemento concreto corretto.

Questa è una fabbrica astratta. Una fabbrica regolare crea oggetti concreti di un tipo. Una fabbrica astratta crea oggetti concreti di vario tipo, a seconda dell’implementazione concreta della fabbrica stessa., La sua capacità di concentrarsi non solo su oggetti concreti, ma su intere famiglie di oggetti concreti “lo distingue da altri modelli creazionali, che coinvolgono solo un tipo di oggetto prodotto” (pp. 51).

Supporto di più finestre SystemsEdit

Proprio come look-and-feel è diverso tra le piattaforme, così è il metodo di gestione di windows. Ogni piattaforma visualizza, espone, gestisce l’input e l’output da e mette a strati le finestre in modo diverso.,

Problemi e vincoli

1. L’editor di documenti deve essere eseguito su molti dei “sistemi di finestre importanti e in gran parte incompatibili” esistenti (p. 52)
2. Non è possibile utilizzare una fabbrica astratta. A causa di standard diversi, non ci sarà una classe astratta comune per ogni tipo di widget.
3. Non creare un nuovo sistema di finestre non standard

Soluzione e Pattern

È possibile sviluppare “le nostre classi di prodotti astratti e concreti”, perché “tutti i sistemi di finestre fanno generalmente la stessa cosa” (p. 52)., Ogni sistema di finestre fornisce operazioni per disegnare forme primitive, iconificare / de-iconificare, ridimensionare e aggiornare il contenuto della finestra.

Una base astrattaWindow classe può essere derivata per i diversi tipi di finestre esistenti, come applicazione, iconificato, finestra di dialogo. Queste classi conterranno operazioni associate a Windows,come rimodellamento, aggiornamento grafico, ecc. Ogni finestra contiene elementi, le cui funzioni Draw() sono richiamate dalle funzioni relative al draw di Window.,

Per evitare di dover creare sottoclassi di finestre specifiche della piattaforma per ogni piattaforma possibile, verrà utilizzata un’interfaccia. La classeWindow implementerà una classe astrattaWindow (WindowImp). Questa classe verrà quindi a sua volta derivata in più implementazioni specifiche della piattaforma, ciascuna con operazioni specifiche della piattaforma., Quindi, solo un set di Window classi sono necessari per ogni tipo di Window, e solo un set di WindowImp classi sono necessari per ogni piattaforma (piuttosto che il prodotto cartesiano di tutti i tipi e piattaforme disponibili). Inoltre, l’aggiunta di un nuovo tipo di finestra non richiede alcuna modifica dell’implementazione della piattaforma o viceversa.

Questo è un modello di ponte. Window e WindowImp sono diversi, ma correlati., Windowsi occupa di finestre nel programma eWindowImp si occupa di finestre su una piattaforma. Uno di loro può cambiare senza mai dover modificare l’altro. Il modello Bridge consente a queste due “gerarchie di classi separate di lavorare insieme anche se si evolvono indipendentemente” (p. 54).

User OperationsEdit

Tutte le azioni che l’utente può intraprendere con il documento, che vanno dall’immissione di testo, modifica della formattazione, uscita, salvataggio, ecc.,

Problemi e Vincoli

1. le Operazioni devono essere accessibili attraverso diversi ingressi, come un’opzione di menu e tasti di scelta rapida per il comando stesso
2. Ogni opzione ha un interfaccia, che dovrebbe essere modificabile
3. Operazioni attuate in diverse classi
4. al fine di evitare l’accoppiamento, non ci deve essere un sacco di dipendenze tra attuazione e l’interfaccia utente classi.,
5. I comandi Undo e redo devono essere supportati nella maggior parte delle operazioni di modifica dei documenti, senza limiti arbitrari sul numero di livelli di undo
6. Le funzioni non sono praticabili, poiché non annullano / ripetono facilmente, non sono facilmente associate a uno stato e sono difficili da estendere o riutilizzare.
7. I menu devono essere trattati come strutture composite gerarchiche. Quindi, un menu è una voce di menu che contiene voci di menu che possono contenere altre voci di menu, ecc.,

Soluzione e Pattern

Ogni voce di menu, anziché essere istanziata con un elenco di parametri, viene invece eseguita con un oggetto Comando.

Comando è un oggetto astratto che ha solo un singolo abstract Execute() metodo. Gli oggetti derivati estendono il metodoExecute() in modo appropriato (cioè, ilPasteCommand.Execute() utilizzerebbe il buffer degli appunti del contenuto). Questi oggetti possono essere utilizzati da widget o pulsanti con la stessa facilità con cui possono essere utilizzati dalle voci di menu.,

Per supportare undo e redo,Commandviene fornito ancheUnexecute()eReversible(). Nelle classi derivate, la prima contiene codice che annullerà quel comando e la seconda restituisce un valore booleano che definisce se il comando è annullabile. Reversible() consente di non annullare alcuni comandi, ad esempio un comando di salvataggio.

Tutti gli eseguiti Commands sono tenuti in una lista con un metodo per mantenere un marcatore “presente” direttamente dopo il comando eseguito più di recente., Una richiesta di annullamento chiamerà Command.Unexecute() direttamente prima di” present”, quindi sposta” present ” indietro di un comando. Viceversa, una richiestaRedo chiameràCommand.Execute() dopo “presente” e sposta “presente” in avanti uno.

Questo approccio Command è un’implementazione del modello di comando. Incapsula le richieste negli oggetti e utilizza un’interfaccia comune per accedere a tali richieste. Pertanto, il client può gestire richieste diverse e i comandi possono essere sparsi in tutta l’applicazione.,

Controllo ortografico e SillabazionEdit

Questa è la capacità dell’editor di documenti di analizzare testualmente il contenuto di un documento. Anche se ci sono molte analisi che possono essere eseguite, controllo ortografico e sillabazione-formattazione sono al centro.

Problemi e vincoli

1. Consentono più modi per controllare l’ortografia e identificare i luoghi per la sillabazione
2. Consentono l’espansione per l’analisi futura (ad esempio, conteggio delle parole, controllo grammaticale)
3. Essere in grado di scorrere il contenuto di un testo senza accesso alla struttura effettiva del testo (ad esempio,, array, elenco collegato, stringa)
4. Consentono qualsiasi tipo di attraversamento del documento (dall’inizio alla fine, dalla fine all’inizio, ordine alfabetico, ecc.)

Soluzione e Pattern

La rimozione dell’indice basato su interi dall’elemento base consente di implementare una diversa interfaccia di iterazione. Ciò richiederà metodi aggiuntivi per l’attraversamento e il recupero degli oggetti. Questi metodi vengono inseriti in un’interfaccia astratta Iterator., Ogni elemento implementa quindi una derivazione di Iterator, a seconda di come tale elemento mantiene la sua lista (ArrayIterator, LinkListIterator, ecc.).

Le funzioni per l’attraversamento e il recupero vengono inserite nell’interfaccia iteratore astratta. Gli iteratori futuri possono essere derivati in base al tipo di elenco che eseguiranno, ad esempio array o elenchi collegati. Pertanto, indipendentemente dal tipo di metodo di indicizzazione utilizzato da qualsiasi implementazione dell’elemento, avrà l’iteratore appropriato.

Questa è un’implementazione del modello Iteratore., Consente al client di attraversare qualsiasi raccolta di oggetti, senza dover accedere direttamente al contenuto della raccolta, o essere preoccupato per il tipo di elenco utilizzato dalla struttura della raccolta.

Ora che l’attraversamento è stato gestito, è possibile analizzare gli elementi di una struttura. Non è fattibile costruire ogni tipo di analisi nella struttura degli elementi stessi; ogni elemento dovrebbe essere codificato e gran parte del codice sarebbe lo stesso per elementi simili.

Invece, un metodo genericoCheckMe() è incorporato nella classe astratta dell’elemento., Ad ogni iteratore viene dato un riferimento a un algoritmo specifico (come controllo ortografico, controllo grammaticale, ecc.). Quando l’iteratore itera attraverso la sua collezione, chiama ogni elemento CheckMe, passando l’algoritmo specificato. CheckMe passa quindi un riferimento al suo elemento a detto algoritmo per l’analisi.

Quindi, per eseguire un controllo ortografico, a un iteratore front-to-end verrebbe dato un riferimento a un oggettoSpellCheck., L’iteratore accederebbe quindi a ciascun elemento, eseguendo il suo metodoCheckMe() con il parametroSpellCheck. Ogni CheckMechiamerebbe quindiSpellCheck, passando un riferimento all’elemento appropriato.

In questo modo, qualsiasi algoritmo può essere utilizzato con qualsiasi metodo traversal, senza che il codice rigido si accoppi l’uno con l’altro. Ad esempio, Find può essere utilizzato come “trova successivo” o “trova precedente”, a seconda se è stato utilizzato un iteratore “avanti” o un iteratore “indietro”.,

Inoltre, gli algoritmi stessi possono essere responsabili della gestione di diversi elementi. Ad esempio, un algoritmoSpellCheck ignorerebbe un elementoGraphic, piuttosto che dover programmare ogni elemento derivato daGraphicper non inviare se stessi a unSpellCheck.