Newsgroup: it.comp.java
Titolo: [forse OT] Aggregazione debole & forte

Sto studiando da poco il paradigma OO ed il linguaggio Java,
non riesco a capire la differenza tra aggregazione debole & forte.
Il mio libro dice che una classe A e' aggregata con la classe B
se un oggetto di classe B contiene al suo interno un oggetto di
classe A.
In particolare l'aggregazione e' forte se gli oggetti contenuti
non possono sopravvivere senza l'oggetto contenitore.
Fin qui tutto ok, nella pratica pero' non so come venirne 
a capo ^_^
Per es:
//Finestra.java
class Bottone {...}
class Slider {...}
public class Finestra{
   Bottone butt;
   Slider sld;
 
   Finestra(Bottone b, Slider s){
      butt = b;
      sld = s;
   }
   public static void main(String[] args){
      Finestra fin = new Finestra(new Bottone(),new Slider());
   }
}
in questo caso si tratta sicuramente di aggregazione ^_^
ma di che tipo? non riesco praticamente a riconoscere tra
i due tipi di aggragazione.
Se volete potete fare due esempi migliori di aggr. debole
e forte perche' questo l'ho praticamente inventato.
Grazie anticipatamente ^_^

 i due tipi di aggragazione.
Aggregazione debole:
Scheda scheda = new Scheda("Intel", "PCI, ...);
Cpu cpu = new Cpu("Pentium", "900Mhz", ...);
...
new PC( scheda, cpu, video);
e nella classe PC hai il costruttore
PC(Scheda scheda, Cpu cpu);
Aggregazione forte (meglio nota come Composizione):
new PC("Intel", PCI, ..., "Pentium", "900Mhz", ecc.);
e nella classe PC hai il costruttore:
PC(String modelloScheda, String bus, ..., String cpu, ecc.)
Nel caso della forte, da fuori non puoi sapere che la classe PC crea e 
gestisce altri oggetti, che peraltro avranno la stessa vita della classe 
contenitore.
Nel caso della debole invece gli oggetti sono aggregati ma hanno 
possibili cicli di vita diversi.
HTH,
uL

 possibili cicli di vita diversi.
Ti ringranzio, la spiegazione e' stata molto convincente.
Se ho capito bene, anche nel primo dei tuoi esempi si 
potrebbe avere aggr. forte.
Invece di passare al costruttore di PC i riferimenti a Scheda
Cpu, Video basterebbe passare scheda.clone() cpu.clone(), 
video.clone() (supponendo che le relative classi implementino
l'interfaccia Cloneable).

 
mmm... non credo ci sia una risposta univoca.
Se consideri come hai strutturato la classe, l'aggregazione e' forte o 
debole perche' *puo'* esserlo. In un caso infatti il costruttore 
nasconde completamente la composizione del tutto, nell'altro espone le 
parti e le accetta come parametri.
Se consideri i singoli oggetti, passando dei cloni in effetti leghi il 
ciclo di vita del tutto alle sue parti, ottenendo in effetti una 
composizione.
Quindi dipende dai punti di vista: considerando "per classe", la 
risposta e' no: comunque la classe non incapsula completamente le sue parti.
Considerando "per oggetto", la risposta al tuo dubbio e' si.
Comunque guardala dal punto di vista dell'"information hiding": il 
costruttore della classe che accetta parametri come oggetti complessi 
nasconde meglio i dettagli implementativi e produce un accoppiamento 
minore. Di contro, puo' *non ottimizzare* il numero di oggetti prodotti, 
poiche' e' piu' difficile fare uno sharing.
Ma queste sono tutte chiacchiere accademiche, dal punto di vista del 
codice - quello importante - credo tu abbia colto correttamente i punti 
importanti!
HTH, ciao
uL

 composizione.
hai ragione, e se invece faccio in modo che sia il costruttore di PC
ad effettuare la clonazione dei riferimenti che gli vengono passati
allora sarebbe necessariamente composizione, vero?

 
Si, sarebbe piu' vicino ancora alla composizione teoricamente "ottimale"
con i parametri dei sottooggetti nel costruttore del tutto.
ciao
uL