Blog

Seja bem-vindo

Espero que as dicas apresentadas aqui sejam úteis para você.
Se gostar de alguma coisa, não esqueça de comentar e recomendar, caso ache importante.

Currículo

domingo, 15 de junho de 2008

Associação, agregação e composição

Introdução

A orientação a objetos define que objetos podem se relacionar com outros para poder desempenhar suas tarefas, e a idéia deste breve post é explicar as diferenças entre alguns dos tipos de relacionamentos existentes, sendo estes associação, agregação e composição.
Espero que seja útil.


Associação

Em análise e projeto orientado à objetos, uma associação representa um relacionamento entre objetos. Por exemplo, vários alunos podem estar associados à um único professor e um único aluno pode estar associado à vários professores. Neste caso, não existe um relacionamento de posse entre esses objetos. Todos os objetos são independentes. Um aluno pode existir sem a necessidade de um professor, da mesma forma que é possível existir um professor sem a necessidade da existência de um aluno.


Agregação e Composição

Agregação e composição são tipos especiais de associações. Uma agregação representa um todo que é composto de várias partes. Exemplo: um conselho é um agregado de membros, da mesma forma que uma reunião é um agregado de uma pauta, uma sala e de participantes. A implementação deste relacionamento não é uma contenção, pois uma reunião não CONTÉM uma sala. Assim sendo, as partes da agregação podem fazer outras coisas em outras partes da aplicação, eles podem ser referenciados por outros objetos e não somente por um objeto. Em outras palavras, na implementação não há diferença entre agregação e um simples relacionamento “uses”. Nos dois casos, um objeto tem referências para outros objetos. Em UML, a agregação é representada por uma linha com um losango vazio do lado da classe que manda no relacionamento, como nas figuras abaixo.

A composição, diferentemente da agregação, é um relacionamento de conteção. Um objeto (container) CONTÉM outros objetos (elementos). Esses elementos que estão contidos dentro de outro objeto dependem dele para existir. Eles são criados e destruídos de acordo com o seu container. Um exemplo de container poderia ser uma nota fiscal, e seus elementos seriam seus itens. Não faz sentido existirem itens de nota fiscal sem existir uma nota fiscal onde tais itens estariam contidos. Eles só existem se existir uma nota fiscal da qual eles fazem parte. Se a nota fiscal é destruída, todos os seus itens também são, o que não acontece com a agregação, onde, se uma reunião é destruída, seus participantes continuam existindo, pois podem participar de outras reuniões.
A composição, na UML, é representada por uma linha com um losango preenchido do lado da classe dona do relacionamento, conforme mostrado na figura a seguir.


Referências

The Unified Modeling Language User Guide - Grady Booch, James Rumbaugh e Ivar Jacobson