Il pattern di stato è un'architettura saggia per un'applicazione di diagrammi?

Question

Il pattern di stato è un'architettura saggia per un'applicazione di diagrammi?

#1 da (2 voti)

2

Sto progettando un'applicazione per il disegno vettoriale.

Ho bisogno di implemente copia e incolla, inserimento di forme, cancellazione e trasformazione pur essendo in grado di includere nuovi strumenti con facilità in futuro.

Per come la penso io, questa è una macchina a stati finiti, quindi ho pensato a un pattern di stato. Lo stadio si comporta in modo diverso in base al suo stato interno. Ogni stato sarebbe uno strumento.

var stage = new StageManager();

var insert = new InsertTool();
var copy = new CopyTool();
var paste = new PasteTool();
var select = new SelectTool();

stage.registerTool(insert);
stage.registerTool(copy);
stage.registerTool(paste);
stage.registerTool(select);

Se, per esempio, l'utente ha appena incollato una forma, StageManager passa alla modalità di selezione (SelectTool).

onMouseUp(event){
    this.stageManager.addShapes(this.stageManager.clipboard.getAll());

    // Just pasted, transition to selectionTool
    this.stageManager.chooseTool('selection-tool');
}

// From now on, stage behaves like a selectionTool.

È un'architettura saggia per un'app di diagrammi?

design-patterns finite-state-machine

posta motobói 10.09.2016 - 02:03

fonte

1 risposta

Leggi altre domande sui tag design-patterns finite-state-machine

Come dividere le versioni di sviluppo / staging / produzione di un'applicazione Richiama la logica del modello in un UserControl da view-model in un altro UserControl senza violare MVVM

score 2 · Answer 1

Penso che sia una buona architettura per cominciare. C'è un modo per gli stati di fare una transizione senza conoscere troppo l'uno dell'altro. Hanno solo bisogno di conoscere l'interfaccia e una chiave.

Suppongo che la tua lingua supporti le interfacce e che tutti gli strumenti implementino l'interfaccia dello strumento.

Crea costanti globali, una per ogni stato.
Quando registri gli stati lo fai in una raccolta di mappe / dizionari. Metti lo strumento e il suo "ID" nella mappa. In questo modo puoi recuperarli dalla mappa usando quella chiave (la costante corrispondente).
Ogni strumento ha una lista di possibili prossimi stati, che potrebbero avere zero, uno o più possibili "stati successivi" ai quali può passare. MA quella lista non contiene gli strumenti ma la loro chiave.
Quindi, all'interno dell'implementazione di ogni strumento, puoi decidere quale strumento passare e riceverli dal registro usando la loro chiave.

Questa risposta a un'altra domanda mostra il codice funzionante in Java di una macchina a stati in cui ogni stato passa al più appropiato "prossimo stato". L'esempio riguarda un'automobile il cui comportamento è modellato come una macchina a stati finiti. In questo esempio gli stati sono classi interne della classe che li contiene (come opossed to iniettato), e quindi hanno accesso alla collezione di stati (equivalente alla collezione di strumenti che hai in ToolManager quando registri gli strumenti. trovare un modo per fare la stessa cosa senza gli strumenti (che sono stati). Un modo è iniettare una richiamata negli strumenti quando li si registra in modo che possano ottenere l'istanza dello strumento di cui hanno bisogno per passare dalla collezione di registrati strumenti del gestore con la chiave corrispondente.

Se decidi le transizioni nel gestore, finirai con un if-then-else o switch-case pasticcio.

Al momento della registrazione puoi anche iniettare un oggetto di contesto (singoletti) negli strumenti in modo che possano accedere a quale colore è selezionato, ecc.

Inoltre, vorrai implementare lo schema di comando per supportare le operazioni di annullamento.