Non è la strategia che personalmente avrei scelto. Avrei definito i 7 stati e definito i 4 attributi come proprietà dell'oggetto dell'applicazione. È quindi necessario definire regole di business che si applicano all'applicazione in base a questi attributi che potrebbero applicare cambiamenti di stato all'applicazione.
Il vantaggio di questo approccio è che le regole aziendali aggiuntive sono implementate nel codice come regole aziendali aggiuntive che sono molto mantenibili.
Nel tuo progetto, stai codificando le regole aziendali nella macchina a stati, il che significa che nel tempo, con l'introduzione delle regole aziendali, la macchina a stati cresce e diventa completamente non-mantenibile.
Ad esempio:
public decide_next_state(IApplication application, Dictionary<state, List<IBusinessRules>> rules)
{
// by default we remain in the current state.
next_state = application.current_state
foreach(state in rules.keys())
{
bool matched = true;
foreach(rule in rules[state])
{
// if this business rule blocks the transition, then it
// returns false.
if rule.apply(application) == false
{
matched = false;
break;
}
}
if(matched == true)
{
next_state = state;
break;
}
}
return next_state;
}
Ora con questo codice, si passerebbe nel dizionario delle regole per lo stato attuale delle applicazioni. Le regole definiscono quindi a quale stato verrà passata l'applicazione corrente. Tuttavia, può eseguire questa transizione solo se tutte le regole aziendali per tale transizione lo consentono.
Questo è un modello molto semplice, ma può essere reso molto più complesso se necessario.