I campi devono ancora essere privati quando è necessario ristrutturare i dati?

Devi separare i tuoi oggetti dati chiaramente dalle altre classi dell'applicazione , seguendo responsabilità singola . La maggior parte dei metodi dell'esempio non dovrebbe appartenere ai tuoi oggetti dati, dovrebbero appartenere alle classi controller o ad altre classi di applicazioni, perché la responsabilità degli oggetti dati dovrebbe essere, beh, solo per contenere o gestire i loro dati e non per interagire con il file system o l'interfaccia utente. Se inizi a ristrutturare la tua applicazione in questo modo, i tuoi oggetti dati (e solo gli oggetti dati) avranno già la maggior parte dei loro campi accessibili al pubblico.

Ad esempio, un metodo come DisplayAsText() che in realtà visualizza il tuo oggetto sullo schermo chiaramente non appartiene a nessuno dei tuoi oggetti dati. Invece, un metodo come ToString() potrebbe essere parte degli oggetti dati, che viene chiamato da un metodo DisplayAsText() che fa parte di una classe completamente diversa da qualche altra parte nell'applicazione. Un metodo come ErrorCheck potrebbe chiamare molti piccoli metodi di convalida dei tuoi oggetti di dati che dicono se qualche stato è giusto o sbagliato e visualizzare l'errore, il che significa che i piccoli metodi di validazione dovrebbero essere parte degli oggetti dati e ErrorCheck stesso chiaramente no. E un metodo come Edit() in genere richiede un accesso completo in lettura / scrittura per ogni campo di dati degli oggetti dati, quindi dovresti averlo già disponibile quando inizi a implementare il tuo metodo SaveToNewFormat .

Fields are private. Objects have lots of methods to deal with many different uses.

Mantieni i campi privati (getter e setter sono malvagi), ma riduci anche le cose specifiche che ogni oggetto sta facendo usando altri oggetti specializzati.

Per dare un esempio, nessun oggetto dovrebbe avere entrambi questi metodi

DisplayGraphically()
DisplayAsText()

Dovrebbero avere al massimo un singolo metodo di visualizzazione. Non è compito degli oggetti capire dove stanno visualizzando. Invece dovresti avere un oggetto Display che fa funzionare il grunt e può essere un display grafico o un display di console. Questa classe dovrebbe avere un'interfaccia chiara che il tuo oggetto si aspetta e capirà.

Quindi, al posto dei due diversi messaggi sopra, sostituisci con

myobj.display_myself(display_to_use)

Il tuo oggetto sa solo come utilizzare questo oggetto Display per visualizzarsi, molto probabilmente chiamando semplicemente l'oggetto Display con lo stato interno dell'oggetto.

È lo stesso oggetto di visualizzazione che sa come visualizzare tali informazioni. Potresti avere migliaia di tipi di classi Display, ma il tuo oggetto originale ha ancora bisogno di un solo metodo.

Quindi affermare di salvare i dati degli oggetti in un DB. Il tuo oggetto non dovrebbe interessarti. Ha solo

myobj.persist_myself(persistence_to_use)

dove persistence_to_use può essere un oggetto che sa come scrivere su un database, o un oggetto che conosce i file, o un oggetto che conosce i dischi di backup, ecc.

Vuoi cambiare completamente il formato del file che usi per mantenere i tuoi dati. Fantastico, al tuo oggetto non importa un po '. È sufficiente creare un nuovo oggetto Persistenza che faccia ciò che mai un nuovo file di file di fantasia desideri e passa quell'oggetto invece del vecchio oggetto di persistenza. myobj non si accorge nemmeno di questo cambiamento.