Giustificazione per relazione bidirezionale

Question

Giustificazione per relazione bidirezionale

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

4

In genere cerco ed evito le relazioni bidirezionali a tutti i costi. Recentemente ho cercato di seguire una filosofia di progettazione più incentrata sul dominio e sto cercando consigli nel modo migliore per risolvere un problema specifico.

Sto implementando una griglia 2d di base. Ci sono 3 classi base, Item, Tile (ha un elenco di elementi) e World (ha un array 2d di tile).

Sto lottando con dove mettere il metodo move () che sposta un oggetto da una tessera a una tessera attigua. La mia inclinazione iniziale sarebbe quella di posizionare il metodo di spostamento nella classe Item poiché è l'oggetto effettivamente in movimento.

Tuttavia, ciò creerebbe una dipendenza circolare. In passato ho sempre lavorato con oggetti stupidi, nel qual caso il metodo move () era in un livello superiore (una specie di WorldManager o MoveManager) che conosce sia le piastrelle che gli oggetti. Sono interessato a quali proposte potrebbero avere altri che possono evitare la dipendenza circolare mantenendo la filosofia centrata sul dominio.

domain-driven-design domain-model dependency-analysis

posta Pace 11.08.2012 - 01:52

fonte

4 risposte

1

Per DDD, la cosa più importante per iniziare è la conoscenza del dominio. Se, tutto ciò che fai con la tua 'griglia 2d di base', sta spostando gli oggetti da una tessera all'altra, allora perché hai bisogno di mettere una lista di elementi in una tessera? Per quale caso d'uso?

Se fossi in te, cercherei qui radice aggregata. Probabilmente, "mondo" potrebbe essere quello in cui potresti inserire il metodo di spostamento. Tutto dipende dal dominio e dai suoi casi d'uso.

Un esercizio pertinente può essere trovato in Disegno efficace degli aggregati di Vaughn Vernon

risposta data 12.01.2016 - 22:58

fonte

0

Hmm, mi piace l'idea MoveManager migliore.

Qualsiasi oggetto che si muove da solo richiederebbe anche la conoscenza della superficie sottostante su cui si muove, quindi dovresti comunque passare il tileset alla tua Item . Ecco il tuo accoppiamento lento.

Mi sembra che abbia più senso avere un oggetto MoveManager che ha conoscenza del tileset e degli elementi. Ecco come funziona il mondo reale; i pezzi degli scacchi e la scacchiera non hanno alcuna intelligenza incorporata.

risposta data 11.08.2012 - 02:25

fonte

0

I am struggling with where to put the move() method which moves an item from one tile to a neighboring tile. My initial inclination would be to place the move method in the Item class since it is the item that is actually moving.

Quale classe ha la responsabilità di mantenere l'invariante?

Ad esempio, se esiste una regola per cui è possibile solo spostare gli elementi in riquadri adiacenti, è necessario implementare il metodo di spostamento su cui mai oggetti conoscono quali tessere sono vicine.

Attenzione: una delle difficoltà del DDD e dei "semplici" problemi: la regola aziendale è in realtà "fai tutto ciò che l'operatore umano ti dice", e non c'è in realtà un invariante da implementare nel modello.

risposta data 12.01.2016 - 23:38

fonte

Leggi altre domande sui tag domain-driven-design domain-model dependency-analysis

Come si scrive un algoritmo linearithmic? Considerazioni sullo sviluppo di un sistema su larga scala che deve essere sia accessibile al Web tradizionale che accessibile tramite dispositivi mobili

score 3 · Accepted Answer

Per rispondere direttamente alla tua domanda:

Un giocatore direbbe (raccogliendolo) un oggetto per spostarsi da una tessera all'altra. Quindi logicamente, il metodo move va su Item e riceve le due tile come parametri.

Ora ho detto questo:

Non lasciare che il DDD interferisca con il principio della singola responsabilità. Va bene avere elementi non entità, come MoveManager, e chiamarlo parte del tuo dominio. Solo perché non lo fai persistere da nessuna parte, non ne fa meno parte del dominio.

Spesso le persone confondono il modello di dati con il modello del comportamento (o del dominio aziendale) quando parlano di DDD. Qualunque cosa può essere un'entità. In effetti, si potrebbe sostenere che qualcosa persisteva ha già la sua unica responsabilità e non dovrebbe essere più fornito.

Da MSDN :

I, for one, am not disturbed by the need to involve other, non-entity classes, and I would try to avoid lifting the central behavior outside of my entity. You should always remember that entities are intrinsically behavioral units. Often that behavior will be implemented as a kind of state machine—when you invoke a command on an entity, it is responsible for changing its internal state—but sometimes it's necessary for you to obtain additional data or impose side-effects upon the outside world.