Agregação e Composição

Fala ai nanduuuu blz…

Cara pra tentar de ajudar em seu problema, vou tentar te explicar, e espero que não complique mais.

Por exemplo um relacionamento entre uma escola e alunos, neste relacionamento vc terá uma agregação, pois
poderá ter varios alunos em uma escola ou varios alunos em varias escolas.

Agora um relacionamento entre departamenos de uma escola e a escola, neste vc terá uma composição,
pois vc não poderá ter um departamento sem que tenha uma escola.

Espero ter ajudado.

Opa blz sim joaosouza^^

entendi sim a sua colocaçao

Agora deixa eu fazer mais uma pergunta:

A implementação de agregação é muito diferente da implementação para composição?

Ou vice-versa^^

Olá. Eu também fui aluno da UTFPR.

Embora o conceito seja diferente, a implementação dos dois pode até mesmo ser igual.

No caso da composição, é muito comum encontrarmos a classe agregadora (carro, por exemplo) criando as instâncias da classe agregada, peça. Também é comum encontrarmos peça como uma inner class de clarro. Você também vai notar que o uso da classe peça é mais intenso pelo carro. Na verdade, parte dos métodos estarão implementados de forma que, sem uma peça, a classe carro simplesmente não funcionará. Classes compostas geralmente estão em pacotes muito próximos e correlatos.

Note que nada disso é obrigatório. A UML é um padrão que descreve os conceitos envolvendo as classes e muitos desses conceitos podem ter implementações idênticas. O que separa os relacionamentos é o grau de acoplamento da classe agregada com a agregadora, não tanto a implementação.

Obrigado ViniGodoy por seus esclarecimentos.

Quanto a agregação ficou muito claro e entendi tb que os dois podem ser de igual implementação.

Mas quanto a Equipe e jogador como poderia ser explicada ai uma implementação de composição?

Mais uma vez agradeço o esclarecimento de vocês.

Quando terminar e apresentar posto aqui meu projeto completo…

Um Modo Fácil De Vc Pensar

Existem 3 Regras Que Devem Serem Satisfeitas Para Ser Considerada Composicao:

A- Somente Uma Classe Pode Ser Representada Como “Todo”

B- As Partes Do “Todo” So Existem Enquanto O Todo Existir

C- Uma Parte Pode Representar Um “Todo” De Cada Vez

Se Falhar Pelo Menos Uma Dessas É Considerado Agregacao

Em Uml: Losango Preenchido (Composicao)
Losango Vazio (Agregacao)

Para Vc Implementar :

Deverá Declarar Como Tipo Do Atributo (Membro De Dados Ou

Variaveis De Classe Ou Variaveis De Instância) Da Classe Que

Vc Esta Projetando Como Se Fosse Um Tipo Primitivo

(Fundamental Ou Pré Definido Se Vc Vem Do “C”)

Boa explicação JGame:

No caso de Equipe pra jogador entao:

1. Uma equipe não vive sem jogadores;

2. Se não existe equipe, não existe jogador;

3. Esta não consegui interpretar bem^^

Quanto a UML é tranquilo…

Desculpe se estou questionando d+, é que gosto de entender bem sobre um determinado assunto

Não conhecia essas regras. Também não entendi a regra C.

Eu geralmente separo assim. A composição é uma relação visceral, ou seja, o objeto composto é parte praticamente física do objeto que o contém. Portanto, ele não poderá ser compatilhado (ou raramente). Também não há sentido em falar do objeto sem o seu componente (consegue imaginar um carro sem motor? Ou que tal dois carros compartilhando o mesmo motor?)

Já um jogador pode estar em duas equipes ao mesmo tempo. Uma equipe pode até ficar temporariamente sem membros, que continuará existindo conceitualmente. Falando em implementação, é provável que a classe equipe possa ser instanciada sem a presença de um único membro sequer, ser cadastrada num banco e ficar num estado de “inativa” até que os membros apareçam.

Enquanto a classe Carro provavelmente receberia um motor no construtor, ou instaciaria seu próprio motor. Ou seja, não existiria sem ele.

A relação de composição é mais forte. Se for escolher entre as duas, opte pela agregação, a menos que seja imprescindível fazer composição.

nanduuuu:

Boa explicação JGame:

No caso de Equipe pra jogador entao:

1. Uma equipe não vive sem jogadores;

2. Se não existe equipe, não existe jogador;

3. Esta não consegui interpretar bem^^

Quanto a UML é tranquilo…

Desculpe se estou questionando d+, é que gosto de entender bem sobre um determinado assunto

( 3- Uma Parte Só Deve Pertencer a Um Todo Naquele Momento)

Implementacao: Independente De Ser Composicao Ou Agregacao Ela É Feita Da Mesma Forma -(Conforme Te Passei Acima)

---

O Que Vou Te Passei E Vou Te Passar Agora Vem Com a Experiência->Ok
Respondendo À Outros Também Como O Vinícios

• Logicamente Se Vc Tem Ou Nao Experirência E Vai Ler Uma Determinada Literatura Poderá Se Confundir Todo - Nenhum Único Livro Te Explica Isso Que Te Passei - “Guarde Com Carinho”

Sinônimos:

Atributo(Jargao-Em Uml)==Membro De Dados(Jargao Do C++)

Variável De Estância (Jargao Utilizado Nas Classes

Que Inicializam Objetos) == Variáveis De Classe (

Jargao Utilizado Para Variáveis Compartilhadas Para

Todos Os Objetos Criados)

Sinônimos:

Tipo Fundamental ( Generalizados À Todas Ling

Tipificadas) == Tipo Pré-Definido (Jargao Utilizado

Muito Em C) == Tipo Primitivo (Jargao Utilizado Em Java)

Games

Desculpe retomar esta discussão, mas não é exatamente o contrário?
Estou perguntando pq estou aprendendo e eu jurava que era a composição que causa o forte acoplamento, e a agragação é quando são objetos independentes… estou errado?

Desculpe retomar esta discussão, mas não é exatamente o contrário?
Estou perguntando pq estou aprendendo e eu jurava que era a composição que causa o forte acoplamento, e a agragação é quando são objetos independentes… estou errado?

Ops, é ao contrário sim. Vou corrigir ali em cima. Bem observado.