Consigli per la correzione di bug del codice orientato agli oggetti: perché i dati non sono impostati?

Esistono due modi per gestire lo stato dell'oggetto:

1. Avere abilità di debug estremamente sofisticate in modo da poter trovare bug oscuri, o
2. Gestisci il tuo stato in un modo migliore in modo che gli errori oscuri non si verifichino in primo luogo.

Modi per gestire meglio lo stato dell'oggetto:

1. Utilizza i costruttori per creare oggetti il cui stato è già valido.
2. Rendi il tuo stato privato.
3. Metodi di settaggio della scrittura che convalidano i cambiamenti di stato. Blocca le modifiche di stato non valide.
4. Utilizza oggetti immutabili quando appropriato.

Una possibile soluzione è assicurarsi che il campo dell'oggetto sia sempre impostato nel costruttore. Spesso, ciò significa che il costruttore prende il valore di questo campo come argomento; è molto più difficile dimenticare di passare un argomento a un costruttore piuttosto che dimenticare di impostare un campo dopo il fatto.

Un potenziale svantaggio è che non è possibile creare l'oggetto finché non si sa quale dovrebbe essere il valore di questo campo. A volte (di solito?), La soluzione a questo è piuttosto semplice: basta non creare l'oggetto fino a quando non si sa quale dovrebbe essere il valore del campo.

Il consiglio più generale è: rendi la proprietà privata.

Il tuo oggetto dovrebbe essere responsabile del suo stato e non dipendere dagli altri per essere in uno stato valido. L'API della classe deve offrire il comportamento non la manipolazione dei dati.

Questa è una domanda piuttosto ampia, e la risposta generale è "usa buona architettura e design". Il debug non ti aiuterà, ma la progettazione del tuo codice lo farà correttamente.

• Progetta la tua applicazione in base ai principi SOLID.
• Utilizza strutture dati immutabili
• Imponi pre e post-condizioni (cioè fail veloce); costruisci sempre il tuo oggetto in uno stato valido o crash altrimenti.
• Non consentire riferimenti null attraverso le tue interfacce pubbliche (all'interno di una classe va bene se non puoi evitarli nel tuo linguaggio di programmazione).
• Utilizza i tipi di valore anziché le primitive (vedi ossessione primitiva).
• Utilizza le tecniche del design basato sul dominio.

Hai assolutamente ragione che null s è problematico ed è per questo che il suo inventore l'ha definito il suo "errore da un miliardo di dollari".

I miei punti elenco sono piuttosto generici, ma puoi cercare su Google e leggere su ciascun argomento. Capirai quindi come puoi migliorare per evitare il problema.

Congratulazioni! Molti programmatori non si rendono nemmeno conto che questo è un problema e continuano a scrivere codice buggy costoso.