Corsi di Laurea

[tanux]

Sul libro Thinking in Java ho trovato solo il concetto ampliamente spiegato di composizione, mentre dell'aggregazione dice che è un concetto simile, ma che avviene in maniera dinamica.
Qualcuno mi sa spiegare per bene la differenza tra i due concetti?
A tal proposito ho trovato un link che sembra essere interessante, e magari utile esempio.
http://forum.wininiz...showtopic=67421

[tanux]

UP
ho provato a darmi una risposta:
Entrambe rispondono alla relazione “ha un”, e in entrambi i casi posso ampliare l’applicazione con una classe che contiene oggetti o istanziamenti di altre classi.
L'aggregazione è una relazione puramente logica.

Nell’aggregazione, creo gli oggetti nella classe che sto creando, poi li associo ai componenti dell’oggetto, ma cio lo posso fare anche al di fuori dell’istanziamento della classe che sto creando.Quindi si tratta di effettuare questo processo: creo una nuova classe e al suo interno istanzio altre classi che servono(quindi metto dentro degli oggetti). Poi al di fuori della classe, alloco prima gli oggetti che compongono la classe, e istanzio la classe creata e alloco il relativo oggetto e lo uso.

Nella composizione invece,l’oggetto contenuto non puo esistere senza il contenitore: cioe non posso creare istanze degli oggetti, al di fuori della classe che sto creando e quindi devo necessariamente farlo al suo interno. Quindi si tratta di effettuare il seguente processo: creo la nuava classe e al suo interno istanzio altra classi che servono (quindi metto dentro gli oggetti) e sempre all’interno della classe alloco anche quegli oggetti e li utilizzo. Al di fuori della classe creata, istanzio la classe e alloco il relativo oggettoe lo uso.

Pero se qualcuno me lo sa spiegare meglio...sembra un po ortodossa come spiegazione .

[Peppeweb]

Nella composizione tu utilizzi un oggetto come attributo di una nuova classe, ciò comporta che il ciclo di vita dell'oggetto componente ( ex string ) è lo <= del ciclo di vita dell'oggetto composto.
Nell'aggregazione invece tu usi un oggetto come attributo di una nuova classe lo stesso, ma qui non lo vai anche a creare, bensì lo ricevi dall'esterno, ciò significa che l'oggetto aggregante esiste a priori e quindi il ciclo di vita dell'oggetto aggregante è > del ciclo di vita dell'oggetto aggregato.

Nella pratica la composizione la tieni quando hai dichiari una reference a string e fai anche la new, l'aggregazione invece quando dichiari solo la reference a string e poi tipo nel costruttore passi un riferimento ad una stringa che è stata creata precedentemente

[tanux]

quindi, se mi permetti aggiungerei, che in sostanza:
nella composizione, l'oggetto composto, non puo mai esistere, se non creo gli oggetti componenti;
nell'aggregazione, l'oggetto composto puo esistere anche se non ho creato gli oggetti.

[Peppeweb]

quindi, se mi permetti aggiungerei, che in sostanza:
nella composizione, l'oggetto composto, non puo mai esistere, se non creo gli oggetti componenti;
nell'aggregazione, l'oggetto composto puo esistere anche se non ho creato gli oggetti.

Non è detto, gli oggetti composti/aggregati esistono comunque, soltanto che hanno il riferimento a null. secondo me piuttosto che definirle rispetto alla vita dell'oggetto composto ,viene più chiaro definirle rispetto agli oggetti componenti/aggreganti.

[Blackjack]

quindi, se mi permetti aggiungerei, che in sostanza:
nella composizione, l'oggetto composto, non puo mai esistere, se non creo gli oggetti componenti;
nell'aggregazione, l'oggetto composto puo esistere anche se non ho creato gli oggetti.

Non è detto, gli oggetti composti/aggregati esistono comunque, soltanto che hanno il riferimento a null. secondo me piuttosto che definirle rispetto alla vita dell'oggetto composto ,viene più chiaro definirle rispetto agli oggetti componenti/aggreganti.

Beh peppe se proprio vogliamo mettere i puntini sulle I, gli oggetti aggregati di fatto nn esistono, ma esistono solo i loro reference che puntano a null.

E poi un mio pensiero: la differenza tra aggregazione e composizione, vista così tecnicamente, è molto sottile. Quando si parla di composizione vuol dire che l'oggetto composto non ha proprio senso di esistere senza l'oggetto componente, ad esempio se creo una classe ElencoStringhe che contiene al suo interno un Vector.
In questi casi, molto probabilmente, questo vettore viene istanziato nello stesso costruttore di ElencoStringhe, e non viene passato come parametro, ma non è detto: potremmo prevedere che il nostro vettore sia comunque ricevuto dall'esterno (e che sia sostituibile o meno durante la vita dell'oggetto ElencoStringhe).
Dualmente, se abbiamo un'aggregazione, non necessariamente l'oggetto aggregato deve ricevere l'oggetto aggregante dall'esterno, ma può anche crearne uno di default che poi sia successivamente sostituibile.

Quindi la giusta domanda da porsi quando si fa la differenza tra questi 2 concetti è: l'oggetto aggregato/composto HA SENSO, HA UNO SCOPO, se l'oggetto aggregante/componente non esiste?

[Mr_fox]

Quindi la giusta domanda da porsi quando si fa la differenza tra questi 2 concetti è: l'oggetto aggregato/composto HA SENSO, HA UNO SCOPO, se l'oggetto aggregante/componente non esiste?

Secondo me non ha senso... Perchè la relazione della composizione e dell'aggregazione è un tipo di relazione "Ha un" e quindi non essendoci l'oggetto aggregante/componente non viene verificata questo tipo di relazione...

[Blackjack]

Secondo me non ha senso... Perchè la relazione della composizione e dell'aggregazione è un tipo di relazione "Ha un" e quindi non essendoci l'oggetto aggregante/componente non viene verificata questo tipo di relazione...

Beh, secondo me è quello che hai detto tu che non ha senso

Hai confuso la classe con l'oggetto... se io avessi detto che non c'è la classe aggregante/componente allora nel mio modello la relazione di aggregazione/composizione non avrebbe avuto senso...

Ma io non stavo discutendo il modello, è per questo che ho parlato di oggetti e non di classi: in particolare sto parlando del caso in cui nel modello è previsto che vi sia una relazione di composizione/aggregazione tra un oggetto della classe X e un oggetto della classe Y, e capiti che, durante l'esecuzione del programma, l'oggetto della classe X (chiamamolo "peppe" ) non abbia come attributo alcun oggetto della classe Y, ma abbia tale valore a null.

Se la relazione è di composizione, se si dovesse verificare questo caso appena citato l'oggetto "peppe" non avrebbe senso di esistere o semplicemente non potrebbe funzionare, oppure avrebbe un comportamento non specificato, e il programmatore quindi deve fare in modo che questa eventualità non si verifichi mai, cioè esista sempre in "peppe" un oggetto della classe Y (chiamiamolo "andrea" ) che non sia null. In poche parole, "peppe" non può vivere senza "andrea".

E' ben altro discorso se la relazione è di aggregazione, in questo caso l'oggetto "peppe" può ancora funzionare (molto probabilmente perchè l'oggetto aggregante non è di vitale importanza per l'oggetto aggregato) anche quando "andrea" è a null.

E' fondamentalmente qui la differenza tra aggregazione e composizione, che poi spesso si traduce, nel pratico, a inserire/togliere certi metodi e certi attributi dei costruttori della classe X, come è stato già descritto sopra.

PS: ogni riferimento a persone realmente esistenti è puramente casuale

[Mr_fox]

hai ragione