Ooopss... acho que não é bem isto...

Uma agregação é uma especialização de uma associação, a diferença é que em uma
agregação, o ciclo de vida das instancias "parte" estão fortemente relacionadas a
instancia da parte "todo".

Olhando as classe abaixo é impossível saber se o que existe entre elas é uma
associação ou uma agregação...

class Departamento {
    String nome;
    Funcionario diretor;
    List funcionarios;
    // Gets e sets para atributos..
}

class Funcionario {
    String nome;
}

Sugiro outro teste para comprovar isto: pegue uma ferramenta de modelagem OO com
suporte a UML é crie dois diagramas de classe com estas classes, em um diagrama use
agregação e no outro associação e veja o codigo gerado.

Leonardo.
....................................................
Leonardo Souza Mario Bueno
itera Informática
[EMAIL PROTECTED]
Phone: 55 27 337 0317
Cell: 55 27 9971 1375
Visit our website at:
http://www.itera.com.br
....................................................
----- Original Message -----
From: valter vieira de camargo <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 14, 2001 7:10 PM
Subject: Re: RES: [java-list] Para Alexandre: implementação de agregações e
associações


> Sobre as associações e agregações eu estou achando que é realmente isto:
> agregação - atributo do tipo de outra classe
> associação - instanciação de uma classe dentro de algum método de outra...
>
> Quanto à abordagem do Furlan... será que se modelarmos um sistema completamente
> OO sem a preocupação com chaves, etc.... a dificuldade na implementação será
> muito acentuada, você não acha ? Eu estou desenvolvendo um projeto de mestrado e
> quero fazer da maneira certa entende ? A minha outra preocupação é quanto ao
> projeto ..... no modelo de classes de análise tudo bem ... mas o meu modelo de
> classes de projeto tem que ter alguma coisa relacional....
>
>
> Alexandre Rodrigues Gomes wrote:
>
> > Valter,
> >
> > na implementação acho que poderíamos resumir na seguinte forma:
> > para agregar, utilizaremos atributos de instância, ou seja,
> > "variáveis globais" e para associação podemos criar apenas
> > variáveis locais de métodos. Será que é plausível esta abordagem ?
> > Se bem que podemos ter atributos de classe que não são verdadeiras
> > agregações mas apenas realizam papel associativo. Acho que
> > isto é bem conceitual mesmo. O pessoal da lista podia dar
> > uma forcinha.....
> >
> > Quanto àquela abordagem do Furlan, eu questiono um pouco.
> > Ora, temos hoje que o que se busca é a independência da fonte
> > de dados. Devemos abstrair a forma com que a base de informações
> > será implementada, nos deter apenas numa interface pré-definida
> > e deixar as questões peculiares de cada banco com uma camada
> > de software que realize o mapeamento OO/Relacional. Amarrar
> > o seu modelo de negócios numa solução única de backend é
> > limitar seu processo de desenvolvimento à não escalabilidade
> > e evolução.
> >
> > By Alê!
> >
> > -----Mensagem original-----
> > De: valter vieira de camargo [mailto:[EMAIL PROTECTED]]
> > Enviada em: quarta-feira, 14 de março de 2001 10:48
> > Para: [EMAIL PROTECTED]
> > Assunto: [java-list] Para Alexandre: implementação de agregações e
> > associações
> >
> > Ok... Alexandre ...
> >               É justamente no ponto da implementação a minha preocupação....
> >               Gostei do que você disse e acho que realmente está certo.
> > Minhas dúvidas eram mais quanto à  implementação das associação. E também
> > ach
> > oque é assim que funciona.... isto é, dentro de uma classe , instancio uma
> > outra e a utilizo para cumprimento das responsabilidades da primeira.
> >         No caso da agregação, um atributo da classe é do tipo de outra....
> >         É isto, não é ?
> >
> >         Agora veja bem.
> >
> >         Em um livro de UML do Furlan, encontrei que para se fazer a
> > normalização de um modelo de classes, visando o projeto é claro, deve-se
> > basear em algum tipo de banco de dados será utilizado. Se os dados do meu
> > sistema serão persistidos utilizando BD OO a normalização se dá sem a
> > preocupação das chaves primárias e estrangeiras... mas quando o me sistema
> > utiliza BD relacional devo me preocupar com isso... só que ele apenas
> > exemplifica a normalização utilizando BD OO. Você sabe alguma coisa sobre
> > essas normalizações com BD relacional ?
> >
> > []'s Valter.
> >
> > Alexandre Rodrigues Gomes wrote:
> >
> > > Valter,
> > >
> > > no nível de linguagem, tanto agregação quando associação
> > > se dão de maneiras similiares. O que as distingue é o seu
> > > modelo. Na UML, a associação é feita apenas com uma linha
> > > ligando as classes envolvidas enquanto que a agregação é
> > > uma linha com um losango na ponta da classe agregadora.
> > >
> > > Conceitualmente, deveria-se utilizar agregação quando o
> > > propósito de uma classe for o de encapsular o funcionamento
> > > de algum objeto, ou seja, ele será parte constituinte daquela
> > > classe. No caso da associação, a classe apenas tem conhecimento
> > > de alguma outra classe e faz uso de alguma instância desta para
> > > completude de suas responsabilidades.
> > >
> > > No primeiro capítulo do livro do Gamma (Design Patterns),
> > > ele dá uma descrição legal sobre a utilização destas duas
> > > alternativas.
> > >
> > > Abraços,
> > > By Alê!
> > >
> > > -----Mensagem original-----
> > > De: valter vieira de camargo [mailto:[EMAIL PROTECTED]]
> > > Enviada em: terça-feira, 13 de março de 2001 19:38
> > > Para: [EMAIL PROTECTED]
> > > Assunto: [java-list] implementação de agregações e associações
> > >
> > >         Visto que é comum a utilização de linguagens orientadas a
> > > objetos e banco de dados relacionais, pretendo estipular um padrão de
> > > implementação para tais casos de modelagem.
> > >         Estou desenvolvendo uma pesquisa com java e SyBase e devido as
> > > diferenças entre os dos paradigmas algumas dúvidas surgem.
> > >         Eu gostaria de saber a diferença entre a implementação de um
> > > modelo de classes com agregação e com associação. Percebo que a
> > > agregação é fácil identificar, isto é, quando uma classe possui um
> > > atributo cujo tipo é de outra classe. Mas e quando temos uma associação
> > > ? Como vocês implementam uma associação sendo fiel à documentação ?
> > >
> > > Valter
> > >
> > > ------------------------------ LISTA SOUJAVA ----------------------------
> > > http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
> > > dúvidas mais comuns: http://www.soujava.org.br/faq.htm
> > > regras da lista: http://www.soujava.org.br/regras.htm
> > > para sair da lista: envie email para [EMAIL PROTECTED]
> > > -------------------------------------------------------------------------
> > >
> > > ------------------------------ LISTA SOUJAVA ----------------------------
> > > http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
> > > dúvidas mais comuns: http://www.soujava.org.br/faq.htm
> > > regras da lista: http://www.soujava.org.br/regras.htm
> > > para sair da lista: envie email para [EMAIL PROTECTED]
> > > -------------------------------------------------------------------------
> >
> > ------------------------------ LISTA SOUJAVA ----------------------------
> > http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
> > dúvidas mais comuns: http://www.soujava.org.br/faq.htm
> > regras da lista: http://www.soujava.org.br/regras.htm
> > para sair da lista: envie email para [EMAIL PROTECTED]
> > -------------------------------------------------------------------------
> >
> > ------------------------------ LISTA SOUJAVA ----------------------------
> > http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
> > dúvidas mais comuns: http://www.soujava.org.br/faq.htm
> > regras da lista: http://www.soujava.org.br/regras.htm
> > para sair da lista: envie email para [EMAIL PROTECTED]
> > -------------------------------------------------------------------------
>
>


------------------------------ LISTA SOUJAVA ---------------------------- 
http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP 
dúvidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
para sair da lista: envie email para [EMAIL PROTECTED] 
-------------------------------------------------------------------------

Responder a