OO - Associação, Composição e Agregação

[Guilherme_90 33]

Boa noite pessoal! Bom, desculpem se este tópico for repetido porém preciso de uma ajuda!

Já fiz várias pesquisas e li bem a respeito dessas três "regras" dos princípios do OO, mas a minha dúvida é a seguinte: Quando vou saber usar cada um dos casos, no mundo real? Quando eu aplico isso no desenvolvimento de sistema?

 

Eu sei usar na prática apenas, mas quero entender realmente o motivo e por que usar tal método pra tipo de caso. Alguém poderia me ajudar nisso? Ahh, se puder, mostre exemplos de mundo real, e não aqueles que não são aplicados no dia-a-dia, pois assim acredito que ficará mais fácil entender.

 

Muito obrigado.

[João Batista Neto 448]

Boa noite pessoal! Bom, desculpem se este tópico for repetido porém preciso de uma ajuda!

Já fiz várias pesquisas e li bem a respeito dessas três "regras" dos princípios do OO, mas a minha dúvida é a seguinte: Quando vou saber usar cada um dos casos, no mundo real? Quando eu aplico isso no desenvolvimento de sistema?

 

Eu sei usar na prática apenas, mas quero entender realmente o motivo e por que usar tal método pra tipo de caso. Alguém poderia me ajudar nisso? Ahh, se puder, mostre exemplos de mundo real, e não aqueles que não são aplicados no dia-a-dia, pois assim acredito que ficará mais fácil entender.

 

Muito obrigado.

 

Primeiro, não são regras, são formas de relacionamento entre os objetos.

 

 

O primeiro relacionamento é uma associação simples, uma empresa pode ter 1 ou N funcionários. Se um funcionário morrer, a empresa não deixará de funcionar.

 

O segundo relacionamento chama-se agregação, se tirarmos as rodas do carro, ele não andará, mas também não deixará de existir, assim como as rodas não deixarão de existir.

 

O terceiro relacionamento chama-se composição, é o relacionamento mais forte que temos. Se cortarmos a cabeça, Fulano morre. Da mesma forma, se removermos um capítulo de um livro, vamos estragá-lo.

 

[Guilherme Oderdenge 42]

O terceiro relacionamento chama-se composição, é o relacionamento mais forte que temos. Se cortarmos a cabeça, Fulano morre. Da mesma forma, se removermos um capítulo de um livro, vamos estragá-lo.

Eu sempre achei isso meio controverso, porque apesar de removermos o capítulo de um livro, ele [o livro] não deixa de existir.

[João Batista Neto 448]

Eu sempre achei isso meio controverso, porque apesar de removermos o capítulo de um livro, ele [o livro] não deixa de existir.

 

Então vou lhe dar um livro de Agatha Christie para ler, mas vou remover o capítulo final. Assim que você lê-lo, quero que você me diga o que achou do livro.

 

[Guilherme Oderdenge 42]

Mas o livro continua existindo. :thumbsup:

[João Batista Neto 448]

Mas o livro continua existindo.

 

Se você não pode lê-lo, ele não é um livro, mas um monte de papel. A definição de composição é algo cuja importância é fundamental para a funcionalidade de outra. Mesmo que uma dessas coisas NÃO seja destruída, mas apenas removida sua funcionalidade. Se a outra coisa perder sentido, então trata-se de uma composição.

[Gabriel Heming 766]

Mas o livro continua existindo. :thumbsup:

A "pessoa" também... Mas a pessoa não "funciona" sem uma cabeça e uma cabeça não funciona sozinha. Do mesmo modo que um capítulo é apenas uma parte, extremamente importante de um romance, e um romance, sem um capítulo, não é a mesma coisa.

 

Leia o prefácio do livro Dança da Morte do Stephen King, então você entenderá o que faz a falta de um capítulo no livro (foram cortadas 150.000 palavras do manuscrito original para a primeira versão impressa, coisa de 500 páginas. Anos depois foi lançada a versão completa).

[Prog 183]

Os conceitos estão exemplificados. Não prenda-se a coisas como "eu acho", "eu vejo", "eu sei" então "só pode ser assim"... isto não é, necessariamente, verdade.

 

Num processo editorial, não faz sentido um livro sem um capítulo, ele continua funcionando e existindo? Sim, mas para o livro ser editado, este não pode sair incompleto.

 

A cabeça não pode funcionar sem o corpo? Não, mas quem disse que ela necessariamente precisa funcionar ou que estamos modelando o funcionamento correto de um corpo humano? Pode-se utilizar como exemplo um modelo para um sistema de necrotério ou um sistema para o mundo de Futurama.

 

Cada contexto recebe um modelo, e este modelo não necessariamente esta relacionado ao mundo que você vive ou conhece.

[Guilherme_90 33]

Wercks Oliveira

Parece que consegui entender. Em resumo, a associação não depende de outro objeto funcionar? Que no caso, você fez uma agragação no construtor "umSite" passando o objeto Pessoa, e atravéz desse, você chama seus métodos, já que o objeto "pessoa" está sendo criado.

 

Está certo?

 

João Batista Neto

Tá, mais eu juro que não consigo enxergar isso na prática, desculpe. :unsure:

 

Se você não pode lê-lo, ele não é um livro, mas um monte de papel. A definição de composição é algo cuja importância é fundamental para a funcionalidade de outra. Mesmo que uma dessas coisas NÃO seja destruída, mas apenas removida sua funcionalidade. Se a outra coisa perder sentido, então trata-se de uma composição.

 

PARECE que agora tá começando a cair a ficha. Então a composição aplica-se ao uso de interfaces? Onde toda classe que a implementa, terá os métodos sendo obrigados a implementa-los e inserir algoritmos diferentes? :pinch:

 

<?
interface Action{
    public function floor();
    public function run();
}

class ObjectAction{

    public function setAction(Action $interface){
         $interface->floor();
         $interface->run();
    }

}

class Car implements Action{

    public function floor(){
         echo 'O carro esta andando...';
    }

    public function run(){
         echo 'O carro esta correndo...';
    }

}

class People implements Action{

    public function floor(){
         echo 'Uma pessoa esta andando...';
    }

    public function run(){
         echo 'Uma pessoa esta correndo...';
    }

}

$object = new ObjectAction();
$car = $object->setAction(new Car());
$people = $object->setAction(new People());
?>

[Guilherme Oderdenge 42]

É por isso:

Wercks Oliveira

Parece que consegui entender. Em resumo, a associação não depende de outro objeto funcionar? Que no caso, você fez uma agragação no construtor "umSite" passando o objeto Pessoa, e atravéz desse, você chama seus métodos, já que o objeto "pessoa" está sendo criado.

 

Está certo?

 

João Batista Neto

Tá, mais eu juro que não consigo enxergar isso na prática, desculpe. :unsure:

 

 

 

PARECE que agora tá começando a cair a ficha. Então a composição aplica-se ao uso de interfaces? Onde toda classe que a implementa, terá os métodos sendo obrigados a implementa-los e inserir algoritmos diferentes? :pinch:

Que eu questionei sobre a composição, João, Gabriel e Prog.

 

Antes de muito tempo me batendo com OOP, foi só então que eu entendi isso. As explicações para associação, composição e agregação eram, até então, muito vagas. Respostas tipo as a seguir inexistiam:

Se você não pode lê-lo, ele não é um livro, mas um monte de papel. A definição de composição é algo cuja importância é fundamental para a funcionalidade de outra. Mesmo que uma dessas coisas NÃO seja destruída, mas apenas removida sua funcionalidade. Se a outra coisa perder sentido, então trata-se de uma composição.

 

 

A "pessoa" também... Mas a pessoa não "funciona" sem uma cabeça e uma cabeça não funciona sozinha. Do mesmo modo que um capítulo é apenas uma parte, extremamente importante de um romance, e um romance, sem um capítulo, não é a mesma coisa.

 

Leia o prefácio do livro Dança da Morte do Stephen King, então você entenderá o que faz a falta de um capítulo no livro (foram cortadas 150.000 palavras do manuscrito original para a primeira versão impressa, coisa de 500 páginas. Anos depois foi lançada a versão completa).

Então, portanto, o questionamento.

 

Obrigado por esclarecerem. :thumbsup:

[Bruno Augusto 417]

O maior problema dos conceitos da Orientação a Objetos é a falta de exemplo reais e a existência em quantidade assustadora de exemplos abstratos demais.

 

Eu por exemplo nunca vi uma aplicação MVC "normal" que utilizasse de forma clara e objetiva associação e composição.

 

A agregação é o mais fácil de ser ver através da DI, agregando objetos à outros.

 

Agora estudando frameworks, criando códigos-base para outras aplicações é outra coisa, pois esses conceitos ficam perfeitamente visíveis em diversos cenários.

[Gabriel Heming 766]

Prog

 

É bem interessante demostrar esse ponto de vista. Pois baseado em certo contexto.

 

Outro exemplo, são dos órgãos, ou músculos (caso do coração), do corpo humano. Do mesmo modo que um órgão pode ser transplantado de uma pessoa para a outra, isso não significa que é uma agregação. Do ponto de vista "original", digamos assim, uma pessoa não vive sem um coração e não faz sentido um coração sem corpo (não falaremos de casos/caras como Hannibal Lecter :pinch:/> ).

[Guilherme Oderdenge 42]

Pois é, Bruno. Os exemplos que eu conhecia sobre OOP eram sobre pais e filhos, marcas de carros e animais. Na verdade, até hoje é assim e por isso existe tanta dificuldade por parte dos leigos de aprender o tão aclamado OOP.

[Gabriel Heming 766]

Eu por exemplo nunca vi uma aplicação MVC "normal" que utilizasse de forma clara e objetiva associação e composição.

Uma loja virtual usa facilmente composição e associação. Um produto, quando inserido em uma cesta, torna-se um item da cesta e não mais apenas um produto. Apesar de ser implícito o produto se tornar um item da cesta, sem a cesta, ele é apenas um produto comum. Quando se torna um item da cesta, ele possui alguns detalhes novos, como o de quantidade (isso em uma cesta virtual, não a de supermercado).

 

A questão de associação, pode ser como permissões de usuários. Um usuário possui permissão a determinados módulos, caso ele perca a permissão de um módulo apenas, tanto usuário quanto módulo continuarão existindo, mas as associações serão diferentes.

 

Utilizamos implicitamente os conceitos, e só depois percebemos que, de alguma forma ou de outra, já havíamos utilizado eles.

[João Batista Neto 448]

Um produto, quando inserido em uma cesta, torna-se um item da cesta e não mais apenas um produto.

 

Produto e cesta é uma agregação, não composição.

 

O produto independe da cesta, assim como a cesta independe do produto. Posso adicionar e remover produtos da cesta, no instante que eu quiser.

[Gabriel Heming 766]

Há um exemplo aqui, similar, que afirma ser uma composição. A diferença se dá do fato de ser um pedido e um item de pedido.

http://imasters.com.br/artigo/18901/uml/uml-composicao-x-agregacao

 

Eu acho que deveria ter mudado de cesta para pedido... O fato da cesta sempre existir sim, mas o pedido só existe quando existir produtos. Quando me referi a cesta, me referia como um pedido. Foi um equívoco da minha parte.

[João Batista Neto 448]

Apenas mantendo a linha do e-commerce, veja só:

 

Loja e produtos :seta: é uma associação, uma loja pode ter N produtos.

 

Produtos e cesta de compras :seta: é u ma agregação, o cliente pode adicionar N produtos à cesta. Pode removê-los no instante que quiser. Pode voltar a adicionar o produto no instante que quiser. Mas só faz checkout se houver pelo menos 1 produto na cesta.

 

Botão para fechar pedido e layout da loja :seta: é uma composição. O botão sozinho, em uma página em branco, não tem sentido algum. Se eu remover o botão da página de checkout, ninguém consegue fazer compras.

 

É bastante simples, basta ver a funcionalidade que um participante representa no todo. Se a funcionalidade do participante for fundamental para o funcionamento do todo, então trata-se de um relacionamento de composição. O participante X compõe o todo.

 

Há um exemplo aqui, similar, que afirma ser uma composição. A diferença se dá do fato de ser um pedido e um item de pedido.

http://imasters.com....cao-x-agregacao

 

Eu acho que deveria ter mudado de cesta para pedido... O fato da cesta sempre existir sim, mas o pedido só existe quando existir produtos. Quando me referi a cesta, me referia como um pedido. Foi um equívoco da minha parte.

 

Existe uma diferença MUiTO importante entre carrinho e pedido. O pedido é um ato consumado. Se eu removo um item de um pedido já feito, então eu estraguei o pedido e terei que fazer um novo, por isso é, de fato, uma composição. O item do pedido compõe o pedido.

 

Por outro lado, na cesta de compras, o pedido ainda não aconteceu e posso adicionar e remover itens da cesta quando eu quiser. Por isso, trata-se de agregação.

[Bruno Augusto 417]

Saudade desse tipo de discussão.

 

Acho que podemos traduzir Associação, Agregação e Composição em perguntas a serem feitas ao Objeto a fim de definir o contexto em que tais objetos se encontram: pode ser, tem e é, respectivamente.

 

Se um objeto pode ser uma coisa em determinado contexto, então o contexto é uma Associação.

 

Se um objeto tem uma coisa, seja ela um objeto ou não, então o contexto é uma Agregação.

 

Se um objeto é uma coisa ou parte de uma coisa, então o contexto é uma Composição.

[João Batista Neto 448]

Se um objeto pode ser uma coisa em determinado contexto, então o contexto é uma Associação.

 

Se um objeto tem uma coisa, seja ela um objeto ou não, então o contexto é uma Agregação.

 

Se um objeto é uma coisa ou parte de uma coisa, então o contexto é uma Composição.

 

TUDO, Bruno, é associação. Simples assim.

 

Para identificar qual associação é, você deve observar os participantes. Pense em uma roda (de carro mesmo).

 

Se a roda estiver em uma loja que vende rodas, então é uma associação simples, a loja vende rodas.

Se a roda estiver no carro, então ela agrega o carro.

Se você comprar uma nova roda na loja que vende rodas, a roda que você comprou compõe o pedido feito na loja.

 

O mesmo participante "roda" pode estar associado, agregando ou compondo alguma coisa. Por isso é importante observar todas as partes envolvidas. Dependendo do contexto, pode ser uma coisa ou outra.

 

EDIT:

 

Quando eu digo tudo, quero dizer TUDO MESMO. Como orientação a objetos é um paradigma de programação onde N objetos colaboram com suas funcionalidades para que tenhamos uma aplicação, os objetos compõem a orientação a objetos, de forma que, se você tiver apenas 1 objeto, você não tem uma aplicação orientada a objetos. Os objetos precisam se relacionar uns com os outros. Esse relacionamento dos objetos, em orientação a objetos, chama-se associação. Algumas associações são mais fortes, outras mais fracas. Você precisa identificar a funcionalidade que um conjunto de objetos provê para, somente então, "dar nome aos burros".

[Guilherme_90 33]

Explicação melhor que essa do João Batista, difícil achar. Agora sim estou entendendo, era justamente disso que eu estava falando!

+1 pra você, e para todos que colaboraram com este tópico.

 

É disso que nós precisamos, compartilhar conhecimento!