Processo decisionale e manutenzione

3

Sto cercando di trovare un modo elegante per implementare un algoritmo decisionale che consenta una facile manutenzione perché le condizioni per il processo decisionale potrebbero cambiare spesso.

Cercherò di essere più specifico con un esempio qui:

Diciamo che sto cercando di gestire un team di cuochi in cucina in un ristorante.

Ogni chef sa come cucinare 3 tipi di torte: torta di mele, torta di zucca e torta di lamponi e 2 tipi di pizza: pizza al formaggio e pizza al bacon. Sanno tutti come cucinare tutto.

Ora vorrei inviare ordini a questi capi riguardo a ciò che accadrà per i clienti.

Le condizioni sono:

Un capo può cucinare solo una torta alla volta. Se ordino ad uno chef di cucinare una torta di mele, ad esempio, non posso ordinargli di cucinare una torta di lamponi o una torta di zucca a meno che non sia stata fatta la torta di mele o mandare una richiesta di annullamento per la torta di mele.

Posso chiedere a uno chef di cucinare fino a 5 pizze alla volta, dato che è per clienti diversi.

Mi piacerebbe creare un algoritmo che restituisca l'insieme di ordini che posso inviare a uno chef specifico, riguardo a ciò che sta già cucinando.

Sto lavorando con c ++. Potrei scrivere una semplice istruzione switch / case, ma la manutenzione non sarebbe facile se le condizioni cambiano o vengono aggiunte nuove torte, e quindi ...

Sono piuttosto bloccato e non vedo come incapsulare le condizioni e il processo decisionale per ridurre l'accoppiamento tra le condizioni e consentire una facile manutenzione sulle condizioni di cottura della torta.

Come gestiresti un'implementazione complessa dell'algoritmo decisionale?

    
posta JeD 29.09.2014 - 11:38
fonte

2 risposte

1

I dati sono costituiti da Chefs , Orders e un singolo Schedule . Tieni presente che Chefs cambia raramente, ma Orders viene costantemente creato, rimosso e facoltativamente modificato e il Schedule deve cambiare in risposta.

La logica per il nuovo Schedule dipende in realtà da tutti i dati, tra cui Chefs , Orders e vecchio Schedule . Per questo motivo è davvero necessario mantenere la logica di pianificazione insieme in un'unica posizione, ad esempio una classe Scheduler .

L'utilizzo dello sviluppo basato su test è molto adatto a questo problema. Inizia scrivendo i test unitari per i casi semplici e poi crea quelli più complessi in cui Chefs ha già elementi nella coda e quindi i nuovi ordini entrano o vengono rimossi o modificati. Quindi nella tua classe Scheduler , scrivi la logica più semplice che puoi immaginare per esprimere le regole. Sei completamente libero di usare qualsiasi architettura o struttura interna che desideri. Non essere troppo complicato o complicato. Ogni volta che vedi un'opportunità per rendere la logica più semplice e comprensibile, fallo e assicurati che tutti i test siano ancora in corso.

Ora, quando si desidera apportare una modifica, si aggiunge un nuovo caso di test e si modificano i casi di test non più più corretti, quindi si modifica la logica di Scheduler finché tutti i test non passano di nuovo. In questo modo sai che non infrangerai le ipotesi o la logica esistenti.

L'ho usato con successo su diversi problemi simili.

    
risposta data 29.09.2014 - 17:48
fonte
0

Non riesco a vedere ciò che richiede un'istruzione switch. Ecco come progetterei questo. Avrei una sorta di controller o oggetto manager, che assegna compiti. Questo oggetto dovrebbe sapere

  • un elenco di chef
  • un metodo che puoi chiamare su uno chef, ad esempio "sei libero?"
  • un metodo che puoi chiamare per verificare se è in grado di cucinare qualcosa, supponendo che sia gratuito

Chiedete a questo oggetto "portami qualcuno a fare una torta di lamponi" e scorre attraverso gli chef finché non trova uno libero, chiede se può fare la torta di lamponi e, in caso affermativo, assegna ad esso.

Nel frattempo nell'oggetto dello chef devi sapere cosa sai cucinare, la tua capacità di ogni cosa e cosa stai cucinando in questo momento. Non stai cucinando nulla, ti viene chiesto se sei libero, dici di sì, ti viene dato qualcosa da cucinare, quindi tieni traccia di ciò, e se ti viene chiesto ancora prima che sia finito, dici di no.

Con la tua complicazione di una torta ma cinque pizze, potresti combinare le domande "sei libero" e "puoi cucinare" in "sei libero di cucinare X?" che diresti di no se è perché non sai come o perché sei occupato. In questo modo qualcuno con due pizze in movimento dirà di sì a una pizza ma no a una torta.

L'oggetto del cessionario deve anche capire che cosa farà se tutti gli chef dicono che sono occupati. Probabilmente aspettate e chiedete ancora una volta dato che gli chef finiranno ciò che stanno facendo e diventeranno gratuiti. Puoi farlo con pause e sondaggi o facendo in modo che gli chef segnalino l'assegnatario una volta che sono liberi.

La chiave per me è che gli chef sanno cosa e quanto tempo possono cucinare, non l'assegnatario. L'assegnatario sa quanti chef ci sono. Aggiungere nuove torte significa aggiornare la classe di chef (eventualmente solo una ricompilazione se l'elenco delle torte è un enumerazione e tutti gli chef possono sempre cucinare tutti i tipi di torta) e qualunque codice decida che è ora di fare torta al lampone ora. In generale, il codice assegnatario non dovrà essere modificato in queste circostanze: sta ancora scorrendo gli chef chiedendo "puoi fare una pizza al formaggio sì o no?" e se si ottiene si, assegnandolo allo chef e ritornando.

    
risposta data 29.09.2014 - 16:18
fonte

Leggi altre domande sui tag