Processo decisionale e manutenzione

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.

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.