Wrapping Object VS Copia dei campi

Question

Wrapping Object VS Copia dei campi

#1 da (4 voti)
#2 da (0 voti)
#3 da (0 voti)

2

Quasi tutti i software hanno un numero di strutture di dati interne che non vogliamo esporre esternamente (tramite le API ad esempio).

Diciamo che abbiamo alcune classi che rappresentano le tabelle del database 1: 1 - User , UserGroup , GroupPermission , ecc.

Quindi possiamo avere una classe esterna ExternalUser che verrà esposta su un'API, esponendo alcuni dettagli dell'utente e dettagli del gruppo di utenti.

Abbiamo due opzioni per ciò che le proprietà di ExternalUser possono essere:

Copia proprietà - ExternalUser ha una copia di un sottoinsieme di proprietà o proprietà derivate da User e UserGroup

1.1. ExternalUser può avere ad esempio username , fullName , userGroups , ecc. come proprietà.

1.2 Tutte queste proprietà verranno popolate sulla creazione dell'oggetto e copiate da User interno e UserGroups
Oggetto di avvolgimento - ExternalUser ha riferimenti a User e UserGroup .

il 2,1% diExternalUser avrà un% privato diuser e% diuserGroup che manterrà il riferimento ai modelli interni.

2.2 Metodi come getName delegheranno al% interno% co_de, ecc.

Riesco a vedere i pro e i contro di entrambi in termini di perdite di dati, utilizzo della memoria e gestione delle sessioni se si hanno a che fare con transazioni.

C'è qualche schema / standard o una ragione per cui un'opzione è molto migliore rispetto all'altra?

encapsulation java design-patterns

posta SDekov 09.10.2018 - 11:13

fonte

3 risposte

Leggi altre domande sui tag encapsulation java design-patterns

Ereditarietà: quando solo alcuni oggetti concreti devono condividere lo stato Qual è la differenza tra modelli di processi di sviluppo agili e incrementali

score 4 · Answer 1

Se ti capisco correttamente, copiando le proprietà, intendi non usare l'incapsulamento e semplicemente imposta i singoli campi su un'istanza di ExternalUser , sono corretto?

Copiando le proprietà, stai sostanzialmente cercando di rendere il tuo programma più robusto. Una classe POJO come ExternalUser senza tipi sofisticati incapsulati all'interno sarebbe un ottimo modo per staccare l'effettiva implementazione del tuo programma con chi lo usa. L'utente che chiama la tua API presumibilmente riceverà istanze di ExternalUser e non ci sarebbero complicazioni di alcun tipo. I dati sono presenti e possono essere opportunamente serializzati se desiderato.

Incapsulando le istanze delle tue classi interne, la classe ExternalUser diventa molto più dipendente dalla tua implementazione. Ciò non è necessariamente una cosa negativa, poiché è probabile che la modifica dei metodi di User e UserGroup causi comunque ulteriori modifiche nel programma, indipendentemente dal fatto che questa logica sia direttamente in ExternalUser o altrove. Tuttavia dovresti fare attenzione a nascondere tutte le implementazioni interne se lo fai in questo modo. ExternalUser dovrebbe essere una classe dedicata per questo, e quindi tutti i metodi pubblici e sì, anche i metodi privati, non dovrebbero restituire un'istanza User o UserGroup . Perché anche i metodi privati? Perché puoi ancora accedere ai metodi privati tramite la riflessione.

Sebbene non siate favorevoli alla robustezza, seguite il principio DRY, che rende il vostro programma più flessibile e più facile da mantenere in generale.

La mia preferenza personale è mantenere l'interfaccia semplice e robusta, quindi utilizzerei una classe POJO per ExternalUser . Se si desidera seguire il principio di DRY il più possibile, evitare semplicemente di usare ExternalUser fino a quando non si desidera restituire i dati al chiamante. ExternalUser dovrebbe essere una classe esterna rigorosamente a questo punto. Tuttavia, questo potrebbe anche essere un po 'eccessivo per un piccolo progetto, quindi alla fine dipende dalle preferenze personali.

score 0 · Answer 2

Nel caso di un'API non è necessario.

È necessario utilizzare l'oggetto ExternalUser nella libreria client di Api, quindi è necessario uno di questi.

È necessario che l'API emetta una stringa, che contiene solo i dati per i campi in Utente esterno. Ma non è necessario serializzare un oggetto ExternalUser per ottenerlo.

Devi solo configurare il tuo serializzatore per includere solo le proprietà che desideri dall'oggetto Utente.

score 0 · Answer 3

Ci sono due casi

1. API REST e altri canali IO

In genere, non avrai bisogno di oggetti aggiuntivi. Perché? Perché quando serializzi l'output, puoi in genere utilizzare annotazioni come @Ignore o @Expose per serializzare in modo selettivo i tuoi dati in JSON / XML.

2. Confezionato come libreria di codici

Quindi dovresti copiare le tue proprietà in ExternalUser , ad esempio. Perché? Perché sarebbe probabilmente possibile ispezionare il contenuto dei membri privati attraverso la riflessione.