Esiste un nome per questo uso del modello di progettazione dello stato?

Question

Esiste un nome per questo uso del modello di progettazione dello stato?

#1 da (3 voti)

1

Sto cercando di vedere se esiste un nome particolare per questo stile di programmazione di un certo tipo di comportamento in un programma.

Detto programma viene eseguito in tempo reale, in un ciclo di aggiornamento, e il programma usa il modello di progettazione State per fare un po 'di lavoro, ma è il modo specifico in cui fa il lavoro che voglio sapere.

Ecco come viene utilizzato.

- Object Foo constructed, with concrete StateA object in it
- First loop runs
--- Foo.Run function calls StateA.Bar
--- in StateA.Bar replace Foo's state to StateB
- Second loop runs
--- Foo.Run calls StateB.Bar
- Third loop runs
--- Foo.Run calls StateB.Bar
- Fourth loop
--- etc.

Quindi, in breve, Foo non ha una funzione Initialize esplicita. Avrà solo Run , ma Run farà qualcosa di unico nel primo fotogramma per inizializzare qualcosa per Foo e quindi sostituirlo con un'azione diversa che si ripeterà in tutti i fotogrammi successivi, quindi non è necessario controllare se Foo è già inizializzato. È solo un'azione "premi start and go".

Come definiresti implementare questo tipo di comportamento?

design-patterns terminology

posta Chris C 29.08.2012 - 19:37

fonte

1 risposta

Leggi altre domande sui tag design-patterns terminology

Sencha Ext JS licenza di runtime Come gestire richieste frequenti di ajax nel carrello

score 3 · Answer 1

Lo chiamerei inizializzazione pigra implementato usando modello di stato :

...lazy initialization is the tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed.

This is typically accomplished by maintaining a flag indicating whether the process has taken place. Each time the desired object is summoned, the flag is tested. If it is ready, it is returned. If not, it is initialized on the spot.

See lazy evaluation for a general treatment of this idea. In heavily imperative languages this pattern carries hidden dangers, as does any programming habit that relies on shared state...