quale modello usare - se non del tutto

Question

quale modello usare - se non del tutto

#1 da (8 voti)
#2 da (3 voti)

3

Sono abbastanza nuovo nell'usare i pattern e anche se capisco alcuni di loro fino a un certo punto trovo difficile capire quale (i) utilizzare in una particolare situazione.

Sto provando a racchiudere uno schema db esistente in un numero di oggetti e non sono sicuro se dovrei semplicemente usare l'ereditarietà o una combinazione di alcuni modelli

Ho una tabella delle opzioni, che contiene le proprietà di base per un elemento così:

id
type
code
name

Queste opzioni hanno anche disponibilità - memorizzate in un'altra tabella

id (from option table)
fromdate
todate

e prezzi in un'altra tabella

id (from option table)
validfrom
fromdate
todate
price

e infine una tabella prenotata questa volta digitato sull'id dell'opzione e sulla persona che lo ha prenotato

id (from option table)
personid
bookedPrice

Solo per aggiungere altro nel mix, ci sono anche un paio di tipi di opzioni particolari che hanno proprietà aggiuntive che sono uniche per loro. Pensando che forse dovrei usare l'ereditarietà per la maggior parte - come i bit di prezzo / disponibilità sono usati per TUTTI i tipi di opzioni e quindi decorare le opzioni uniche con questi bit extra in quei casi particolari.

Quindi in circostanze diverse questi dati dovranno essere caricati in vari oggetti Mi chiedo se è meglio ereditare dall'opzione di base - fare un AvailabilityOption e un PricedOption ecc. Ed estendere l'opzione di base come quella o decorare l'opzione di base con le proprietà estese.

Non sono sicuro se ci sono abbastanza informazioni qui per rispondere. Mi chiedo se qualcuno potrebbe spiegare i vantaggi e le insidie di ciascuno, così non finirò per finire in un vicolo cieco?

design-patterns inheritance

posta nat 18.12.2013 - 11:22

fonte

2 risposte

Leggi altre domande sui tag design-patterns inheritance

Come posso "ispezionare" il codice C ++? Quanto è significativo il vantaggio del nodo di formare gli sviluppatori in una sola lingua e metterli in attività attraverso lo stack tecnologico? [chiuso]

score 8 · Answer 1

Non utilizzare mai uno schema se non sei sicuro se usarlo.

I modelli di progettazione sono codificazioni di cose che i professionisti avanzati hanno fatto spesso e infine pubblicate sotto un nome canonico. Sono spesso utili per risolvere un problema ricorrente, ma solo se questo è in realtà il problema che stai riscontrando. Se non sei sicuro che sia così, implementare un pattern aumenta la difficoltà del tuo lavoro, perché oltre a ottenere i dettagli delle tue esigenze, devi anche ottenere i dettagli del modello giusto.

Applicare lo schema può rendere il lavoro più semplice, ma a mio avviso ciò accade solo quando hai già compreso il modello (non necessariamente così come il suo autore, ma certamente abbastanza bene da poter ricreare il descrizione del problema / forza / soluzione / struttura della classe ecc. senza doverlo cercare). Di solito questo è perché hai anche risolto o almeno incontrato lo stesso problema dell'autore originale prima. Quindi , quando leggi la descrizione del pattern e ti rendi conto che risolve esattamente il problema che stai affrontando, è relativamente facile applicarlo e (secondo me) diventa abbastanza facile riconoscere altri problemi che richiedono esattamente questo modello.

In altre parole, ritengo che approfittare di questi schemi richieda di passare attraverso lo stesso processo di apprendimento facendo, riconoscendo e "raggruppando" la soluzione in un elemento riconoscibile del tuo pensiero come ha fatto l'inventore. Basta copiare una struttura di classe da un libro e chiamarla "Bridge" o qualsiasi cosa abbia poco valore se non come documentazione rapida per gli altri che leggeranno il tuo codice.

score 3 · Answer 2

Quando devi accedere a un modello di dati che non è stato progettato pensando a una struttura di oggetti o di eredità, è meglio evitare qualsiasi "oggettivazione" artificiale in seguito. Il rischio è alto che con la prossima versione del modello DB, le modifiche entreranno in collisione con la struttura dell'oggetto che hai aggiunto. Anche senza una modifica dello schema DB, i dati del mondo reale potrebbero non essere conformi ai vincoli aggiuntivi che la gerarchia di classe induce sul sistema.

Quindi mantienilo semplice e stupido e crea una classe per tabella, un attributo per colonna db, evita di usare l'ereditarietà e prova quanto lontano puoi ottenere con questo approccio.

Le cose sono abbastanza diverse quando il design del DB è stato realizzato da un modello di classe, con un ORM in mente. Quindi la documentazione dell'ORM dovrebbe suggerire come può essere la mappatura da tabelle a classi e quali opzioni hai.