OO Design: lettura / scrittura di oggetti con più formati

Question

OO Design: lettura / scrittura di oggetti con più formati

#1 da (2 voti)

1

Ho una classe Song , che ha i seguenti metodi pubblici:

String getSong();
void setSong(String);
int getId();
void setId(int);

Ora ho due modi diversi per memorizzare questi brani in un database:

solo due colonne; uno per ID, uno per l'intero testo del brano
tre colonne; uno per ID, uno per il numero di riga e uno per quella linea

[ Si prega di ignorare i problemi di progettazione di DB; è importante solo che i due schemi siano diversi. ]

Quindi ho bisogno di un modo per cambiare il modo in cui le canzoni sono scritte / lette dal / al database. Ciò potrebbe anche significare prendere una decisione runtime su quale schema io uso. Qual è il modo OO corretto per farlo? Mi sento come se lo schema della strategia funzionasse qui, ma non riesco a collegarlo tutto insieme. Alcune domande su cui mi sono confrontato:

Dovrebbe esserci un oggetto separato per ogni lettura e ogni scrittura? O una classe dovrebbe implementare sia una lettura che una scrittura?
Come posso evitare la logica duplicata? Ad esempio, metodo (2) significa che il metodo di scrittura divide la canzone su newline, mentre il metodo di lettura li unisce. C'è un modo per combinare la logica simile qui?
Che cosa succede se Song non ha setter pubblici? Come cambia il design?

Ho avuto davvero difficoltà a risolvere questo in modo pulito e in un modo flessibile orientato agli oggetti, quindi qualsiasi aiuto sarebbe fantastico.

object-oriented design design-patterns object-oriented-design serialization

posta Query 24.10.2015 - 12:59

fonte

1 risposta

Leggi altre domande sui tag object-oriented design design-patterns object-oriented-design serialization

Come testare un algoritmo con più input? Dove mettere la logica aziendale comune in DDD con MVC

score 2 · Answer 1

Forse, questa non è la risposta che ti aspetti, ma credo fermamente che dovresti impegnarti maggiormente nelle decisioni di progettazione, piuttosto che prendere decisioni sbagliate e investire la maggior parte del tempo nel pensare a come implementare questo cattivo design.

Now I have two different ways I might want to store these songs in a database:

1) just two columns; one for ID, one for the whole text of the song

2) three columns; one for ID, one for line number, and one for that line

Sì. Queste sono le possibilità. Ma mi vengono in mente due domande:

1) Perché vuoi 2 formati diversi (allo stesso tempo)?

2) Il secondo design ha senso?

Quale sarebbe il vantaggio di memorizzare il numero di riga e il contenuto di quella linea? L'unico caso, quando alla fine potrebbe in qualche modo avere un senso è, quando si hanno spesso query get me exactly line n from the song x e anche allora non vedo giustificazioni per memorizzare il testo riga per riga come righe di colonna. Metti il testo come TEXT nel DB e fai la magia che vuoi fare su quella in memoria dopo averla recuperata dal DB

So I need a way of swapping out how songs are written/read from/to the database. That might even mean making a runtime decision on which schema I use. What is the proper OO way of doing this? I feel like the Strategy pattern would work here, but I can't connect it all together. Some questions I've been struggling with over this

La strategia sarebbe adatta a questo; così potresti cambiare strategy come memorizzare o recuperare i dati a piacimento.

Should there be a separate object for each read and each write? Or should one class implement both a read and a write?

Il modello tipico per persistenza è repository . Il compito del repository è quello di astrarre i dettagli della persistenza. E sarebbe il repository, che userebbe strategy .

How do I avoid duplicated logic? For example, method (2) means the write method splits the song on newlines, while the read method joins them. Is there a way to combine the similar logic here?

Dipende dalla tua implementazione. Certo, ci sono modi per prevenire la duplicazione.

What if Song didn't have public setters? How does the design change?

Devi implementare in qualche modo, come la tua canzone rappresenta lo stato.

Dato che ne hai bisogno per impostare almeno la creazione dell'oggetto, dovresti scrivere un constructor tale, che il tuo oggetto sia inizializzato nel modo desiderato.

Lasciando (pubblico) setters , rendi l'oggetto immutabile che potrebbe essere quello che volevi. Il vantaggio di oggetti immutabili è semplice: sono incredibilmente noiosi; hanno sempre lo stesso stato, il che è bello nel contesto multithread. Non ci sono sorprese, quello stato è stato alterato involontariamente.