Campi pubblici in un oggetto di trasferimento dati

Question

Nei miei anni di programmazione ho spesso creato classi che raggruppano semplicemente alcune variabili con i loro setter e getter. Ho visto questi tipi di oggetti denominati oggetti valore, oggetti dominio o oggetti modello a seconda del contesto in cui vengono utilizzati. Il termine più adatto per l'uso generico sembra essere il Data Transfer Object (DTO). Questo descrive un POJO che contiene solo accessori e mutatori.

Ho appena scritto uno di questi oggetti che contiene circa cinquanta campi utilizzati per impostare i parametri del tema su un grafico. Ora mi chiedo se invece di generare un centinaio di gettatori e setter dovrei semplicemente dichiarare questi campi come pubblici. Fare così va contro tutto ciò che i miei istinti di programmazione mi dicono ancora non posso negare che aumenterebbe notevolmente la leggibilità del mio codice e ridurrebbe la quantità di codice boilerplate nella classe.

L'unico motivo per cui posso vedere non per utilizzare i campi pubblici sarebbe se avessi bisogno di eseguire qualsiasi tipo di convalida su questi campi. Se supponiamo che la convalida del tipo sia sufficiente per i miei scopi, sta usando i campi pubblici in questo scenario una rottura accettabile dalla progettazione orientata agli oggetti? Un DTO pubblico funzionerà meglio con operazioni batch di grandi dimensioni?

Answer 1

La maggior parte dei programmatori imposterà automaticamente i campi privati ​​con getter/setter senza pensarci. Ma come ogni cosa di culto del cargo, è meglio prendere una decisione consapevole.

Il motivo principale per l'utilizzo di una combinazione getter/setter anziché di un campo pubblico è che è possibile modificare la definizione. Quindi, se il DTO fa parte di un'interfaccia tra componenti, è meglio usare i getter. Se cambi il funzionamento interno, puoi adattare il getter per simulare il vecchio comportamento e mantenere la compatibilità.

Un'altra ragione è che è possibile creare campi di sola lettura. Spesso per DTO, la sola lettura e l'immutabile sono una buona scelta.

Un terzo motivo potrebbe essere che il DTO deve essere un javabean perché si intende utilizzarlo in alcuni strumenti che lo richiedono.

Se nessuna di queste proprietà è adatta a te, non c'è motivo di non utilizzare i campi pubblici.

Non aspettatevi molto di una differenza di prestazioni però :)

Answer 2

Non credo che sia una pratica terribilmente male avere una classe "settings" o "theme" o "style" con attributi pubblici.

Gli IDE moderni con strumenti di refactoring rendono banale la promozione di un attributo a getter/setter se si desidera eseguire calcoli complicati o verifiche sui valori al momento dell'impostazione.

Spesso nel proprio "setTheme" o qualsiasi funzione che utilizza queste classi di impostazioni è un buon punto pulito per eseguire la convalida.

Quando si impostano impostazioni come questa di solito è opportuno eseguire un oggetto copiato in profondità anziché conservare un riferimento a una classe mutabile.