Ho una classe che avrà un numero enorme di proprietà (da 30 a 50). Un numero enorme di queste proprietà sarà letto solo sul client. È una buona pratica avere una classe con molte proprietà o avere classi più piccole e usarle come proprietà nella classe genitore?
Nota che gli oggetti di questa classe verranno inviati al client in formato JSON e avere una classe con molte proprietà renderà il messaggio un po 'più piccolo.
In teoria, è meglio avere classi più piccole quando è possibile un raggruppamento logico delle proprietà. Tuttavia, ci sono un certo numero di casi in cui il costo di refactoring della classe in quelli più piccoli non supera i benefici. Alcuni possibili motivi:
il refactoring viola la retrocompatibilità del codice esistente e il refactoring di tutto questo codice non sembra degno di nota, o non è nemmeno possibile poiché non è sotto il tuo controllo
la struttura delle classi deve riflettere un modello di dati o un'API esistente in un modo 1: 1, in cui questo modello o API non è sotto il tuo controllo
la classe funziona solo come un "oggetto di trasferimento dati", senza alcuna logica aziendale, e non ci sarà quasi nessun codice che trarrà vantaggio dalla struttura migliore (ma attenzione, dovresti essere quasi sicuro che questo non cambierà nella prossima versione del tuo programma)
ti aspetti un impatto sulle prestazioni serio (e misurabile) utilizzando classi più piccole
non è possibile utilizzare facilmente tipi di dati combinati o riferimenti ad altri tipi in questa classe specifica per qualche motivo tecnico, quindi sei legato all'uso di tipi primitivi
Quindi, quando si applica una delle ragioni sopra esposte, si potrebbe stare meglio con quelle proprietà da "30 a 50". Se non è applicabile, raccomando vivamente di rifattorizzare le classi più piccole.
Dipende davvero dal tipo di proprietà e dal modo in cui si integrano logicamente. Se appartengono logicamente allo stesso oggetto, quindi vai avanti, non c'è motivo di dividerli. Se appartengono logicamente a diverse sottoclassi, allora a questo.
Il sovraccarico del messaggio di avere diverse sottoclassi non dovrebbe essere un problema. Il sovraccarico sarà trascurabile a meno che tu non abbia una grande quantità di traffico o requisiti di prestazioni davvero elevate, nel qual caso dovresti usare un protocollo specializzato.
Come l'altro già menzionato, il semplice fatto che tu abbia "molte" proprietà non è una buona ragione per diffonderle su più classi. Puoi tuttavia voler categorizzare le tue proprietà e applicare una gerarchia. Questo renderà più facile al destinatario / utente dell'oggetto trovare le proprietà di cui ha bisogno, renderebbe la classe più facile da capire. Quindi, invece di Larghezza, Altezza, Colore, Tessuto avresti Dimensioni. Larghezza, Dimensioni.Altezza, Skin.Color e Skin.Fabric.
Se le dimensioni dei messaggi sono davvero importanti, fai ricorso alla compressione a livello di messaggio piuttosto che rovinare il tuo modello.
Stai pensando a come organizzare tutte queste proprietà, ma questi dati dovrebbero essere disposti anche in "proprietà"?
Si dice che la maggior parte di queste proprietà sarà utilizzata solo sul lato client, quindi presumo che il server stia leggendo queste proprietà da qualche database nell'oggetto e passandole al client così com'è. Il server funge da pipe: è "consapevolezza" della struttura dei dati che le pipe devono essere limitate. Se la pipe è a conoscenza della struttura dei dati che canalizza, diventa un altro posto che dipende da quella struttura e quella dipendenza non fornisce molto valore.
Al posto delle proprietà, ti suggerisco di usare un dizionario o qualche altra struttura di dati dinamica - una che il codice che la gestisce non ha bisogno di essere consapevole della struttura effettiva che detiene. In questo modo il codice del server non ha bisogno di preoccuparsi di quante proprietà ci sono e di come è organizzata la loro gerarchia.
Ricorda che:
Anche se il server trasmette solo i dati, a volte si desidera convalidarli. Per quello puoi usare uno schema. Puoi usare qualcosa come JSON Schema , ma ci sono anche alcune librerie che usano le classi come schema e usano la riflessione per leggerle. Se si utilizza tale libreria, è necessario scrivere una classe con tutti questi campi come proprietà - ma la mia risposta è ancora valida! Assicurati di trattare queste classi come schemi, non come effettive classi OOP. Non si scrivono queste classi per l'incapsulamento: le si scrive come alternativa alla scrittura di uno schema JSON in JSON. Non è necessario applicare la metodologia OOP completa su di essi solo perché sono classi.
Vorrei basare questo sulla riunione di due fattori:
Ad esempio, prendi un semplice sistema di gestione dei prodotti al dettaglio. Diversi campi potrebbero essere raggruppati per rappresentare la quantità di prodotto nell'inventario: magazzino, numero del cestino, data di messa in inventario / età se deperibile, numero in magazzino, prezzo di acquisto, ecc. Nessun inventario per questo articolo non tirerebbe nulla, quindi in quel caso ci sono meno dati.