parser simile a SAX: come si chiama questo modello?

Question

parser simile a SAX: come si chiama questo modello?

#1 da (3 voti)
#2 da (1 voti)

5

Ho scritto un parser per un certo tipo di file binario con struttura ricorsiva. Ho fatto la sua API per essere simile a SAX, cioè:

il parser accetta un oggetto di un'interfaccia specifica,
questa interfaccia ha diversi metodi chiamati come avviene l'analisi: startFoo(type, name) , endFoo() , datum(type, name, value) , badEntry(errorMsg) , ecc.
ci sono alcune promesse su come vengono chiamati questi callback: ad es. per ogni startFoo ci sarà un endFoo , con nidificazione appropriata, ecc.

Ero solito pensare che questa sia una variante di un pattern Visitor. Tuttavia, il pattern visitor non ha più callback, questi callback hanno argomenti diversi e il pattern Visitor non parla di promesse come nell'ultimo punto. Inoltre, in senso stretto, non è una struttura di dati in memoria che viene ripetuta, ma suppongo che questa parte sia meno importante ...

Penso anche che non sia strettamente un modello di Osservatore: non c'è stato da osservare; nessuna registrazione tardiva per la ricezione di eventi (ovvero si ottengono tutti gli eventi di analisi o nessuno, non è possibile iniziare nel mezzo); solo un singolo oggetto è accettato.

Esiste un nome più appropriato per questo modello di progettazione?

EDIT: A quanto ho capito, esistono schemi di progettazione per comunicare in modo rapido e preciso strutture di codice comuni. Tuttavia, se tutto quello che posso dire sulla struttura del codice di cui sopra è che si tratta di un modello di "Strategia" o di un modello di "Osservatore", la comunicazione è inefficiente. Non tutte le implementazioni di pattern "Strategiche" hanno interfacce con più metodi con promesse riguardanti l'ordine in cui sono chiamate, ecc.

Sto cercando un nome o una frase che possa comunicare direttamente l'insieme di condizioni sopra menzionate, o almeno alcune approssimazioni ravvicinate.

design-patterns parsing visitor-pattern

posta liori 17.01.2017 - 00:40

fonte

2 risposte

Leggi altre domande sui tag design-patterns parsing visitor-pattern

Dato un set di chip VLSI, come posso determinare quali sono buoni? Dove si trova l'elaborazione del modulo in un'applicazione MVC?

score 3 · Answer 1

Questo è un esempio del Modello di strategia . La libreria fornisce un parser generico che richiama la strategia di analisi fornita dall'utente, che consente al parser di evitare di mantenere lo stato non necessario. Le ulteriori garanzie relative alla sequenza di invocazioni del metodo sono solo una parte dell'interfaccia che non può essere espressa all'interno del sistema di tipi come firma del metodo.

L'intenzione del modello di stato è diversa: Permettere ad un oggetto di cambiare il suo comportamento quando il suo stato cambia, senza condizionali eccessivi. A tal fine, ogni stato è rappresentato da una sottoclasse separata. Un wrapper contiene l'oggetto stato corrente e può cambiare lo stato. Qui, l'API parser non ha la possibilità di modificare i callback. Tuttavia, la strategia delle forniture può utilizzare internamente il modello di stato.

L'intenzione del pattern del visitatore è diversa: Per aggiungere nuove operazioni a una gerarchia di classi senza modificare tali classi. La caratteristica che definisce è un approccio a doppia spedizione che equivale a un downcast sicuro. Qui, sembra che non ci sia una gerarchia di classi che richiederebbe un visitatore. Tuttavia, il parser o la strategia possono utilizzare un visitatore internamente per gestire elementi diversi (ad esempio per reagire in modo diverso ai nodi testo, elemento e commento).

Questo è in qualche modo correlato al pattern osservatore , poiché la strategia di analisi viene notificata ogni volta che lo stato del parser cambia. Poiché non sembra esserci alcun supporto per la registrazione di più osservatori, quindi penso che la caratterizzazione come esempio del modello strategico sia più accurata. Tuttavia, questo parsing basato su callback che stai vedendo è assolutamente un tipo di analisi basata sugli eventi.

score 1 · Answer 2

Qualsiasi parser implementa in qualche modo una grande macchina a stati in cui gli stati dipendono dalla grammatica del langage parsed e dalla lettura del token lessicale, e in cui lo stato di trigger di input cambia.

Questo non significa che il parser usi uno schema di progettazione dello stato. È possibile implementare i parser utilizzando builder, factory e altri pattern. O nessun modello.

È interessante notare che l'oggetto ricevente implementa anche una macchina a stati: offre un'interfaccia e ci si aspetta che le sue funzioni vengano chiamate dal parser a seconda del suo stato (ad esempio End() dopo start() ). E la maggior parte delle chiamate potrebbe innescare alcuni cambiamenti di stato.

I callback aiutano in qualche modo l'oggetto a replicare gli stati del parser, che inoltra gli eventi di modifica dello stato.

Quindi a livello macro e in base all'intento, si implementa un modello di osservatore; Anche se l'interfaccia di aggiornamento del tuo osservatore è più complessa del tradizionale update() .