Design OOP: relazione tra classi di entità

Naviga le tue risposte
6

A prima vista ho un problema semplice ma non riesco a capire come risolvere. Ho una classe astratta Compound . Un Compound è costituito da Structures . Poi c'è anche un Container che contiene l'1% diCompound.

Un'implementazione "speciale" di Compound ha Versions . Per quel tipo di Compound voglio Container per contenere il Version del Compound e non il Compound stesso.

Potresti dire "crea solo un'interfaccia Containable " e una Container contiene l'1% diContainable. Comunque non funzionerà. Il motivo è che sto creando un framework e la parte principale di tale framework è di semplificare la memorizzazione e in particolare la ricerca di un tipo di dati speciale contenuto da Structure oggetti. Quindi per cercare Containers che contengono un Compound composto da uno specifico Structure richiede che il "Percorso" da Container a Structure sia ben definito (Numero di relazioni o join).

Spero che questo sia comprensibile. La mia domanda è come progettare le classi e le relazioni per essere in grado di fare ciò che ho delineato.

EDIT:

Tipo di problema di traduzione. con la versione non intendevo in termini di "versioning" ma più in termini di "varietà diversa" ma fondamentalmente uguale. Non c'è attivo / inattivo. Tutti sono attivi.

EDIT 2:

Si noti inoltre che queste classi sono classi di entità e quindi l'ereditarietà e le gerarchie complesse possono essere problematiche.

MODIFICA 3:

Semplicemente non vedere come può funzionare uno dei due pattern (Composito, Decoratore). Ho provato ma il problema è il "percorso trasversale", ad es. implementandolo nel contesto di Spring-data e QueryDSL.

Ho creato un diagramma di classe con commenti che potrebbero aiutare a capire il problema. Batch = Versione.

    
posta beginner_ 15.11.2012 - 06:24
fonte

6 risposte

0

La soluzione che ho usato è questa:

E per fare riferimento all'immagine nella domanda, un Batch estende Contenuti.

    
risposta data 15.05.2013 - 10:31
fonte
1

... to search for Containers which contain a Compound made up of a specific Structure requires that the "Path" from Container to Structure is well defined (Number of relationships or joins).

Non se stai chiedendo al contenitore se ha una tale struttura sì o no, allora solo il contenitore deve conoscere il percorso. Puoi tenerlo un dettaglio di implementazione in questo caso.

Implementa una classe contenitore per i composti senza versione e un'implementazione per i composti con versione modificata. Attraversi indirettamente le strutture attraverso la delega.

    
risposta data 12.12.2012 - 18:30
fonte
0

È possibile avere la speciale esecuzione del Compound pass di invocazioni dei suoi metodi Compound alla sua versione attiva? In questo modo il contenitore non saprebbe che ha un composto speciale.

    
risposta data 15.11.2012 - 17:38
fonte
0

Se ho capito bene, Compound è una classe astratta. Un'implementazione di un composto non ha Versioni, ma un'altra. Come suggerito da @SteveEmmerson, la proprietà Compound an ActiveVersion risolverebbe questo problema di progettazione.

L'opzione che preferisco è applicare il modello Composito . In questo progetto, l'implementazione di Compound (ad esempio VersionedCompound ) sarebbe responsabile per i dati della versione da presentare quando viene trattato come un composto.

Lo preferisco perché questo design è additivo, in altre parole, non richiede il refactoring della classe Compound .

    
risposta data 15.11.2012 - 18:20
fonte
0

Ci sono tanti modi per realizzare variazioni nella struttura e nella funzione del codice.

In questo caso, se non ci sono funzioni che funzionano in modo diverso per un Composto con versione di un Composto non in versione, l'ereditarietà o qualche schema di progettazione sarebbe eccessivo.

Che ne dici di una "versione" di attributo? Per i composti semplici, la versione potrebbe essere "none" o 0 o 1, qualsiasi cosa abbia più senso per il modo in cui la usi.

Se per qualche motivo le funzioni effettive su Compound devono essere implementate in modo diverso, allora si desidera il polimorfismo. In tal caso, ritengo che la descrizione di neontapires dell'uso del pattern Composite sia una buona direzione.

Come ti aspetti che il codice client usi un composto rispetto a un composto con versione?

Sono come gli isotopi o gli zuccheri mancini / destrimani?

    
risposta data 08.12.2012 - 20:10
fonte
0

Questo problema può essere affrontato usando il pattern Decorator. Mantieni il contenitore relativo al Compound e trasforma la versione in un decoratore di Compound.

Utilizzando il diagramma di riferimento qui , il tuo problema potrebbe essere mappato in questo modo:

  • Componente = Composto
  • ConcreteComponent = Concrete Compound che contiene Structures
  • Decorator = Version Concrete
  • Decoratore = versione di modelli o pacchetti di extra

Spero che ti aiuti.

    
risposta data 09.12.2012 - 15:02
fonte

Leggi altre domande sui tag

Metodo di fabbrica astratto e polimorfismo Approccio di licenza per la libreria .NET che potrebbe essere utilizzata desktop / web-service / ambiente cloud