este exemplo não é muito trivial… para composição prefiro adotar o exemplo de um carro por exemplo… um carro é composto por motor, bateria, freio, suspensão que são objetos essencias para a criação do carro… alguns objetos podem ser opicionais como: som, ar condicionado… etc… e outros são funcionais como freios, motor… etc… tanto uns como outros são feitos exclusivamente para comporem o carro… portanto se o carro não existir seus componentes tambem não iram existir…
Sinceramente não achei o exemplo da família correto para, metaforicamente, explicar a diferença entre composição e agregação.
Em OO o conceito é um pouco diferente.
Como bem disse o amigo:
O que não é verdade para o exemplo da família.
Exemplo prático de COMPOSIÇÃO:
NotaFiscal --> ItemNotaFiscal
Não existe o item se a NF não existe.
Exemplo prático de AGREGAÇÃO:
Carro --> Motor
O motor existe, independente do carro existir, pode até ser retirado de um e colocado em outro carro.
[quote=danieldestro]Sinceramente não achei o exemplo da família correto para, metaforicamente, explicar a diferença entre composição e agregação.
Em OO o conceito é um pouco diferente.
Como bem disse o amigo:
O que não é verdade para o exemplo da família.
Exemplo prático de COMPOSIÇÃO:
NotaFiscal --> ItemNotaFiscal
Não existe o item se a NF não existe.
Exemplo prático de AGREGAÇÃO:
Carro --> Motor
O motor existe, independente do carro existir, pode até ser retirado de um e colocado em outro carro.[/quote]
Hmm… um carro continua sendo um carro sem motor? Talvez se o exemplo fosse neon, xenon, adesivos 
Ele deixa de ser carro?
Ok, talvez um melhor exemplo para agregação fosse:
Cesta --> Frutas
O exemplo do carro sem motor, fica parecido com o do ser humano sem coração. Não bate muito bem.
Bom, ai estamos tratando de dois conceitos TOTALMENTE diferentes, e a capacidade de abstrair isso e levar para um modelo computacional é o que ajuda a criar um sistema mais conciso.
Concordo… por isto dei o exemplo do carro… outro exemplo pode ser um ser humano…
Composição: um homem e composto por coração, cerébro, nariz, ouvidos, figado… etc…
Agregação: ao homem pode ser agregado peças de vestuario como camisetas, calças, sapatos… etc…
Amigos, façam o mesmo que o Fowler e esqueça Agregação. O próprio Rumbaught disse "considere a agregação um placebo da UML". A agregação simplesmente é um relacionamento do tipo "parte-todo". Isso geralmente não tem efeito colateral no seu código. Exemplo:
Equipe < >----- Pessoa
Uma equipe nada mais é que um agrupamento de pessoas. Se isso for gerar confusão no seu projeto simplesmente esqueça isso. Já a composição, como vocês notaram, é uma associação muito forte, como se ambos os objetos trabalhassem como uma coisa única.
Pedido <#>------- ItemPedido
Não existe ItemPedido que não esteja associado a um Pedido e quando o Pedido morrer, todos os ItemPedido associados morrem junto.
Editado: A agregação não tem efeito colateral, a composição sim.
Rodrigo, não tem efeito colateral? Isso quer dizer que se eu tiver uma coleção de objetos que outro objeto acessa usando composição, mas quiser manter a lista de objetos mesmo quando o objeto que acessa a coleção for destruído não causará problema no meu código?
Eu sempre achei que sim…
Se bem que não faz muito sentido manter uma coleção de objetos que sempre foi e somente será acessada por um objeto. Estou certo nesse detalhe?
André, eu errei no texto e já editei… a composição tem efeito colareral a agregação não.