[Resolvido] Interfaces

[Jair Humberto 2]

Olá pessoal,

 

eu tenho uma grande dúvida que até agora não consegui encontrar resposta: Métodos públicos só devem ser implementados se estão especificados em uma interface implementada?

 

O porquê dessa dúvida:

 

Dizem por aí, que as interfaces são como contratos na aplicação. Todos os métodos especificados numa interface devem ser implementados nas classes que a implementam e isso evita, por exemplo, que futuramente excluamos, ou renomeamos um método de uma interface e isso venha a causar pane no sistema. Ok isso não é questionavel. Está correto. Bom, de um jeito ou de outro, todo o conjunto de métodos publicos de uma classe constituem a interface dessa classe. Então surge a dúvida: Posso ter um método publico "avulso" na minha classe que, sua existencia, não esteja obedecendo a uma

interface específica? Se não é preciso que todos os métodos publicos de uma classe estejam presentes em especificações de interfaces, logo, a possibilidade de pane no sistema continuaria.

 

A resposta para essa pergunta para mim, no principio parecia ser SIM, todos os métodos publicos deveriam obedecer a especificação de uma interface.

Porém, o que acontece quando temos uma classe que SÓ ela implementaria uma determinada interface? Um exemplo é as classes de banco tipo

 

uma tabela de exemplo: foo com os campos a e b

eu geralmente, crio uma classe para essa tabela chamada

class Foo {
   private $a;
   private $b;
   public function getA() {
      return $this->a;
   }
   protected function setA($a) {
      $this->a = $a;
   }

   public function getB() {
      return $this->b;
   }
   protected function setB($B) {
      $this->b = $b;
   }

}

E aí? Preciso realmente de uma interface como Ifoo só para essa classe? Parece que a lógica diz que sim. Porém essa interface Ifoo,

só existiria por causa dessa classe.

[visitante_php 0]

+/-, uma interface diz a uma classe quais metodos ela deve ter, isso nao significa q so deve existir nesta classe os metodos declarados na interface...você pode ter metodos q nao estejam na interface, sem problemas...agora o uso de interface implica no fato de implementar heranças multiplas, o q nao eh suportado no php...e tb implica em polimorfismo de metodos...

[Jair Humberto 2]

Então não é 100% correto o fato de que as interfaces servem como "contratos" para as classes, evitando assim, que seja alterados ou excluidos métodos publicos importantes para o funcionamento do sistema?

[João Batista Neto 448]

agora o uso de interface implica no fato de implementar heranças multiplas, o q nao eh suportado no php...e tb implica em polimorfismo de metodos...

 

????

[Jair Humberto 2]

Eu sei que polimorphismo acontece também em métodos de classes que implementam interfaces

Eu acho que o pattern Factory, para quem conhece, pode exemplificar isso.

 

Acho que é praticamente a mesma idéia do polimorphismo na herança.

porém esse é não poderia ser o objetivo das interfaces, ou poderia?

 

Esse negócio é complicado.

 

Estou quase enchendo meu sistema de interfaces por causa desses artigos que leio na internet. Mas não está parecendo correto a minha idéia,

senão, realmente pareceria lógico ter uma restrição contra métodos publicos "avulsos".

 

Um outro problema que vejo nas interfaces NO PHP é a questão do PHP não ser tipado. Fica furado o código, porque apesar de eu ter que implementar os métodos da interface, não tenho especificações de quais tipos receber ou retornar e isso me permite quebrar o sistema se mudo os tipos.

No final, eu tenho que tratar isso nos métodos, aí as interfaces no PHP reduzem um pouco sua utilidade.

[visitante_php 0]

isso detipos q você fala eh type casting...você pode fazer isso

 
<?php 
class Identidade{
private $name;
public function __construct($name)
{
$this->setName($name);
} 
function setName($name) {
$this->name = $name;
} 
public function getName() 
{ 
return $this->name;
} 
.... } 

class Pessoa{ 

private $identidade; 

public function __construct( Identidade $identidade) 
{ 
$this->identidade = $identidade; 
} 

function getInformations() { 
echo '<pre>'; 
print_r($this->identidade); 
echo '</pre>'; 
} 
} 

$igor = new Identidade('igor'); 
$pessoa = new Pessoa($igor);
$pessoa->getInformations(); 

 

resultado

Identidade Object
(
 [name:Identidade:private] => igor
)

[Jair Humberto 2]

Opa, interessante o type casting, só que só funciona para instancias de classes né? Por exemplo se eu quiser limitar em um

inteiro como faria? Se eu coloco Integer, ele entende como uma classe Integer não como o tipo Integer, se coloco int a mesma

coisa acontece. Bom, porém isso já ajuda muito.

 

Agora, sobre a dúvida inicial, se posso ter métodos publicos avulsos independentes de interfaces implementadas, então o meu

sistema fica passível de quebra da mesma forma não é?

 

Seria correto implementar então interfaces para todos os métodos publicos?

[visitante_php 0]

Opa, interessante o type casting, só que só funciona para instancias de classes né?

creio que nao, acho q funcoes simples t podem ter isso....

 

Por exemplo se eu quiser limitar em um

inteiro como faria?

você teria q fazer isso dentro da funcao ex

fuction inteiro($int)
{
$inteiro = (int) $int;
return $inteiro;
}

 

neste caso ele esta forcando a variavel $int ser do tipo int

 

Agora, sobre a dúvida inicial, se posso ter métodos publicos avulsos independentes de interfaces implementadas, então o meu

sistema fica passível de quebra da mesma forma não é?

o php nao suporta herança multipla...ou seja, uma classe so pode herdar de uma, e nao de mais de uma..entao usa-se a interface...a interface forca uma classe ter certos metodos, você tendo uma classe q implementa varias iterfaces você tera varios metodos, uma coisa, ao mesmo tempo você pode herdar uma classe abstrata onde nela, tendo um metodo abstrato, este metodo eh forcado ter na classe filha

 

Seria correto implementar então interfaces para todos os métodos publicos?

assim você sufocaria o sistema q teria mais trabalho ao programar....

 

a interface eh do ponto de vista popular como contrato pelo seguinte....imagina um package sql com 4 classes: uma q gera a sql para select, outra q gera sql para insert, outra pra update e pra delete...todos eles teriam um metodo em comum: getQuery, q seria retornar a sql formatada, aki eu posso usar interface, pra unir o package num metodo comum...do ponto de vista tecnico, interface eh pra simular herança multipla, veja as classes de recursividade e SPL do manual...

[Jair Humberto 2]

mas C++ tem herança multipla! Então porque tem interfaces também?

Não é correto dizer que o conjunto de métodos públicos de uma classe são sua interface?

Logo, como poderia interfaces estar ligado à simulação de herança multipla?

outra coisa, se interfaces é pra simular herança multipla, então, quando eu tiver que implementar apenas

uma interface, um caminho igual seria a herança?

 

do detalhe lá do type casting, era isso mesmo que eu dizia. Eu não posso forçar tipagem no php a não ser se o tipo

for objeto

 

ex.:

interface Ifoo {
    public bool function bar(int $bar);
}

bool e int da forma que foi colocado, é impossível no PHP. Logo as interfaces perdem um pouco a utilidade nesse quesito aí.

 

Eu sei que dá pra simular herança multipla com interfaces, embora eu nunca precisei de herança multipla, porém,

sempre precisei de implementar mais de uma interface simplesmente para organizar o sistema.

 

Pra mim, interfaces são pra organizar o sistema e não tem uma necessidade específica, além dessa. Igualmente poderia comparar

a OO "não tem necessidade" programar OO se você consegue programar estruturado, porém, é muito melhor, mais organizado,

facil de manter , e etc, etc... se você programa OO. Assim da mesma forma, eu encaro as interfaces. Mas essa visão, tal como a sua,

eu ainda não tinha ouvido, embora, eu já sabia que se simulava herança multipla com interfaces.

 

Enfim, sobre a ultima parte, que é a primeira. Se vou sufocar meu sistema limitando todos os métodos publicos a interfaces implementadas,

e se não vou precisar usar herança, ou herança multipla, então não faz diferença usar interfaces no meu sistema?

 

Essa é a grande dúvida.

[João Batista Neto 448]

mas C++ tem herança multipla! Então porque tem interfaces também?

 

Porque não tem absolutamente nada a ver uma coisa com a outra, é um grande equivoco fazer relação entre interfaces e herança, principalmente herança múltipla.

 

Não é correto dizer que o conjunto de métodos públicos de uma classe são sua interface?

 

Sim, os métodos públicos de uma classe podem também ser chamados de métodos de interface.

 

Logo, como poderia interfaces estar ligado à simulação de herança multipla?

outra coisa, se interfaces é pra simular herança multipla, então, quando eu tiver que implementar apenas

uma interface, um caminho igual seria a herança?

 

Como disse anteriormente, não tem absolutamente nada a ver, interface é uma coisa, herança múltipla é outra.

 

Amigo, Interface é aquilo que você vê, você não deve criar uma interface para cada classe sua, não é esse o objetivo de uma interface.

Tudo o que você precisa é que uma classe implemente um método específico que você precisa, por exemplo:

 

Por exemplo:

 

interface IProduct {
public function getPrice();
}

 

Quando você define uma interface como essa você está falando que qualquer classe que a implemente terá o método getPrice(), como o preço será recuperado não é importante, apenas o método que importa:

 

class Apple implements IProduct {
public function getPrice(){
	return 10;
}
}

class Banana implements IProduct {
private $pdo;
private $name;

public function __construct(){
	$pdo = Registry::get( 'pdo' );

	$this->name = 'banana ouro';
}

public function getPrice(){
	$ret = -1;
	$stmt = $pdo->prepare( 'SELECT `price` FROM `Product` p WHERE p.`name`=:name;' );
	$stmt->bindParam( ':name' , $this->name , PDO::PARAM_STR );

	if ( $stmt->execute() ){
		$obj = $stmt->fetch( PDO::FETCH_OBJ );

		$ret =& $obj->price;
	}

	return $ret;
}
}

 

Como pode ver, temos dois produtos distintos que implementam IProduct, agora usando isso:

 

class Cart implements Countable {
private $storage = array();
private $total = 0;

public function addProduct( IProduct $product ){
	$this->storage[] =& $product;
	$this->total += $product->getPrice();
}

public function getTotal(){
	return $this->total;
}

public function count(){
	return count( $this->storage );
}
}

$carrinho = new Cart();
$carrinho->addProduct( new Apple() );
$carrinho->addProduct( new Banana() );

echo 'O carrinho tem ' , count( $carrinho ) , ' com o valor total de R$ ' , $carrinho->getTotal();

 

Veja que, apesar de termos duas classes distintas, sabemos que podemos contar com o método getPrice(), é só ele que precisamos.

 

Um outro exemplo:

 

interface ICommand {
public function execute();
}

class SendMail implements ICommand {
const MAIL_SENDER = 'my.self@domain.com';

private $recipient;
private $message;

public function setRecipient( $recipient ){
	$this->recipient =& $recipient;
}

public function setMessage( $message ){
	$this->message =& $message;
}

public function execute(){
	echo 'Enviando a mensagem ' , $this->message , ' de ' , self::MAIL_SENDER , ' para ' , $this->recipient , PHP_EOL;
}
}

class MailBot {
private $storage = array();

public function add( ICommand $mail ){
	$this->storage[] =& $mail;
}

public function send(){
	foreach ( $this->storage as $k => $mail )
		$mail->execute();
}
}

class EmailMarketing {
private $bot;
private $message;

public function __construct( $message ){
	$this->bot = new MailBot();
	$this->message =& $message;
}

public function setRecipients( array $recipients ){
	foreach ( $recipients as $recipient ){
		$mail = new SendMail();
		$mail->setRecipient( $recipient );
		$mail->setMessage( $this->message );
		$this->bot->add( $mail );
	}
}

public function send(){
	$this->bot->send();
}
}

$campaign = new EmailMarketing( 'Feliz Natal !!!' );
$campaign->setRecipients( array(
'fulano@dominio.com.br',
'teste@gmail.com',
'beltrano@test.com',
'interfaces@example.com'
) );
$campaign->send();

 

Como pode ver, a interface ICommand apenas define o método execute(), a classe que implementa essa interface, SendMail, deve implementar esse método, mas nada impede que ela tenha outros métodos. Você não precisa definir esses métodos porque eles não são importantes para a classe MailBot afinal, o bot vai apenas usar o método execute().

 

Como eu disse no início, interfaces não tem nada a ver com herança, tanto que nenhum dos exemplos demonstrados utilizou herança.

 

;)

[Jair Humberto 2]

Olá João Batista Neto,

 

Desculpe pela minha ignorância tamanha!

Mas então qual é, realmente, a utilidade das interfaces!? Eu não poderia aqui, simplesmente pelo bom senso,

definir o método getPrice(pois sei que vou precisar dele), sem precisar da interface?

 

class Apple {
        public function getPrice(){
                return 10;
        }
}

class Banana {
        private $pdo;
        private $name;
        
        public function __construct(){
                $pdo = Registry::get( 'pdo' );
                
                $this->name = 'banana ouro';
        }
        
        public function getPrice(){
                $ret = -1;
                $stmt = $pdo->prepare( 'SELECT `price` FROM `Product` p WHERE p.`name`=:name;' );
                $stmt->bindParam( ':name' , $this->name , PDO::PARAM_STR );
                
                if ( $stmt->execute() ){
                        $obj = $stmt->fetch( PDO::FETCH_OBJ );
                        
                        $ret =& $obj->price;
                }
                
                return $ret;
        }
}

Uma pergunta melhor é: Como eu saberei quando implementar interfaces?

[João Batista Neto 448]

Mas então qual é, realmente, a utilidade das interfaces!? Eu não poderia simplemente aqui, simplesmente, pelo bom senso,

definir o método getPrice()(sabendo que vou precisar dele), sem precisar da interface?

 

Como dito antes, os métodos públicos de uma classe são também chamados de métodos de interface, então se você encapsulou a lógica de uma operação e disponibilizou um método público, esse método faz, por definição, parte da interface da classe.

 

A necessidade de se utilizar a construção interface para declarar uma interface específica se dará conforme o uso da sua aplicação.

 

Porém aqui vai uma dica simples, sempre que você olhar para um objeto e perguntar:

 

Isso é ?

 

E a resposta para essa pergunta não for relevante ou não for suficiente, tente fazer uma outra pergunta:

 

Isso tem ?

 

Se essa segunda pergunta trouxer uma resposta mais adequada ao seu problema, então você está diante de um caso onde utilizar a construção interface

 

Imagine que você esteja desenvolvendo uma loja que venda produtos de informática, processadores, memória, monitor, gabinete....

 

class Product {
private $name;
private $price;

public function __construct( $name , $price ){
	 $this->name =& $name;
	 $this->price =& $price;
}

public function getPrice(){
	 return $this->price;
}

public function show(){
	 echo $this->name , PHP_EOL;
}
}

 

Sua loja estava funcionando 100% até que um dia, seu cliente vira para você e fala que quer permitir que seus clientes além de comprar os produtos separados, possam também customizar um novo produto utilizando qualquer produto da loja.

 

Percebe que agora a pergunta Isso é não resolve mais seu problema, afinal, tanto um processador 3Ghz quanto um gabinete com processador 3Ghz são de fato produtos ???

 

Porém,

 

interface IProduct {
public function getPrice();
public function show();
}

 

Se o produto, tanto o simples, quanto o customizado implementarem a interface IProduct, a pergunta Isso tem passa a responder seu problema, afinal, ambos tem o método show() e ambos possuem o método getPrice() fundamentais para o seu carrinho.

 

class Product implements IProduct {
private $name;
private $price;

public function __construct( $name , $price ){
	 $this->name =& $name;
	 $this->price =& $price;
}

public function getPrice(){
	 return $this->price;
}

public function show(){
	 echo $this->name , ' ';
}
}

class DecoratedProduct implements IProduct {
private $base;
private $name;
private $price;

public function __construct( $name , $price , IProduct $base ){
	 $this->base =& $base;
	 $this->name =& $name;
	 $this->price =& $price;
}

public function show(){
	 $this->base->show();

	 echo $this->name , ' ';
}

public function getPrice(){
	 return $this->price + $this->base->getPrice();
}
}

class Cart {
private $storage = array();

public function addProduct( IProduct $product ){
	 $this->storage[] =& $product;
}

public function getTotal(){
	 $total = 0;

	 foreach ( $this->storage as $product ) $total += $product->getPrice();

	 return $total;
}

public function show(){
	 echo '<table>' , PHP_EOL;
	 foreach ( $this->storage as $product ){
		 echo '	<tr>' , PHP_EOL;
		 echo ' 	<td>' , $product->show() , '</td>' , PHP_EOL;
		 echo ' 	<td>R$ ' , $product->getPrice() , '</td>' , PHP_EOL;
		 echo '	</tr>' , PHP_EOL;
	 }

	 echo '	<tr>' , PHP_EOL;
	 echo ' 	<td colspan="2"> Total do carrinho R$ ' , $this->getTotal() , '</td>' , PHP_EOL;
	 echo '	</tr>' , PHP_EOL;
	 echo '</table>' , PHP_EOL;
}
}

 

Agora, seu cliente pode tanto comprar um produto avulso como também montar um produto novo:

 

$proc1 = new Product( 'Processador 2Ghz' , 100 );
$proc2 = new Product( 'Processador 3Ghz' , 200 );
$proc3 = new Product( 'Processador 3Ghz' , 300 );

$gab1 = new Product( 'Gabinete' , 100 );

$disc1 = new Product( 'Hd 300Gib' , 300 );
$disc2 = new Product( 'Hd 500Gib' , 450 );

$especial = new DecoratedProduct( 'Processador 3Ghz' , 100 , $gab1 );
$especial = new DecoratedProduct( 'Hd 300Gib' , 200 , $especial );

$carrinho = new Cart();
$carrinho->addProduct( $especial );
$carrinho->addProduct( $disc2 );
$carrinho->show();

 

A saída será:

<table>
<tr>
	<td>Gabinete Processador 3Ghz Hd 300Gib </td>
	<td>R$ 400</td>
</tr>
<tr>
	<td>Hd 500Gib </td>
	<td>R$ 450</td>
</tr>
<tr>
	<td colspan="2"> Total do carrinho R$ 850</td>
</tr>
</table>

 

;)

[Jair Humberto 2]

Acho que estou entendendo agora. O exemplo que você deu, está me fazendo parecer que

Interfaces estão bem relacionadas a polimorphismo.

[João Batista Neto 448]

O exemplo que você deu, está me fazendo parecer que Interfaces estão bem relacionadas a polimorphismo.

 

Polimorfismo:

 

Poli => Várias

morfismo => Formas

 

O PHP é por padrão, uma linguagem polimórfica, isso significa que qualquer método ou função pode receber qualquer coisa como argumento:

 

function exemploPolimorfico( $valor ){
switch ( gettype( $valor ) ){
	case 'string':
		echo 'Você passou uma string com o valor: ' , $valor;
		break;
	case 'integer':
		echo 'Um inteiro !!!';
		break;
	case 'object':
		echo 'Uma instância de ' , get_class( $valor );
		break;
}
}

exemploPolimorfico( 'Neto' );
exemploPolimorfico( 10 );
exemploPolimorfico( new stdClass() );

 

Como pode ver, o comportamento padrão do PHP é aceitar qualquer coisa o que, por definição, faz do PHP uma linguagem polimórfica por padrão.

Porém, você pode prevenir esse comportamento utilizando type hint:

 

function exemploNaoPolimorfico( array $valor ){
echo 'Foi passada uma matriz com os seguintes valores: ' , print_r( $valor , true );
}

exemploNaoPolimorfico( array( 10 , 20 , 30 ) );

 

A função exemploNaoPolimorfico() vai falhar se você tentar enviar um inteiro ou qualquer coisa que não seja uma matriz.

 

Como eu disse, a interface é para garantir que uma instância de um objeto tenha um método que você precisa, isso é o contrário de polimorfismo, onde uma ação seria escolhida em runtime para um tipo diferente de dado, veja a diferença em uma classe:

 

class Polymorphism {
public function show( $value ){
	switch ( gettype( $value ) ){
		case 'string': $this->showString( $value ); break;
		case 'integer':
		case 'double': $this->showNumber( $value ); break;
		case 'object' : $this->showObject( $value ); break;
		default:
			echo 'Não sei trabalhar com isso';
	}
}

private function showString( &$value ){
	echo 'A string é: ' , $value , PHP_EOL;
}

private function showNumber( &$value ){
	echo $value , ' + 10 = ' , $value + 10;
}

private function showObject( &$value ){
	$vars = get_object_vars( $value );

	echo 'O objeto da classe ' , get_class( $value ) , ' tem as propriedades ' , implode( ',' , array_keys( $vars ) );
}
}

$obj = new stdClass();
$obj->teste = 10;
$obj->nome = 'Neto';

$teste = new Polymorphism();
$teste->show( 'Neto' );
$teste->show( 10 );
$teste->show( $obj );

 

A saída será:

A string é: Neto

10 + 10 = 20

O objeto da classe stdClass tem as propriedades teste,nome

 

Que é bem diferente disso:

 

interface IPerson {
public function show();
}

class Person implements IPerson {
private $name;

public function __construct( $name ){
	$this->name =& $name;
}

public function show(){
	echo 'Meu nome é ' , $this->name , PHP_EOL;
}
}

class Programmer implements IPerson {
private $person;

public function __construct( IPerson $person ){
	$this->person =& $person;
}

public function show(){
	$this->person->show();

	echo 'Eu sou um programador';
}
}

class NonPolymorphic {
public function show( IPerson $person ){
	$person->show();
}
}

$teste = new NonPolymorphic();
$teste->show( new Programmer( new Person( 'Neto' ) ) );

 

A saída será:

Meu nome é Neto

Eu sou um programador

 

Veja que no segundo exemplo, nós já sabemos que receberemos um IPerson e sabemos ainda que a interface IPerson garantirá que qualquer objeto que a implemente terá o método show(), por isso não precisamos decidir se vamos usar um ou outro método como ocorre no primeiro exemplo.

 

;)

[Jair Humberto 2]

Ué João Batista, no seu exemplo final também ocorreu polimorphismo. Veja:

 

class NonPolymorphic {
        public function show( IPerson $person ){
                $person->show(); /* aqui ocorreu, pois o método show pode ser interpretado de diversas formas diferentes
nas classes que implementam IPerson */
        }
}

Eu realmente não sabia que existia polimorphismo fora da Orientação a Objetos, para mim falar de polimorphismo fora

de OO era esquisito, mas você disse que o PHP é uma linguagem inteiramente polimórfica. Mesmo se eu programar estruturado?

 

Ainda estou pensando a mesma coisa sobre Interfaces e Polimorphismo. Parecem intimamente ligados!

o.O será que estou enganado?

[João Batista Neto 448]

Ué João Batista, no seu exemplo final também ocorreu polimorphismo. Veja:

 

class NonPolymorphic {
 public function show( IPerson $person ){
 $person->show(); /* aqui ocorreu, pois o método show pode ser interpretado de diversas formas diferentes
nas classes que implementam IPerson */
 }
}

Sim, mas o polimorfismo não ocorreu porque uma classe implementou o método show() diferente da outra e sim porque o método show() da classe NonPolymorphic aceita tanto um Programmer quanto um Person quanto qualquer coisa que implemente IPerson.

 

O polimorfismo não é o comportamento diferente do objeto e sim a capacidade de uma classe trabalhar com vários objetos de classes diferentes.

 

Eu realmente não sabia que existia polimorphismo fora da Orientação a Objetos, para mim falar de polimorphismo fora

de OO era esquisito, mas você disse que o PHP é uma linguagem inteiramente polimórfica. Mesmo se eu programar estruturado?

 

hehehehe, não amigo, foi só para ilustrar,

 

Polimorfismo é um conceito da orientação a objetos, eu só quis mostrar que ao contrário de linguagens de tipagem forte, o PHP aceita qualquer coisa como argumento e isso possibilita que você, dentro de uma classe, decida o que fazer com a informação recebida.

 

Ainda estou pensando a mesma coisa sobre Interfaces e Polimorphismo. Parecem intimamente ligados!

o.O será que estou enganado?

 

Não está enganado,

 

Quando N classes implementam uma interface todas elas passam a ter um acesso comum para uma determinada operação, quando passamos N instâncias dessas N classes para um método de uma outra classe, essa última será polimórfica, por poder trabalhar com N objetos de N classes diferentes, porém, com a garantia de saber que todas as instâncias terão um acesso comum para uma determinada operação.

[Jair Humberto 2]

Entendi agora hehe, finalmente.

mas não podem negar é difícil! http://forum.imasters.com.br/public/style_emoticons/default/natal_tongue.gif

 

mas não deixarei de ainda ler sobre o assunto buscando conhecimento cada vez mais sólido na área

 

Obrigado João Batista pelas explicações e ao Igor pelas contribuições também http://forum.imasters.com.br/public/style_emoticons/default/natal_biggrin.gif

[Fabyo 66]

Desculpe o comentario OFF TOPIC, mas gostaria de falar, eu gostei de ver as respostas do João Batista Neto, está de parabens :natal_biggrin:

 

é dificil eu ver programadores manjarem de OOP e ententer o que esta fazendo, a maioria das vezes só vejo programadores jogando funções dentro de class{} e ja acha que esta programando em OOP, e tbm a falta de logicas e nomes que nao tem nada haver com a classe e metodos e fora a falta de boas praticas de programação em OOP

 

valeu!!