2011-08-25 18 views
6

So che ci sono diversi modi di ravvivare la conversione di associazione, aggregazione e composizione in java. Ma quando li convertiamo in codice (classi java) sono tutti rappresentati nello stesso modo. Come lo Studente insegnato dall'insegnante che è l'associazione sarà rappresentato con la classe Student con variabile di istanza di Insegnante di Classe.Conversione di associazione, aggregazione e composizione in codice in java?

Dipartimento ha professori che è l'aggregazione sarà anche essere rappresentato con classe Dipartimento con variabile di istanza (array) di professori di classe.

Università ha dipartimenti che è composizione sarà anche essere rappresentato con classe Università con variabile di istanza (array) del dipartimento di classe.

Quindi tutti sono ripresentati nello stesso modo in termini di codice. Quindi, quali sono i termini di benefici che l'associazione, l'aggregazione e la composizione forniscono allo sviluppatore?

risposta

4

Ti manca una parte della storia con Composizione. Incarica un paio di ulteriori proprietà:

  • immutabilità del genitore (cioè bambino non può passare genitori)
  • ciclo di vita responsabilità per i bambini si trova con il genitore. il genitore è responsabile della creazione e dell'eliminazione delle istanze secondarie. Il bambino non può vivere dopo la morte del genitore.

Hai ragione che l'associazione si manifesterà come riferimento/raccolta di referenze nel genitore & genitore rispettivamente. Ma il codice deve anche applicare le regole di cui sopra per garantire l'applicazione della semantica di composizione.

Come per l'aggregazione: non lo uso. La semantica è troppo lenta e non offre vantaggi rispetto alle associazioni dirette.

hth.

+0

Spiacente sfinnie ho perso entrambi i punti. Punto 1: - Se consideriamo l'esempio di composizione nel post originale, stai dicendo che la classe University dovrebbe avere una variabile di istanza (array) del dipartimento Class come finale. Se non lo rappresenteremo nel codice. Punto 2: - sì sono d'accordo con il tuo punto ma non fa differenza quando convertiamo il diagramma uml in codice perché sarà ancora una semplice variabile di istanza. –

+0

punto 1: sì. Punto 2: non si tratta solo del riferimento. La semantica composita UML richiede "Se un composito viene cancellato, tutte le sue parti vengono normalmente cancellate con esso" (Sovrastruttura UML 2.3, pagina 40). In linguaggi non GC come C++, questo significa che il codice del distruttore deve garantire che tutti i bambini vengano cancellati prima che il genitore venga eliminato. Per gli ambienti GC questo è meno ovvio. Tuttavia, esistono idiomi, come l'approccio "Aggregate Root" reso popolare da Domain Driven Design, in cui l'unico modo per creare (o rimuovere) un bambino è tramite i metodi sul genitore stesso ... (ctd). – sfinnie

+0

... quindi, nello scenario prototipo Order/OrderLine, l'unico modo per aggiungere una OrderLine da un ordine è chiamare Order.AddOrderLine() (analogamente per la rimozione). Quindi, per riassumere: non esiste un analogo diretto e dichiarativo nel codice che denoti un composito. Invece devi costruire il comportamento proceduralmente. Identificare i compositi nel codice richiede quindi una quantità di "riconoscimento del modello". Se il riferimento è definitivo e l'unico modo per creare/eliminare un bambino è attraverso l'interfaccia del genitore, la relazione è probabilmente Composito. hth. – sfinnie