Il nome di una nuova variabile di stato dovrebbe riflettere il contesto setter originale o l'uso previsto?

0

Spesso affronta questo problema quando arrivano nuovi requisiti, ma non l'ho mai visto discusso da nessuna parte. In questo caso, ho un elenco esistente di elementi (righi in una partitura musicale). Il requisito è che un utente possa aggiungere e rimuovere nuovi elementi, ma non è consentito rimuovere gli elementi originali. Quindi, come faccio a chiamare il nuovo stato memorizzato?

Una proprietà enum con valori Original e CreatedByUser riflette il contesto setter originale ed è potenzialmente utile in altre azioni come rinomina, copia, ecc. In genere aggiungerei anche una proprietà di sola lettura isDeletable che fa riferimento all'enumerazione.

Una proprietà bool di tipo boolea riflette il nuovo requisito e potenzialmente consente ad altri contesti di impostare il valore in base a ulteriori requisiti.

È uno migliore dell'altro? Esistono collegamenti che descrivono o discutono meglio questa dualità delle variabili di stato?

    
posta Tony Rietwyk 06.01.2018 - 05:26
fonte

1 risposta

2

Direi che il tuo dilemma è tra Dati e Logica.

Note.State è dati, non cambierà a meno che la nota non cambi

Note.IsDeletable() è logica. Può cambiare gli straordinari quando cambiano i requisiti.

Questo è un buon argomento contro programmazione orientata agli oggetti perché IsDeletable ha solo significato nel contesto dell'applicazione MusicEditor.

Se ho un'altra applicazione (o parte di una grande applicazione), ad esempio MusicPlayer, con le stesse note i dati della nota hanno ancora senso, ma la logica no. Entrambe le note non sono più cancellabili, o ancora peggio sono cancellabili ma hanno requisiti diversi.

Questo ti porta ad avere più versioni di "lo stesso" oggetto MusicEditor.Note , MusicPlayer.Note non puoi più parlare di note in modo generico.

Lo stesso è vero in misura minore quando i requisiti cambiano nel tempo.

La risposta è prendere un approccio ADM e mettere la tua logica in servizi, mantenendo solo i dati sull'oggetto.

Note.State
MusicEditor.IsDeletable(Note note)

Ora posso disporre di un servizio MusicPlayer separato con logica e metodi completamente diversi ma che funziona ancora con gli stessi oggetti dati delle note.

Allo stesso modo posso avere diverse versioni del servizio MusicEditor nel tempo

    
risposta data 06.01.2018 - 11:09
fonte

Leggi altre domande sui tag