Mantenere traccia dello stato di un oggetto

Normalmente inserirò le responsabilità per i processi di creazione complessi e i loro stati di tracciamento in un oggetto separato come CarBuilder . Ma per ragioni di dimostrazione, lascia che queste proprietà facciano parte di un Car .

lets say I wanted to keep track of a car being build. It could can a status of "Paint job completed".

Una proprietà di base di un'auto potrebbe essere il suo Color (con un valore speciale None per le auto non verniciate). Quindi uno stato come "Dipingi lavoro completato" è già una proprietà derivata e uno stato booleano PaintJobCompleted può essere simile a questo:

          public bool PaintJobCompleted
          {
              get{return Color!=Color.None;}
          }

(Come ho scritto, questa proprietà è IMHO meglio posizionata in CarBuilder , poiché un oggetto auto non dovrebbe sapere che c'è un "lavoro di pittura" coinvolto per renderlo colorato, ma lascia ignorarlo).

But from a different perspective, this status could also be considered "Ready for assembly"

Supponiamo che "pronto per l'assemblaggio" coinvolga l'auto dipinta e le ruote disponibili e WheelsAvailable sia un'altra proprietà booleana. La dipendenza tra questi stati porta quindi a una proprietà come questa:

 public bool ReadyForAssembly
 {
    get{return PaintJobCompleted && WheelsAvailable;}
 }

Or from a sales perspective, it would be "In production".

Diciamo che una macchina ha una serie di ruote e quando quella matrice non è nulla, le ruote sono assemblate.

 Wheel[] wheelsArray;
 public bool WheelsInPlace
 {
    get{return wheelsArray!=null}
 }

"In produzione" può essere vero finché l'auto non è verniciata e le ruote non sono al loro posto:

 public bool InProduction
 {
    get{return ! (PaintJobJobCompleted && WheelsInPlace);}
 }

Quindi spero che ti venga l'idea:

• fare una chiara distinzione tra proprietà di base (o attributi dell'oggetto, che sono per lo più indipendenti dal processo), e proprietà derivate

• assegna solo lo spazio di archiviazione per quelle proprietà di base e codifica le regole di business per le proprietà derivate nella loro implementazione

Naturalmente, potrebbero esserci proprietà derivate con regole aziendali complesse in cui la memorizzazione interna (come cache) diventa necessaria per motivi di prestazioni. Ma consiglierei di evitarlo fino a quando non misurerai un impatto notevole sulle prestazioni.

Il problema qui è che hai tre proprietà per rappresentare un solo valore: non dovresti essere in grado di impostare indipendentemente lo "stato delle vendite" e lo "stato del reparto verniciatura", perché il primo dipende dal secondo. Invece, avere un'unica fonte di verità per lo stato e le diverse visualizzazioni su quello stato: ad esempio, lo "stato delle vendite" dovrebbe semplicemente restituire "ancora in produzione" o simile se lo stato sottostante si trova in uno degli stati che indicano il il lavoro di verniciatura è incompleto.

Sospetto che troverai che devi considerare lo stato come un albero piuttosto che un processo lineare, ma questo dipende dalla complessità del sistema che stai modellando.

Per quanto riguarda "necessita di attenzione manuale", questo probabilmente diventa un flag booleano e viene riflesso nella segnalazione dello stato di alto livello.