1.4.3 Métodos de Interface e Polimorfismo

João Batista Neto · Maio 4, 2010

Bom, essa é a última parte de métodos de interface e polimorfismo, até agora vimos que as interfaces reduzem as dependências das implementações, vimos também que um mesmo objeto pode se comportar de várias formas diferentes ou vários objetos diferentes podem ter comportamentos iguais e que isso chama-se polimorfismo.

Quando vimos que herança serve para compartilhar código, vimos que o custo de implementação passa a ser menor, agora, podemos unir esse baixo custo de implementação com a redução das dependências de implementação utilizando classes abstratas.

Por exemplo, vamos pensar em um site, mais especificamente o que é exibido ao usuário:

Uma página possui:

1. Título
2. Palavras chave
3. Componentes

3.1. Menu
3.2. Texto
3.3. Formulários

Percebam então que, uma página é composta por vários elementos visuais que, juntos, exibem um conteúdo ao usuário, mas que individualmente, possuem características diferentes. É claro que, se todos tem o mesmo objetivo, eles devem ter alguma operação em comum, então, se pensarmos da forma mais simplista possível, todos os componentes da interface de usuário devem ser exibidos, alguns podem ter componentes filhos, como é o caso do Menu e Formulario, outros são mais simples, como um Texto.

Então precisamos de uma interface, comum para todos os componentes, que não viole o encapsulamento e que permita que todos sejam exibidos para o usuário.

interface Component {
public function addChild( Component $child );
public function hasChilds();
public function getChilds();
public function draw();
}

Bom, temos duas operações aqui, agora, imaginem que addChild() possua exatamente o mesmo código, para todos os componentes, não existe qualquer sentido em reescrever essa implementação para Menus, Paragrafos, Formulários, Botões. Porém, o a operação draw() é diferente para cada componente, afinal, um Menu é exibido para o usuário diferentemente de um Paragrafo que é diferente de outros componentes.

Ao utilizar uma classe abstrata como interface para seus herdeiros, podemos deixar partes específicas da implementação para as sub-classes e ainda definir uma interface comum para todos que dela derivam.

Por exemplo:

abstract class AbstractComponent implements Component {
private $childs = array();

public function addChild( Component $child ){
$this->childs[] = $child;
}

public function hasChilds(){
return count( $this->childs ) > 0;
}

public function getChilds(){
return $this->childs;
}

protected function drawChilds(){
foreach ( $this->getChilds() as $child ){
$child->draw();
}
}
}

Percebam que deixamos a implementação da operação draw() para depois, isso significa que as classes que derivarem de AbstractComponent precisarão implementar essa operação já que a interface Component a define. Porém, essa implementação, apesar de totalmente abstrata, possui um problema, ela assume que TODOS os componentes terão filhos e, isso não ocorre para um Texto por exemplo, então, precisamos redefinir algumas operações da AbstractComponent para adequar a essa situação:

abstract class AbstractLeaf extends AbstractComponent {
public function addChild( Component $child ){
throw new Exception( 'Esse componente não pode ter filhos.' );
}

public function hasChilds(){
return false;
}

public function getChilds(){
return array();
}
}

Agora sim, se um objeto deriva de AbstractComponent, terá os métodos de interface definidos pela interface Component e terá apenas que definir o que é específico para exibição do componente propriamente dito, porém, se estivermos trabalhando com um Texto, derivamos a AbstractLeaf que também provê um esqueleto para os métodos comuns da interface Component, apenas não permitindo que filhos sejam adicionados. Vamos ver como ficaria isso na prática:

class Page extends AbstractComponent {
private $title;

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

public function draw(){
echo '<html>';
echo '<head>';
echo '<title>' , $this->title , '</title>';
echo '</head>';
echo '<body>';
$this->drawChilds();
echo '</body>';
echo '</html>';
}
}

Ok, como uma página possui filhos, vamos defini-los:

class Text extends AbstractLeaf {
private $text;

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

public function draw(){
echo $this->text;
}
}

Como um texto não pode possuir filhos, derivamos AbstractLeaf, vamos ver outros componentes:

class Heading1 extends Text {
public function draw(){
echo '<h1>';
parent::draw();
echo '</h1>';
}
}

class MenuItem extends Text {
public function draw(){
echo '<li class="menuitem">';
parent::draw();
echo '</li>';
}
}

Percebam que tanto Heading1 quanto MenuItem derivam agora de Text, isso porque não tem sentido declararmos uma propriedade $text e um método construtor, exatamente igual ao Text, então, aproveitamos o que já existe em vez de reescrever código. Bom, continuando:

class Menu extends AbstractComponent {
public function draw(){
echo '<ul class="menu">';
$this->drawChilds();
echo '</ul>';
}
}

Ao contrário dos componentes anteriores (MenuItem, Heading1 e Text), um Menu deriva de AbstractComponent, isso porque um Menu é composto por MenuItems, então, logicamente, ele possui filhos.

class Bold extends AbstractComponent {
public function draw(){
echo '<b>';
$this->drawChilds();
echo '</b>';

}
}

class Paragraph extends AbstractComponent {
public function draw(){
echo '<p>';
$this->drawChilds();
echo '</p>';
}
}

Da mesma forma que o Menu, um Bold e um parágrafo possuem filhos, vamos usar isso agora:

$menu = new Menu();
$menu->addChild( new MenuItem( 'Home' ) );
$menu->addChild( new MenuItem( 'Empresa' ) );
$menu->addChild( new MenuItem( 'Produtos' ) );
$menu->addChild( new MenuItem( 'Trabalhe Conosco' ) );
$menu->addChild( new MenuItem( 'Contato' ) );

$h1 = new Heading1( 'PHP Orientado a Objetos' );
$programando = new Text( 'Programando para ' );
$interfaces = new Text( 'Interfaces' );
$bold = new Bold();
$bold->addChild( $interfaces );

$paragraph = new Paragraph();
$paragraph->addChild( $programando );
$paragraph->addChild( $bold );

$pagina = new Page( 'PHP Orientado a Objetos' );
$pagina->addChild( $h1 );
$pagina->addChild( $menu );
$pagina->addChild( $paragraph );
$pagina->draw();

A saída:

<html>
<head>
<title>PHP Orientado a Objetos</title>
</head>
<body>
<h1>PHP Orientado a Objetos</h1>
<ul class="menu">
<li class="menuitem">Home</li>
<li class="menuitem">Empresa</li>
<li class="menuitem">Produtos</li>
<li class="menuitem">Trabalhe Conosco</li>
<li class="menuitem">Contato</li>
</ul>
<p>
Programando para <b>Interfaces</b>
</p>
</body>
</html>

Percebam que, ao utilizar herança de classes, conseguimos deixar para os componentes apenas a responsabilidade pela exibição, isso fez com que nosso código ficasse curto e fácil de manter, porém, ao trabalhar com as interfaces, reduzimos as dependências da implementação de tal forma que conseguimos uma abstração total do que é necessário para montar uma página, mesmo que tenhamos objetos totalmente diferentes, todos se comportam exatamente iguais.

Bom, por hora é só, no próximo artigo da série PHP Orientado a Objetos, começaremos a falar sobre os objetos e interfaces nativos do PHP, chamados de SPL ou Standard PHP Library.

Imagem Postada

Índice :seta:

cedamorim · Maio 5, 2010

Perfeito

xiris · Agosto 25, 2010

Reavivando um pouco o tópico heheh.

Muito boa a "aula", de fácil entendimento. Parabéns.

WM _ Guilherme Ferrolli · Setembro 3, 2010

só tem um problema,

a quantidade gigantesca de includes e arquivos que eu teria que fazer.

Porém para isso:

<?php
function __autoload($nome_da_classe) {
    require_once 'lib/$nome_da_classe.'.'php';
}
$menu = new Menu();
$menu->addChild( new MenuItem( 'Home' ) );
$menu->addChild( new MenuItem( 'Empresa' ) );
$menu->addChild( new MenuItem( 'Produtos' ) );
$menu->addChild( new MenuItem( 'Trabalhe Conosco' ) );
$menu->addChild( new MenuItem( 'Contato' ) );

$h1 = new Heading1( 'PHP Orientado a Objetos' );
$programando = new Text( 'Programando para ' );
$interfaces = new Text( 'Interfaces' );
$bold = new Bold();
$bold->addChild( $interfaces );

$paragraph = new Paragraph();
$paragraph->addChild( $programando );
$paragraph->addChild( $bold );

$pagina = new Page( 'PHP Orientado a Objetos' );
$pagina->addChild( $h1 );
$pagina->addChild( $menu );
$pagina->addChild( $paragraph );
$pagina->draw();
?>

desta forma não é preciso incluir nada , apenas defini-se um diretório para salvar as classes , que no meu caso coloquei lib, até por padrão, e usar o autoload junto da index do controller.

XD

João Batista Neto · Setembro 3, 2010

a quantidade gigantesca de includes e arquivos que eu teria que fazer.

Porém para isso:
<?php
function __autoload($nome_da_classe) {
 require_once 'lib/$nome_da_classe.'.'php';
}
desta forma não é preciso incluir nada , apenas defini-se um diretório para salvar as classes , que no meu caso coloquei lib, até por padrão, e usar o autoload junto da index do controller.

Exatamente Guilherme,

Uma outra alternativa é a spl_autoload_register().

Imagine que você desenvolva uma biblioteca para fazer qualquer coisa, se o usuário que for utilizar sua biblioteca já tiver uma função __autoload() você terá problemas, com a spl_autoload_register() você pode ter várias funções para esse fim.

Pode inclusive listar todas as já existentes com spl_autoload_functions()

;)

WM _ Guilherme Ferrolli · Setembro 3, 2010

Imagine que você desenvolva uma biblioteca para fazer qualquer coisa, se o usuário que for utilizar sua biblioteca já tiver uma função __autoload() você terá problemas, com a spl_autoload_register() você pode ter várias funções para esse fim.

Eu desconhecia essa função. :D

Me sinto renovado agora ;P

Agradeço a implementação

Pode inclusive listar todas as já existentes com spl_autoload_functions()

Isso sim é uma função útil. hehe

Eu estava aqui pensando com meus botões e me perguntei:

"e se eu precisar de mais parametros para os filhos?"

então imaginei o seguinte:

Continuando no exemplo de um site.

Digamos que eu queira por exemplo modificar a cor de um determinado texto, ou melhor. ao invés de eu predeterminar com uma classe(php) nova

qual seria a classe(css) de uma tag qualquer eu poderia fazer isso com um parametro adicional por exemplo:

class Text extends AbstractLeaf {
        private $text;

        public function __construct( $a ,
		$b = false,$c = false,$d = false,
		$e = false,$f = false,$g = false,
		$h = false,$i = false,$j = false,
		$k = false,$l = false,$m = false,
		$n = false,$o = false,$p = false,
		$q = false,$r = false,$s = false,
		$t = false,$u = false,$v = false,
		$x = false,$z = false) // assim eu permito até 24 parâmetros sem burlar o encapsulamento
		{
                $this->a = $a;$this->i = $a;$this->q = $a;
				$this->b = $a;$this->j = $a;$this->r = $a;
				$this->c = $a;$this->k = $a;$this->s = $a;
				$this->d = $a;$this->l = $a;$this->t = $a;
				$this->e = $a;$this->m = $a;$this->u = $a;
				$this->f = $a;$this->n = $a;$this->v = $a;
				$this->g = $a;$this->o = $a;$this->x = $a;
				$this->h = $a;$this->p = $a;$this->z = $a;
				
        }

        public function draw(){
                echo $this->a;
        }
}

class div extends Text {
        public function draw() {
                if(parent::b == false) {parent::b = 'classe_padrao'}
                echo '<div class="'.parent::b.'">';
                parent::draw();
                echo '</div>';
        }
}

desta forma tenho a liberdade de mecher com toda estrutura de uma tag , inclusive , poderia até mudar a tag para a que eu bem quizesse, como:

class div extends Text {
        public function draw() {
                if(parent::b == false) {parent::b = 'classe_padrao'}
                if(parent::c == false) {parent::c = 'div'}
                echo '<'.parent::c.' class="'.parent::b.'">';
                parent::draw();
                echo '</'.parent::c.'>';
        }
}

Achei isto útil quando lidamos com id de usuários, de produtos ou qualquer outro tipo de informação que trocamos via post,

para usar de parametro de comparação nas consultas SQL.

Bom é isso ai. :D

Aprendi muito lendo seus tutoriais hehehe..

Obrigado novamente pela dica do spl_autoload_functions()

;P

WM _ Guilherme Ferrolli · Setembro 3, 2010

eu tenho uma pergunta. Procurei no manual mas não tem.

Tem como eu adicinoar algum parametro de return na spl_autoload_functions() ?

é que eu salvo minhas classes em um padrão de nome, exemplo:

class-login.php

class-newUser.php

class-seilaKKK.php

Porém o nome das classes fica sem o 'class-', exemplo:

class login {}

class newUser {}

class seilakkk {}

Abraços :)

///////////editando o post , ja que não posso excluí-lo KKKK

Acabei de descobrir o que você tinha dito, o manual explica e você ja o tinha explicado, ele não anula o autoload, só complementa. Quando eu tiver uma outra aplicação posso usar a função sem medo de duplicação ou redeclarações de classes.

XD você é o cara.

Abraços

WM _ Guilherme Ferrolli · Setembro 29, 2010

Tudo ok João?

Tenho usado este pattern e fiz uma pequena implementação nele mas muito útil.

A limitação dele é gerada pelo encapsulamento, pois não permite a utilização de metodos além do $this->draw().

E como não estou utilizando ele para gerar html, mas para facilitar a criação de objetos, existem determinados objetos que necessitam de outros metodos, e para isso uma solução simples , aonde posso utilizar todos os métodos da child nova usando o objeto encapsulador.

]
<?php
interface Component {
}
abstract class AbstractComponent implements Component {
        private $childs = array();

        public function addChild( Component $child ){
                $this->childs[] = $child;
        }

        public function hasChilds(){
                return count( $this->childs ) > 0;
        }

        public function getChilds(){
                return $this->childs;
        }

        protected function drawChilds(){
                foreach ( $this->getChilds() as $child ){
                        $child->draw();
                }
        }
		public function __call($method,$array) {
		foreach($this->getChilds() as $class) {
			if(method_exists($class,$method)) {
				$class->$method();
			}
		}
	}
}
class newComponent extends AbstractComponent {
	public function draw() {
		$this->drawChilds();
	}
}
class a extends newComponent {
	public function draw() {
		echo "function draw";
	}
	public function metodo_a() {
		echo "classe A";
	}
}
class b extends newComponent {
	public function draw() {
		echo "function draw";
	}
	public function metodo_b() {
		echo "classe B";
	}
}
$child = new newComponent;
$child->addChild(new a());
$child->addChild(new b());
$child->metodo_a();
$child->metodo_b();
$child->draw();
?>

Simples não. E útil.

É isso ai..

abraços.

João Batista Neto · Setembro 30, 2010

@WM _ Guilherme Ferrolli,

Eu não gosto desses "métodos mágicos", eles vão contra exatamente o que queremos mostrar neste tópico, que é a confiança que um determinado objeto terá um determinado método baseado em usa interface.

Ao utilizar o __call() você acaba programando para um objeto que você sabe que o implementa e deixa de programar para interfaces. Isso causa, inevitavelmente, que você torne-se dependente de uma implementação específica e passe a modificar código se as implementações mudam.

Programar para interfaces é justamente o oposto que o método __call() pretende, é trabalhar com a confiança que um objeto faz o que você espera baseado em sua interface e não supor que tal objeto vá fazer e, menos ainda, saber que tal objeto faz alguma coisa porque você conhece a implementação específica.

WM _ Guilherme Ferrolli · Outubro 1, 2010

João Batista Neto

Eu não gosto desses "métodos mágicos",

Bom, não deixando antes de reconhecer que o conhecimento que você tem está quilômetros a frente do meu, digo que não é porque se esta acostumado, se gosta ou não de alguma implementação no Core do PHP, como foram os métodos mágicos que eles deixem de ser úteis.

Programar para interfaces é justamente o oposto que o método __call() pretende, é trabalhar com a confiança que um objeto faz o que você espera baseado em sua interface e não supor que tal objeto vá fazer e, menos ainda, saber que tal objeto faz alguma coisa porque você conhece a implementação específica.

Sim, programar para interfaces é a melhor opção por diversas razões, porém não entendi aonde na pequena implementação deixou de ser uma implementação para interfaces, afinal todo pattern continua dependendo do método drawChilds() e nas classes herdeiras do método draw().

A utilização do __call dentro do sistema serve somente para que eu não precise criar dezenas de classes que poderiam ser métodos, como validação de campos de um determinado cadastro.

Senti a necessidade de utilizar o __call porque este sistema limita todas as classes herdeiras a terem somente um metodo draw() e seu __construct,

obrigando assim a escrever quase que de modo procedural dentro das draw(), ou criar dezenas de classes que só serão utilizadas uma ou duas vezes.

ex:

tenho uma classe que cria usuários, uma que salva, uma que edita, e uma que deleta, e para fazer a validação, terei que criar uma classe para validar o login procurando uma entrada no banco igual, validar o email, validar o cpf, validar o nome e validar o ip restrito de uso do sistema de cada usuário, e utilizaria estas classes somente uma vez, no cadastro dos usuários, não poderia, por exemplo, usar esta classe para validar produtos, criar clientes e etc.De outro modo, poderia fazer o metodo draw ser interdependente de métodos de validação dentro da própria classe , porém tornaria a escrever de forma procedural dentro de uma classe.

Então ao invés de criar 8 classes para fazer um simples controle de usuários eu crio somente a classe users e dentro dela implemento com os métodos necessários e ao invés de o draw() ser dependente dos métodos da classe ele tem a sua função independente, sendo que para que ele não seja executado todos os métodos de validação devem ser true, pois caso contrário lançariam uma Exception, que geraria um erro fatal acabando com a execução do processo no servidor, não executando o draw().

Analize estas classe que utilizei. Com uma implementação do __call poderia torná-las muito mais simples e abstratas.

insertSQL

<?php
class insertSQL extends admin {
	private $debug;
	private $table;
	private $rows;
	private $query;
	public function __construct($table,$rows=array(),$debug=false) {
		$this->debug = $debug;
		$this->table =  noInject::doIt($table);
		$this->rows = noInject::doIt($rows);
	}
	public function make() {
		$query = "insert into  `$this->table` (";
		foreach($this->rows as $row) {
			$query .= "`$row`,";
		}
		$query .= "`id` ) values ( ";
		foreach($this->rows as $offset) {
			$this->value = noInject::doIt($_POST[$offset]);
			if($_POST[$offset]==='') {
				throw new Exception("preencha o campo $offset");
				exit();
			}
			$query .= "'".$this->value."',";	
		}
		$query .= " NULL ); ";
		if($this->debug===true) {
			throw new Exception($query);
		}
		else {
			$sql = megaDB::_query($query);
			if($sql===true) {
				throw new goodException("Requizição realizada com sucesso",true);
			}
		}
	}
}
?>

Eu tinha desenvolvido a insertSQL primeiramente utilizando ArrayIterator, mas ficou muito mais simples assim.

Nesta classe eu permito a inserção de quantos campos existirem no universo dentro de uma tabela sql, compreendendo que cada argumento do array() é um campo da tabela do primeiro argumento da função make() (troquei o draw()) e são também as index de $_POSTs que serão recebidos, passando a depender somente de conter em todas as tabelas um campo id, que é comum, e praticamente indispensável.

Porém esta classe não tem validação, pois não tenho a liberdade de criar um método abstrato para validação seguindo esse estilo de sistema, teria que criar uma outra classe.

Agora como __call eu poderia criar uma validação de campos abstrata usando os artifícios que ele tem,

sendo argumentos infinitos dentro de um array() e a string do método qualquer que posso usar como quizer.

para validar por exemplo os usuarios poderia fazer simplismente assim

ex:

$adm = new admin;
$adm->addChild(new insertSQL("users",array("name","login","pwd"));
$adm->name() //validaria o nome no método da classe insertSQL em algum método que realiza um select para validar
$adm->email() // validaria o email com checkdnsrr()
$adm->make()// caso as validações fossem true ele seria executado caso contrário não chegaria 
//nem a ser conhecido pelo servidor pois a Exception teria gerado um fatal error

no caso de utilizar o sistema sem o __call

seria de escrita tão simples quanto, mas ao invés serem métodos seriam classes, e essas classes obrigatóriamente teriam seus métodos public, sendo que além do encapsulamento , se fossem métodos , poderiam ser private e serem ativados apenas pelo __call dentro da própria classe.

Marcone Lima · Dezembro 9, 2010

João Batista Neto

Eu não gosto desses "métodos mágicos",

Bom, não deixando antes de reconhecer que o conhecimento que você tem está quilômetros a frente do meu, digo que não é porque se esta acostumado, se gosta ou não de alguma implementação no Core do PHP, como foram os métodos mágicos que eles deixem de ser úteis.

Programar para interfaces é justamente o oposto que o método __call() pretende, é trabalhar com a confiança que um objeto faz o que você espera baseado em sua interface e não supor que tal objeto vá fazer e, menos ainda, saber que tal objeto faz alguma coisa porque você conhece a implementação específica.

Sim, programar para interfaces é a melhor opção por diversas razões, porém não entendi aonde na pequena implementação deixou de ser uma implementação para interfaces, afinal todo pattern continua dependendo do método drawChilds() e nas classes herdeiras do método draw().

A utilização do __call dentro do sistema serve somente para que eu não precise criar dezenas de classes que poderiam ser métodos, como validação de campos de um determinado cadastro.

Senti a necessidade de utilizar o __call porque este sistema limita todas as classes herdeiras a terem somente um metodo draw() e seu __construct,

obrigando assim a escrever quase que de modo procedural dentro das draw(), ou criar dezenas de classes que só serão utilizadas uma ou duas vezes.

ex:

tenho uma classe que cria usuários, uma que salva, uma que edita, e uma que deleta, e para fazer a validação, terei que criar uma classe para validar o login procurando uma entrada no banco igual, validar o email, validar o cpf, validar o nome e validar o ip restrito de uso do sistema de cada usuário, e utilizaria estas classes somente uma vez, no cadastro dos usuários, não poderia, por exemplo, usar esta classe para validar produtos, criar clientes e etc.De outro modo, poderia fazer o metodo draw ser interdependente de métodos de validação dentro da própria classe , porém tornaria a escrever de forma procedural dentro de uma classe.

Então ao invés de criar 8 classes para fazer um simples controle de usuários eu crio somente a classe users e dentro dela implemento com os métodos necessários e ao invés de o draw() ser dependente dos métodos da classe ele tem a sua função independente, sendo que para que ele não seja executado todos os métodos de validação devem ser true, pois caso contrário lançariam uma Exception, que geraria um erro fatal acabando com a execução do processo no servidor, não executando o draw().

Analize estas classe que utilizei. Com uma implementação do __call poderia torná-las muito mais simples e abstratas.

insertSQL
<?php
class insertSQL extends admin {
private $debug;
private $table;
private $rows;
private $query;
public function __construct($table,$rows=array(),$debug=false) {
	$this->debug = $debug;
	$this->table =  noInject::doIt($table);
	$this->rows = noInject::doIt($rows);
}
public function make() {
	$query = "insert into  `$this->table` (";
	foreach($this->rows as $row) {
		$query .= "`$row`,";
	}
	$query .= "`id` ) values ( ";
	foreach($this->rows as $offset) {
		$this->value = noInject::doIt($_POST[$offset]);
		if($_POST[$offset]==='') {
			throw new Exception("preencha o campo $offset");
			exit();
		}
		$query .= "'".$this->value."',";	
	}
	$query .= " NULL ); ";
	if($this->debug===true) {
		throw new Exception($query);
	}
	else {
		$sql = megaDB::_query($query);
		if($sql===true) {
			throw new goodException("Requizição realizada com sucesso",true);
		}
	}
}
}
?>
Eu tinha desenvolvido a insertSQL primeiramente utilizando ArrayIterator, mas ficou muito mais simples assim.

Nesta classe eu permito a inserção de quantos campos existirem no universo dentro de uma tabela sql, compreendendo que cada argumento do array() é um campo da tabela do primeiro argumento da função make() (troquei o draw()) e são também as index de $_POSTs que serão recebidos, passando a depender somente de conter em todas as tabelas um campo id, que é comum, e praticamente indispensável.

Porém esta classe não tem validação, pois não tenho a liberdade de criar um método abstrato para validação seguindo esse estilo de sistema, teria que criar uma outra classe.

Agora como __call eu poderia criar uma validação de campos abstrata usando os artifícios que ele tem,

sendo argumentos infinitos dentro de um array() e a string do método qualquer que posso usar como quizer.

para validar por exemplo os usuarios poderia fazer simplismente assim

ex:
$adm = new admin;
$adm->addChild(new insertSQL("users",array("name","login","pwd"));
$adm->name() //validaria o nome no método da classe insertSQL em algum método que realiza um select para validar
$adm->email() // validaria o email com checkdnsrr()
$adm->make()// caso as validações fossem true ele seria executado caso contrário não chegaria 
//nem a ser conhecido pelo servidor pois a Exception teria gerado um fatal error
no caso de utilizar o sistema sem o __call

seria de escrita tão simples quanto, mas ao invés serem métodos seriam classes, e essas classes obrigatóriamente teriam seus métodos public, sendo que além do encapsulamento , se fossem métodos , poderiam ser private e serem ativados apenas pelo __call dentro da própria classe.

Muito bom.

Arquivado

1.4.3 Métodos de Interface e Polimorfismo

Recommended Posts

João Batista Neto 448

Compartilhar este post

Link para o post

Compartilhar em outros sites

cedamorim 0

Compartilhar este post

Link para o post

Compartilhar em outros sites

xiris 0

Compartilhar este post

Link para o post

Compartilhar em outros sites

WM _ Guilherme Ferrolli 0

Compartilhar este post

Link para o post

Compartilhar em outros sites

João Batista Neto 448

Compartilhar este post

Link para o post

Compartilhar em outros sites

WM _ Guilherme Ferrolli 0

Compartilhar este post

Link para o post

Compartilhar em outros sites

WM _ Guilherme Ferrolli 0

Compartilhar este post

Link para o post

Compartilhar em outros sites

WM _ Guilherme Ferrolli 0

Compartilhar este post

Link para o post

Compartilhar em outros sites

João Batista Neto 448

Compartilhar este post

Link para o post

Compartilhar em outros sites

WM _ Guilherme Ferrolli 0

Compartilhar este post

Link para o post

Compartilhar em outros sites

Marcone Lima 0

Compartilhar este post

Link para o post

Compartilhar em outros sites

Consulta SQL dentro de outra consulta

problema em usar json para realizar engenharia de dados

Soma dos dias utilizados

Fóruns

Tempo Real

Informação importante