Associação agregação e composição
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.
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
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
alternative link download
