Você já se perguntou o que é o relacionamento de Agregação entre Classes?
É algo que parece abstrato, mas é mais simples do que imaginamos.
Mas o uso inadequado da Agregação gera Alto Acoplamento e Baixa Coesão na estrutura de um software.
Este é o terceiro post sobre relacionamentos entre classes na UML – aqui você pode ver o primeiro sobre Dependência entre Classes, e aqui pode ver o segundo sobre Composição entre Classes.
Agregação na vida real
Como já citei em outros posts, sempre que pensamos em Orientação a Objetos devemos entender que o objetivo deste paradigma é refletir na estrutura do software a vida real do problema que o software busca resolver.
Vamos imaginar uma casa. Uma casa possui telhado e paredes, e não existe sem isso. Logo, uma casa é composta de telhado e paredes.
/* Num relacionamento de Composição podemos entender que classes que são compostas por outras precisam destas para “viver”, para “existir”. Por exemplo, a classe Coração compõe a classe Corpo Humano. Sem o coração o corpo humano não vive. */
Mas uma casa existe, vive sem um espelho. Mas casas tem espelhos.
Neste contexto, o Espelho é uma Agregação, agrega-se à Casa.
Se a casa dependesse do Espelho para existir, então seria uma Composição.
E se a casa fosse feito de Espelhos, fosse esta sua matéria prima, então seria uma Herança.
São três forma de pensar um mesmo conceito, mas são semanticamente muito diferentes.
/* Num relacionamento de Agregação, podemos entender que classes que são agregadas por outras não precisam destas para “viver”, para “existir”. Por exemplo, a classe Unha agrega a classe Corpo Humano. Sem a unha o corpo humano vive sem grandes dificuldades. */
Agregação na UML e OOP
Agregação e Composição, que são relacionamentos de Associação, não são relacionamentos nativos da Orientação a Objetos. São utilizados na UML para representar modelos estruturais codificados no software.
Quando ocorre a implementação do código fonte, para a maioria das linguagens mais atuais este relacionamento é um tanto transparente, pois baseia-se apenas na utilização de um atributo na classe.
O diagrama de classe é que demonstra melhor a relação utilizada, bem como a multiplicidade aplicada.
Apenas lembrando, estas relações aplicam-se apenas a atributos de tipos complexos (ou tipo compostos), não aplicam-se a atributos de tipos primitivos.
Nesta imagem, Endereço e Contrato podem ser composições ou agregações, dependendo do que está modelado no diagrama relacionado à classe ClienteEntidade.
UML e Agilidade
Agilidade não é produzir software com pressa, é produzir software com velocidade, entregando valor no menor espaço de tempo possível, e melhorando isso continuamente.
Para ser ágil, é fundamental ser eficiente.
Não é plausível falar em agilidade sem eficiência, com desperdício.
Em projetos de software, um dos maiores desafios é a boa comunicação.
Deixar claro o que se quer, o que será entregue, como será produzido etc. Isso não é simples quando produzimos software, devido à complexidade inerente a esta atividade.
Quando se entende um requisito do jeito errado, sempre há o custo de fazer errado, desfazer, e fazer certo. Obviamente, este tipo de desperdício custa 3 vezes mais que se tivéssemos feito certo da primeira vez.
E neste contexto, fica claro que o uso racional de diagramas UML com o objetivo de transmitir ideias entre membros de um mesmo time, é uma ferramenta que favorece muito uma cultura ágil.
Exemplos
Nesta imagem temos a Classe Casa. Mas projetada da forma incorreta.
Cada classe deve ter apenas uma responsabilidade, e esta classe Casa possui responsabilidades que não são suas, pois possui coisas de Telhado, que é outra Entidade (conceitualmente falando), que deve possuir nela tudo referente a telhado.
E isso gera Alto Acoplamento, pois insere em Casa o que é de Telhado, além de ter também Baixa Coesão, pois mistura o conceito de Telhado com o conceito de Casa.
Vejamos abaixo a forma correta de modelar a classe Casa, com uma boa Separação de Responsabilidades, fazendo com que o modelo viabilize um software com Baixo Acoplamento e Alta Coesão.
Podemos ver que a classe Casa agora não possui mais coisas que são de responsabilidade de Telhado, pois isso está em uma classe separada. Lembrando que Casa precisa de Telhado para existir.
Mas Casa não precisa de Espelho para existir.
Logo, fizemos uma agregação da Classe Espelho para a classe Casa (Espelho agrega Casa).
Se excluirmos do modelo a classe Espelho, isso não vai deixar nossa Casa com problemas, pois espelho é um plus, não é algo essencial para a Casa existir.
Para melhorar o estudo, segue abaixo um vídeo, onde temos uma aula rápida explicando a aplicação da Agregação.
Concluindo
Softwares devem ser modelados antes de ser construídos, mesmo que apenas suas partes mais críticas. E na modelagem todo Analista de Sistemas deve ter como mantra a ideia de Fraco Acoplamento e Alta Coesão.
E quanto o assunto é Orientação a Objetos e UML, usar corretamente os relacionamentos entre classes na Modelagem é pré-requisito para isso virar realidade.
Se você gostou do conteúdo deste post, deixe seus comentários, para ajudar outras pessoas a encontrarem este material! 🙂
Grande abraço!