Che cosa è un buon design per un contenitore, un compito e oggetti

Question

Che cosa è un buon design per un contenitore, un compito e oggetti

#1 da (1 voti)

0

    ------------- 1    * -------------- *       1 --------
    | Container |--------| Assignment |-----------| User |
    -------------        --------------           --------
          ^                     ^
          |                     |
      ----------            -------------
      |        |            |           |
---------- ----------  ---------- ---------------
| Flight | | Dinner |  | Booking| | Reservation |
---------- ----------  ---------- ---------------

Questo problema è uno che ho trovato in diverse occasioni ma non ho mai trovato una soluzione elegante per:

Nel mio modello di sistema (in rotaie), che mappa al database, ho bisogno di avere Users che può essere aggiunto a Containers a Assignments .

Ora, ci possono essere molte cose che possono essere contenitori:

Un Flight è un Container . Può contenere Users . In tal caso, il% concreto diAssignment è un Booking .
Un Dinner è un Container . Può contenere Users . In tal caso, il% concreto diAssignment è un Reservation .
E molti altri. Ottieni il mio punto.

Quindi ho nozioni astratte di Container e Assignment . Containers hold Assignments e ho anche implementazioni concrete di esse, con ogni implementazione concreta di Container che corrisponde a un'implementazione concreta di Assignment . Il design semplice è come sopra. Il mio problema principale è che non esprime la relazione tra ciascun contenitore di cemento e l'assegnazione concreta.

Qualche idea su come progettare meglio questo?

design design-patterns database-design ruby-on-rails orm

posta davidrac 21.03.2013 - 17:14

fonte

1 risposta

Leggi altre domande sui tag design design-patterns database-design ruby-on-rails orm

Come gestire il gioco "animato" in cui l'immagine deve "animare" invece di cambiare bruscamente? OO Design: suggerire EntityManager per precaricare alcuni set di dati

score 1 · Answer 1

In realtà hai un'implementazione di base del Pattern del ponte .

Dove le cose si rompono è che un Dinner non dovrebbe contenere un Booking . Tuttavia, il tuo modello indica che può. Dai tuoi commenti hai indicato che c'è molta logica condivisa nella classe Container che funziona su un insieme di Assignment s.

Suppongo che la classe Assignment esegua il suo lavoro utilizzando il metodo modello per delegare i dettagli di implementazione al sottoclassi e che Container non ha bisogno di essere a conoscenza del tipo Assignment con cui sta lavorando. In questo caso, l'unica preoccupazione è limitare quali tipi di Assignment s possono essere associati a Container .

In una lingua tipizzata, potresti creare un metodo% "protetto"% co_de nella classe addAssignment . Quindi in ogni sottoclasse Container fornisci un metodo pubblico di tipo% sicuroContainer o addReservation che chiama solo addBooking protetto. Potresti far rispettare questo controllo in runtime in un linguaggio dinamico, ma questo sembra eccessivo.

Un'altra soluzione è riconoscere che sia addAssignment che Booking contengono un singolo Reservation . Tecnicamente potresti creare un metodo "astratto" nella User chiamata Container che accetta addAssignment anziché User . Le sottoclassi Assignment quindi "sostituiscono" il metodo decorando l'oggetto Container passato e aggiungendo alla raccolta sottostante.

Il mio punto è che ci sono molte opzioni, che potrebbero cambiare nel modo in cui i tuoi oggetti stanno interagendo. Ad esempio, potresti anche passare un User a AssignmentFactory che ha spostato la logica di creazione da un'altra parte. Devi davvero decidere a quale livello di controllo desideri il tuo codice. Con un linguaggio dinamico è un po 'più difficile esplicitare. Spero che almeno alcuni dei miei esempi dimostrino anche quanto possa essere eccessivamente ingegnosa una soluzione quando inizi a essere paranoico.