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

[Felipe Rex 12]

Olá colegas, estive há tempos pesquisando sobre Orientação a Objeto e estive lendo alguns livros sobre o assunto aplicado a PHP que ajudaram em partes. Consegui criar classes para resolver alguns problemas... mas no fundo eu sei que essas classes não estão projetadas de forma correta.

 

Recentemente quis aperfeiçoar o meu entendimento de Orientação e fiz o curso de 'Introdução a programação orientada a objeto' na escola Impacta. O Curso foi muito bom, embora teórico. Agora estou com 4 fontes de matérias estudando associações e gostaria de ver com vocês se estou pensando de forma correta quanto aos conceitos de OOP.

 

 

Vamos lá, o meu entendimento foi o seguinte:

 

Polimorfismo

Ocorre quando classes derivadas fazem implementação de um método da classe-base, tornando o método herdado com comportamentos diferente. Ou seja, as classes-filhas de uma classe-base terá o mesmo método, mas com comportamentos diferentes.

 

Exemplo:

 

 

-----

 

Agregação

 

É um relacionamento entre classes onde se tem uma classe-todo e outras classes que são 'partes dela'. A Agregação ocorre quando um método na classe-todo incorpora uma outra classe que faz parte do todo. Ou seja, a classe-todo possui um método cujo parâmetro recebe um objeto (uma outra classe) que se torna 'parte' dela.

 

Uma dúvida que fiquei na agregação é: Uma classe que faz parte de outra classe (classe-todo) pode existir sem a classe-todo? Na apostila que estou lendo, diz que uma classe-parte não pode existir isoladamente (sem a existência da classe-todo), isso é verdade? Eu não posso ter uma classe-parte sem existir a classe todo?

 

 

Exemplo:

 

Nota: Neste exemplo de uml, eu entendo que as classes-parte (video, teclado e gabinete) não podem existir se a classe-todo Micro não existir... mas essa é a ideia da agregação? Se objeto-todo não existir, os objetos-partes não devem existir também?

 

 

-------

 

 

 

Logo mais posto a respeito de associação simples e composição para ver se estou no pensamento certo.

 

 

Obrigado a todos que colaborar em ajudar e me orientar se estou no caminho certo.

[Gabriel Heming 766]

isso é verdade? Eu não posso ter uma classe-parte sem existir a classe todo?

Isso seria verdade se estivesse falando de Composição.

 

Pelo que entendo de agregação e composição, eles possuem conceitos parecidos, mas não iguais. A diferença, entretanto, é que, na composição, as "partes" não podem existir sem o TODO e na agregação sim.

 

Exemplo de agregação:

A rodas agregam um carro. Apesar do carro estar incompleto, você pode possuir um carro sem rodas (mesmo que ele não ande), como pode possuir rodas sem um carro.

 

Exemplo de composição:

Os dedos compõem a mão. Você não pode possuir dedos sem possuir uma mão.

 

Este post do João Batista Neto possui uma ótima explicação.

http://forum.imasters.com.br/topic/458278-como-pensar-em-orientacao-a-objetos/page__view__findpost__p__1815097

[Gabriel Heming 766]

Não havia tempo para eu falar mais, vim agora '-'

eu entendo que as classes-parte (video, teclado e gabinete) não podem existir se a classe-todo Micro não existir

Não. As classes podem existir separadamente. Você pode pensar no caso que, quando você quer um teclado novo para o seu computador, você não troca de PC, apenas de teclado. E também, um computador não necessariamente necessita de um teclado. Anos luz atrás, falava-se em dispositivos de entrada (teclado, mouse, touch screen) e saída ( monitor, impressora, caixas de som ). Então, o que agrega o seu microcomputador (no seu exemplo) são os dispositivos de entrada e saída. Logo, teclado, mouse e vídeo, fazem parte desse conjunto. Mas você poderá trocá-los sempre quando bem entender (e o dinheiro deixar). O mesmo caso do gabinete, já vi computadores rodando sem gabinete, entretanto, não seria um computador completo.

 

Achei que haveria mais pessoas comentando esse tópico, gostaria para saber também, se meus "entendimentos" estão corretos.

 

Sempre há o que se aprender

[Felipe Rex 12]

Não havia tempo para eu falar mais, vim agora '-'

 

Não. As classes podem existir separadamente. Você pode pensar no caso que, quando você quer um teclado novo para o seu computador, você não troca de PC, apenas de teclado. E também, um computador não necessariamente necessita de um teclado. Anos luz atrás, falava-se em dispositivos de entrada (teclado, mouse, touch screen) e saída ( monitor, impressora, caixas de som ). Então, o que agrega o seu microcomputador (no seu exemplo) são os dispositivos de entrada e saída. Logo, teclado, mouse e vídeo, fazem parte desse conjunto. Mas você poderá trocá-los sempre quando bem entender (e o dinheiro deixar). O mesmo caso do gabinete, já vi computadores rodando sem gabinete, entretanto, não seria um computador completo.

 

Achei que haveria mais pessoas comentando esse tópico, gostaria para saber também, se meus "entendimentos" estão corretos.

 

Sempre há o que se aprender

 

 

Primeiro, obrigado Gabriel pelas respostas.

 

Você citou que as partes podem existir separadamente na agregação? No caso da classe-parte teclado, pode ser trocado, mas não faria sentido ela existir sem a existência da classe-todo Micro, não é? A classe-todo Micro pode existir sem as partes (Vídeo, teclado e gabinete), mas o inverso não faria sentido, não é assim que deve pensar quando trabalhar com agregação?

 

Estou analisando 2 fontes que falam coisas opostas:

A apostila teórica diz o seguinte: "Em uma agregação, um componente que faz parte de outro não pode existir isoladamente."

 

Agora no livro de programação PHP tem um diagrama demonstrativo de agregação onde a 'cesta de compras' é a classe-todo e a classe-parte é 'Produto'. Neste diagrama, 'Produto' pode existir sem a necessidade da 'Cesta de compras' (no meu ponto de vista)... Por isso to confuso, uma fonte diz uma coisa e outra explica pouco mas demonstra na programação o contrário.

 

Exemplo do diagrama demonstrado no livro de PHP

 

A propósito, o diagrama acima me parece errado, deveria ter uma classe 'produto comprado' onde esta seria agregada à 'Cesta de compras' e não a classe 'Produto', não seria certo?

[Gabriel Heming 766]

No caso da classe-parte teclado, pode ser trocado, mas não faria sentido ela existir sem a existência da classe-todo Micro

Mas mesmo o micro não existindo, o teclado continuaria existindo e o micro sem teclado também. Esse é o conceito da agregação.

 

Diferente da composição, que se a classe todo não existir ou a classe parte, vai dar problema. Um exemplo mais real seria o coração para um ser humano. Tire o coração de uma pessoa e veja o que acontece com o ser humano ou com o coração (não faça isso, foi só um exemplo :yay:), diferente do que acontece com o micro e o teclado.

 

A apostila teórica diz o seguinte: "Em uma agregação, um componente que faz parte de outro não pode existir isoladamente."

Essa é a definição de Composição. Há um bom artigo, do imaster, sobre isso.

 

UML: composição x agregação

 

Vale ressaltar, que, quando o alterar fala sobre a composição com o exemplo Pedido -> ItemPedido. Ele diz o seguinte.

[...]um produto NÃO é item de um pedido se não existe pedido[...]

O que significa que, isoladamente, um produto continua existindo, mas um item de um pedido não existirá caso não exista um pedido.

 

É muito comum as dúvidas recorrentes entre Agregação e Composição. Eu mesmo ainda "empaco" em alguns casos. E isso não vai ser de uma hora pra outra que você vai saber tudo 100%. Mas é bom que livre-se dessa apostila que cita a definição da composição no tópico de agregação. Não é interessante receber conhecimento incerto, e após tentar saber o certo.

 

Sugiro que procure algumas literaturas sobre UML e de preferências de autores conceituados. Mas eu já paro por ai, o que eu aprendi, foi aqui no fórum mesmo, lendo os tópicos já existentes.

[Felipe Rex 12]

Mas mesmo o micro não existindo, o teclado continuaria existindo e o micro sem teclado também. Esse é o conceito da agregação.

 

Diferente da composição, que se a classe todo não existir ou a classe parte, vai dar problema. Um exemplo mais real seria o coração para um ser humano. Tire o coração de uma pessoa e veja o que acontece com o ser humano ou com o coração (não faça isso, foi só um exemplo :yay:), diferente do que acontece com o micro e o teclado.

 

 

Essa é a definição de Composição. Há um bom artigo, do imaster, sobre isso.

 

UML: composição x agregação

 

Vale ressaltar, que, quando o alterar fala sobre a composição com o exemplo Pedido -> ItemPedido. Ele diz o seguinte.

 

O que significa que, isoladamente, um produto continua existindo, mas um item de um pedido não existirá caso não exista um pedido.

 

É muito comum as dúvidas recorrentes entre Agregação e Composição. Eu mesmo ainda "empaco" em alguns casos. E isso não vai ser de uma hora pra outra que você vai saber tudo 100%. Mas é bom que livre-se dessa apostila que cita a definição da composição no tópico de agregação. Não é interessante receber conhecimento incerto, e após tentar saber o certo.

 

Sugiro que procure algumas literaturas sobre UML e de preferências de autores conceituados. Mas eu já paro por ai, o que eu aprendi, foi aqui no fórum mesmo, lendo os tópicos já existentes.

 

 

Poxa Gabriel, obrigado pela ajuda. Essa apostila do curso diz exatamente o que escrevi no tópico e... o pior, ela não aborda o assunto Composição, somente Agregação - Associação e herança.

 

 

Vou desconsiderar a apostila do curso para agregação. Obrigado.

 

 

 

Só para ficar claro para mim e para outros leitores:

 

Agregação É um relacionamento entre classes onde se tem uma classe-todo e outras classes que formam 'partes dela'. A Agregação ocorre quando um método na classe-todo possuí um parâmetro para receber outra classe que fará parte do todo. As classe(s)-parte(s) podem existir isoladamente da classe-todo.

 

É obrigatório que a agregação ocorre na classe-todo por meio de um método?

 

 

É isso?

 

 

 

abs.

 

Obrigado pelos links enviados. Li este último e foi esclarecedor, obrigado.

[Gabriel Heming 766]

É obrigatório que a agregação ocorre na classe-todo por meio de um método?

Err... Me pegou... Também nunca vi de outra forma. Só não queria acabar falando besteira.

 

Entretanto, segundo os exemplos do autor Pablo Dall'Oglio, agregação é quando um objeto (parte) agrega outro objeto (todo) através de métodos. Na composição, é quando o próprio objeto (todo) instância outro objeto (parte).

[Felipe Rex 12]

Obrigado Gabriel pela ajuda. Tirei bastante dúvidas que tinha com a sua ajuda e links informados. Vlw!

[Gabriel Heming 766]

Que bom que lhe foi útil. Conhecimento agregado (sim, conhecimento é uma agregação) é sempre importante.

 

Entretanto, acho que eu cometi um "equívoco". Na verdade, o exemplo do autor Pablo Dall'Oglio é válido, mas , ao meu ver, não abrange todo o "problema".

 

Os tipos de associação, não se referem somente ao modo de instância do objeto, e sim ao conceito do objeto. Como no exemplo da lista de pedidos ( UML: composição x agregação ), eu não vejo, explicitamente, a necessidade de se instanciar o objeto paerte dentro do objeto todo.

 

Por exemplo:

Pedido.php

class Pedido {

   private $listaItemPedido;
   private $nome;

   public function __construct( $nome ) {
       $this->nome = $nome;
       $this->listaItemPedido = new ArrayIterator();
   }

   public function addProduto( Produto $produto ) {
       $this->listaItemPedido->append( $produto );        
   }
}

 

Produto.php

class Produto {

   private $nome;


   public function __construct( $nome ) {
       $this->nome = $nome;   
   }
   public function getNome() {
       return $this->nome;   
   }    
}

 

Desenvolvimento

$pedido = new Pedido( 'Pedido teste' );
$pedido->addProduto( new Produto( 'Produto nº 1' ) );
$pedido->addProduto( new Produto( 'Produto nº 2' ) );
$pedido->addProduto( new Produto( 'Produto nº 3' ) );

 

Veja que, apesar de termos apenas duas classes, o objeto produto torna-se um item pedido quando inserido no pedido através do método addItem. Método o qual só aceita um objeto da instância de Produto. Nesse caso, se fosse seguir a risca o exemplo anteriormente falado, você teria que possuir uma terceira classe.

 

ItemPedido.php

class ItemPedido {

   private $produto;

   public function __construct( Produto $produto ) {
       $this->produto = $produto;   
   }
   public function getProduto() {
       return $this->produto;   
   }    
}

 

E ai sim, instanciar a classe item pedido dentro da classe pedido.

 

Pedido.php (adptada ao novo exemplo)

class Pedido {

   private $listaItemPedido;
   private $nome;

   public function __construct( $nome ) {
       $this->nome = $nome;
       $this->listaItem = new ArrayIterator();
   }

   public function addProduto( Produto $produto ) {        
       $this->listaItemPedido->append( new ItemPedido( $produto ) );        
   }
}

 

O qual pra mim, não faz o menor sentido ter de instanciar a nova classe. Mas ai essa seria uma dúvida minha também. Do mesmo modo que você, também estou aprendendo, e dúvidas sempre surgirão, essa é uma das minhas.