poliformismo

[criatividade zero 17]

estava dando uma 'estudada' em poliformismo no material daqui do forum e em uns sites gringos, e peguei e adaptei uns exemplos, e queria saber se se enquadra como poliformismo

 

 

ficarei grato se alguem poder me dar uma luz dizendo se estou - pelo menos - no caminho

 

class massacote {
    public function acerta(){
        return ('acertou o massacote!');
    }

    public function matou(){
        return ('matou o massacote');
    }
}

class possante {
    public function acelera(){
        return ('pisa fundo!');
    }

    public function freia(){
        return ('olha o muro!');
    }
}

class sujeito{
	public function atira($classe, $funcao){
		return $classe -> $funcao();
	}
}

$sujeito	= new sujeito();
$massacote	= new massacote();
$possante	= new possante();

$acerta		= $sujeito -> atira($massacote, 'acerta');
$matou		= $sujeito -> atira($massacote, 'matou');

$acelera	= $sujeito -> atira($possante, 'acelera');
$freia		= $sujeito -> atira($possante, 'freia');

echo ($acerta . '<br />' . $matou);
echo ('<hr />');
echo ($acelera . '<br />' . $freia);

[João Batista Neto 448]

estava dando uma 'estudada' em poliformismo no material daqui do forum e em uns sites gringos, e peguei e adaptei uns exemplos, e queria saber se se enquadra como poliformismo

Amigo, vou tentar descrever polimorfismo de uma forma bem simples.

 

Imagina aquelas massas de modelar, que as crianças costumam ganhar. Se você modelar a massa como um boneco, um inseto, um carro ou qualquer outra coisa, você poderá ter várias (poli) formas (morphos) para a massa, mas ela continuará sendo massa.

 

A capacidade de um objeto se comportar como outro objeto, em orientação a objetos, chama-se polimorfismo.

 

E o que define o comportamento de um objeto ?

 

http://forum.imasters.com.br/public/style_emoticons/default/seta.gif Métodos de interface.

 

Então, polimorfismo em orientação a objetos, está diretamente relacionado aos métodos de interface que um determinado objeto implementa, por exemplo:

 

<?php
interface Brinquedo {
public function pegaNome();
}

class Bola implements Brinquedo {
public function pegaNome(){
 	return 'bola';
}
}

class Carrinho implements Brinquedo {
public function pegaNome(){
 	return 'carrinho';
}
}

class Crianca {
public function brinca( Brinquedo $brinquedo ){
 	echo 'A criança vai brincar com ' , $brinquedo->pegaNome();
}
}

 

Como por ver no fragmento acima, apesar da bola poder ter seus vários comportamentos particulares (quicar, entre outros), tanto o carrinho quanto a bola podem se comportar como Brinquedos.

[criatividade zero 17]

então o que postei não é mais que uma classe comum?! :)

li varios exemplos alguns diziam que 'class extends outra_classe' era poliformismo... ai me perdi

 

 

vou dar uma olhada mais afundo e depois retorno

valeu fera

[]s

[João Batista Neto 448]

então o que postei não é mais que uma classe comum?!

 

Você foi bem até certo ponto, depois se perdeu.

 

li varios exemplos alguns diziam que 'class extends outra_classe' era poliformismo... ai me perdi

 

Herança de classes também serve para definir os métodos de interface de um objeto, já que ele herda o comportamento do pai, por exemplo:

 

class Pessoa {
private $nome;
private $olhos;

public function __construct( $nome , $olhos ){
 	$this->nome = $nome;
 	$this->olhos = $olhos;
}

public function pegaNome(){
 	return $this->nome;
}

public function pegaCorOlhos(){
 	return $this->olhos;
}
}

class Pai extends Pessoa {
public function __construct( $nome ){
 	parent::__construct( $nome , 'azuis' );
}
}

class Filho extends Pai {
}

$pai = new Pai( 'Fulano' );
$filho = new Filho( 'Beltrano' );

echo 'O pai tem os olhos ' , $pai->pegaCorOlhos();
echo 'O filho herdou os olhos ' , $filho->pegaCorOlhos() , ' do pai.';

 

Como pode ver, tanto o pai quanto o filho herdaram da classe Pessoa os comportamentos pegaCorOlhos() e pegaNome(), esses dois métodos são os métodos de interface da classe Pessoa e que são compartilhados, através de herança de classes, com as classes Pai e Filho.

 

Agora, um exemplo polimórfico com as classes Pai e Filho seria:

 

<?php
class Empresa {
public function contrata( Pessoa $pessoa ){
 	echo 'Olá ' , $pessoa->pegaNome() , ' seja bem vindo à nossa empresa.';
}
}

$empresa = new Empresa();
$empresa->contrata( new Pai( 'Fulano' ) );
$empresa->contrara( new Filho( 'Beltrano' ) );

 

Como pode ver, como a Empresa espera uma Pessoa, tanto as instâncias de Pai como as instâncias de Filho são aceitas pelo método contrata que sabe como lidar com uma Pessoa.

 

;)

[criatividade zero 17]

 

então o que postei não é mais que uma classe comum?!

 

Você foi bem até certo ponto, depois se perdeu.

 

hehehehehe obrigado pelo incentivo :)

 

eu li inumeras vezes o seu exemplo do pau no gato, mas confesso que fiquei sem entender onde poderia usa-lo

 

 

acho que esse seu exemplo deu uma visão melhor (eu acho hehehe)

tentei fazer algo que fosse mais claro de como pode ser aplicado

 

acho que essa ainda é a minha maior dificuldade - aonde aplicar o poliformismo, aonde é necessário

 

 

$empresa->cadastra( new Cliente( '7999' ) );
$empresa->cadastra( new Cliente( '6999' ) );

faço a instancia de 2 clientes pelo ID

depois retorna o tipo de cdastro (pessoal ou empresarial), e retorna um array com os dados da pessoa

 

 

class Pessoa {
        private $nome;
        private $tipo;
        private $dado;

        public function __construct( $nome , $tipo ){
                $this->nome = $nome;
                $this->tipo = $tipo;
                $this->dado = array('nome' => 'fulano',
									'sobrenome' => 'da silva',
									'estado' => 'rio de janeiro',
									'cidade' => 'campos'
									);
        }

        public function pegaDado(){
                return $this->dado;
        }

        public function pegaNome(){
                return $this->nome;
        }

        public function pegaTipo(){
                return $this->tipo;
        }
}

class Cliente extends Pessoa {
        public function __construct( $nome ){
				if ($nome == '7999') {
                	parent::__construct( $nome , 'empresa' );
				} else {
                	parent::__construct( $nome , 'pessoal' );
				}
        }
}


class Empresa {
        public function cadastra( Pessoa $pessoa ){
                echo '<p>id ' , $pessoa->pegaNome() , ' cadastro tipo ' , $pessoa->pegaTipo() , ' .</p>';
				print_r($pessoa->pegaDado());
        }
}

$empresa = new Empresa();
$empresa->cadastra( new Cliente( '7999' ) );
$empresa->cadastra( new Cliente( '6999' ) );

 

valeu João

[João Batista Neto 448]

eu li inumeras vezes o seu exemplo do pau no gato, mas confesso que fiquei sem entender onde poderia usa-lo

 

Vou lhe dar uma dica: "Nunca foque no problema".

 

É comum, quando precisamos resolver um problema, dar tanta ênfase a esse problema, que deixamos de pensar na solução, ficamos cegos e deixamos de ver o óbvio.

 

Vamos tentar ver de uma forma diferente:

 

Imagine um estádio de futebol, Morumbi por exemplo. Você está diante do estádio, prestes a ver um jogo do nosso querido São Paulo, o Morumbi está lotado, 60 mil pessoas:

 

Dentro do estádio, o que você vê ?

 

Pessoas, óbvio.

 

Orientação a objetos é justamente isso, pensar no óbvio.

 

Pessoas é um tipo, e podemos sub-tipar essas pessoas, por exemplo:

 

Temos torcedores (óbvio), jogadores de futebol (óbvio), árbitros (óbvio), técnicos (óbvio)...

 

Então, além do tipo Pessoas, temos sub-tipos que também são pessoas e qualquer um desses sub-tipos são adequados à um estádio de futebol em dia de jogo.

 

Agora, se o Felipe Massa chegar no Morumbi pilotando uma Ferrari, ele vai entrar no estádio ? Uma Ferrari é adequada para um estádio de futebol em dia de jogo ?

 

Obviamente, não. O Felipe pode até assistir o jogo se ele quiser, mas a Ferrari deve ficar de fora (óbvio).

 

Entre os torcedores, podemos novamente subtipar, afinal, podemos ter engenheiros, médicos, jogadores de outros times, técnicos de outros times, operários, homens, mulheres, crianças, idosos....

 

Quanto mais óbvia for sua interpretação do problema, mais simples será sua solução e, consequentemente, mais reutilizável serão seus objetos.

 

Reutilizável ?

 

Sim, pense que essas mesmas pessoas que estão no Morumbi hoje (inclusive os jogadores, árbitros e técnicos) podem algum dia ir assistir Felipe Massa correndo no autódromo de Interlagos e, da mesma forma que Felipe não pôde entrar com sua Ferrari no Morumbi, nem pense em levar uma bola para jogar em Interlagos em dia de corrida porque, obviamente, não é adequado.

 

A abstração, em orientação a objetos, tem como único objetivo simplificar e, quanto mais simples for sua aplicação, mais escalável ela será.

[criatividade zero 17]

essa parte eu acho que ja entendi

 

$empresa->contrata seria a instancia de reutilização

new Pai( 'Fulano' ) seria a definição do tipo

 

posso contratar pai, filho, medico, advogado

mas não posso contratar uma mesa, um computador; pois não são do tipo "contrataveis"

 

acho que é isso :)

heheh

 

 

no seu exemplo, function contrata retorna os dados do tipo contratado, no caso new Pai( 'Fulano' )

$empresa->contrata( new Pai( 'Fulano' ) );

 

na class Pai extends Pessoa eu teria que ter algum retorno, possivelmente da database, seria aqui a consulta?

 

 

desculpe-me, mas eu ainda tenho dificuldade de enxergar a aplicação para o poliformismo

[João Batista Neto 448]

Certo amigo,

 

Façamos assim, pense em um problema real, vamos pensar em uma solução para ele.

[criatividade zero 17]

ai que esta, não tenho como imaginar uma situação real, pois estou no ABC :)

vou acabar falando besteira pq não sei a aplicação hehehehe

 

por exemplo uma alteração de cadastro - PF/PJ

seriam campos diferentes, um teria cpf e outro cnpj

to viajando hehehehehe

[João Batista Neto 448]

vou acabar falando besteira pq não sei a aplicação hehehehe

 

Jamais se preocupe com isso, ninguém nasce sabendo.

 

por exemplo uma alteração de cadastro - PF/PJ

seriam campos diferentes, um teria cpf e outro cnpj

 

Certo, então vamos pensar no seu contexto:

 

Você tem um formulário, esse formulário possui campos e botões. Dependendo do tipo do cadastro, um conjunto ou outro de campos é exibido.

 

Para que um conjunto ou outro seja exibido, uma ação do usuário é necessária, afinal, você não tem como adivinhar se quem está à frente do computador é uma PF ou um representante de uma empresa.

 

Quando o usuário terminar de preencher o formulário, uma outra ação será necessária para gravá-los no banco de dados.

 

-----

 

Da forma que foi descrita até esse instante, você consegue dizer quais os tipos de objetos que temos ? Todos eles, por mais minimalista que seja ?

[criatividade zero 17]

heheeheheh sou muito tapado com isso ainda :)

liga não

 

eu tentei imaginar o seguinte

o fulano faz o login e clica em alterar os dados, nessa etapa ja tenho definido se ele é PF ou PJ

 

acho que imgainei uma situação diferente da que você imaginou

[João Batista Neto 448]

Certo, mas o fato de você saber se é uma PF ou PJ no ato do login não muda o contexto.

 

Você continua tendo um formulário para modificação de um cadastro, campos, botões e ainda precisa que o usuário efetue uma ação para que o formulário seja gravado e os dados alterados.

 

Tente visualizar essa tela de cadastro/modificação de dados. O que você vê ?

[criatividade zero 17]

Certo, mas o fato de você saber se é uma PF ou PJ no ato do login não muda o contexto.

 

pq ainda não chegamos aonde entra o poliformismo... certo?

 

 

Tente visualizar essa tela de cadastro/modificação de dados. O que você vê ?

 

bom, se eu tiver 2 forms distinos, eu vejo todos os campos iguais exceto CPF/CNPJ, um botão de ação e uma classe-model que receberá essas informações

 

fui limitado?

[João Batista Neto 448]

pq ainda não chegamos aonde entra o poliformismo... certo?

 

Exatamente, ainda estamos apenas analisando o problema, a solução vem depois.

 

fui limitado?

 

Você deveria tê-lo sido mas, ao contrário, você descreveu em alto nível. Quando for analisar um problema, tente pensar de forma simplista e minimalista, quanto mais baixo nível você conseguir ver, menos especializados seus objetos serão e, consequentemente, mais reutilizáveis.

 

Pense que, nessa tela de cadastro/alteração, temos apenas componentes visuais.

 

O formulário é um componente visual que contém outros componentes visuais (títulos, campos e botões), essa composição de elementos visuais formam a interface de usuário ou GUI.

 

Os campos são elementos visuais de entrada, enquanto os botões são elementos visuais de ação.

 

Toda ação causará, sempre, uma reação e é exatamente esse o ponto do MVC.

 

Qual iteração que um usuário precisa fazer em uma GUI para causar a reação esperada ?

 

O clique no botão enviar, por exemplo, submeterá o formulário e, possivelmente, os dados serão gravados.

 

Tudo certo até aqui ?

[criatividade zero 17]

O clique no botão enviar, por exemplo, submeterá o formulário e, possivelmente, os dados serão gravados.

 

Tudo certo até aqui ?

 

sim sim

 

deveria ter analisado as entradas das informações, pois estas que serão manipuladas; onde e quando ainda não é o ponto

captei?! :)

[João Batista Neto 448]

captei?!

 

Na verdade não,

 

O que eu disse sobre ser minimalista foi no aspecto de você ter descrito "todos os campos iguais exceto CPF/CNPJ, um botão de ação" enquanto deveria ter dito apenas elementos visuais.

 

Tanto faz se são formulários, campos, textos ou botões, porque na verdade, são apenas elementos visuais.

[criatividade zero 17]

hahahaha to muito pior do que imaginava

to muito cru ainda, nao consigo ver o basico