Como um exemplo para melhor entendimento do Padrão Strategy, considere uma classe Guerreiro, que possui um método chamado lutar, onde nele ele utiliza de uma arma golpear os adversários; Porém existem vários tipos de armas (Espada, Machado, Lança, Arco/Flecha), e para ganhar uma guerra, deve-se ter vários tipos de armamentos distribuídos entre os guerreiros;

Como primeira idéia de implementação, vamos criar uma implementação Guerreiro padrão, e para cada tipo de armamento vamos estender a classe padrão sobrescrevendo o método lutar para utilizar outro armamento; Sendo assim temos:

Como primeira idéia de implementação,

<?php
class Guerreiro {
 
	// Outros métodos do Guerreiro
	...
 
	public function lutar() {
		// Implementação da luta
		echo 'lutando com os punhos';
	}
}
 
class Arqueiro extends Guerreiro {
	public function lutar() {
		// Implementação da luta
		echo 'Atirando com o Arco';
	}
}
 
class Cavaleiro extends Guerreiro {
	public function lutar() {
		// Implementação da luta
		echo 'Lutando com espada';
	}
}
?>

De inicio parece uma boa solução, porém a luta não consiste apenas em golpear o adversário, mas sim de vários outros comportamentos que não depende da arma, e sendo assim, esse código ficará repetido em cada classe que estender a classe Guerreiro, o que não é uma boa solução, tendo em vista que na hora da alteração desse código, terá que passar em cada classe alterando o mesmo código;

Para melhorar solucionar esse problema, vamos aplicar o conceito do padrão Strategy, onde será mantida uma unica implementação de Guerreiro que receberá em seu construtor qualquer classe que implemente a interface Arma, que contem um método para realizar o golpe; Sendo assim:

<?php
 
//Implementação de Guerreiro
class Guerreiro {
	private $arma;
	public function __construct(Arma $arma) {
		$this->arma = $arma;
	}
 
	// Outros métodos do Guerreiro
	...
 
	public function lutar() {
		// Implementação da luta
		$this->arma->golpear();
	}
}
 
interface Arma {
	public function golpear();
}
 
class ArcoFlecha implements Arma {
	public function golpear() {
		echo 'Atirando com o arco';
	}
}
 
class Punho implements Arma {
	public function golpear() {
		echo 'Cabra macho luta com os punhos';
	}
}
 
class Espada implements Arma {
	public function golpear() {
		echo 'Lutando com a Espada';
	}
}
 
// Exemplo
$arqueiro = new Guerreiro(new ArcoFlecha());
$cavaleiro = new Guerreiro(new Espada());
$cabraMacho = new Guerreiro(new Punho());
 
?>

O padrão Strategy segue o padrão de Orientação a Objetos de encapsular o que varia, mantendo o codigo comum em um unico só lugar, ficando fácil a manutenção que, no nosso exemplo, basta implementar a interface Arma caso precisar de um novo tipo de arma na guerra; Outra vantagem vem da amplitude onde o problema pode ser expandido, ou seja, caso existam outro tipo de classe que lute com armas (um Pirata, por exemplo), não é necessário reimplementar todo o comportamento de luta com armas:

<?php
class Pirata {
	private $arma;
	public function __construct(Arma $arma) {
		$this->arma = $arma;
	}
 
	public function invadirNavioInimigo() {
		$this->arma->golpear();
	}
}
 
$pirata = new Pirata(new Espada());
 
?>

Aplicando esse conceito no framework, vamos alterar a forma como é lido os parâmetros que definem qual Module/Action que será acessada;

Utilizar variáveis GET para determinar qual action deve ser executada não é uma boa prática, e tornam “feias” as URLs do Sistema; Para isso, vamos aplicar o conceito de URLs amigáveis, no lugar das variáveis GET; Assim, os valores do module e da action que será acessada no sistema, serão lidos diretamente da URL;

No Framework atual, a leitura dos parâmetros que decidem qual Command executar esta sendo feita atualmente dentro do Command_Factory juntamente com o código de carregar o Command; Nesse caso em particular, teremos que separar as duas funcionalidades, pois vai variar a forma que será recuperado os parâmetros para carregar os Command, e seguindo a definição do Strategy, vamos criar uma interface que irá descrever como que as implementações de leitura dos parâmetros deve fornecer os valores, assim o factory não irá se importar de qual implementação ele esta recuperando os parâmetros;

Com essa alteração, cada classe passa a ter sua responsabilidade bem definida, e sempre que se deseja mudar a forma como que os parâmetros devem ser lidos, basta criar uma classe que implementa a interface que realiza essa ação e passa-la pro Factory sem precisar mudar uma linha de código do Factory;

Nossa interface se chamará Command_Info, pois ela guardara as informações da URL de acesso, e terá dois métodos principais, que irá retornar o Modulo e a Action desejada, ficando da seguinte forma:

arquivo: /lib/Command/Info.php

interface Command_Info {
    //Método que retorna o Module
    public function getModule();
    //Método que retorna a Action
    public function getAction();
}

Vamos criar a nossa implementação padrão, que irá recuperar os parâmetros da mesma forma que estava sendo feita anteriormente:

arquivo: /lib/Command/Info/Default.php

class Command_Info_Default implements Command_Info {
    // Retorna o valor do Module contido no GET
    public function getModule() {
        return $_GET['module'];
    }
    // Retorna o valor da Action contigo no GET
    public function getAction() {
        return $_GET['action'];
    }
 
}

O Command_Factory receberá uma instância de alguma implementação de Command_Info por parâmetro, para então realizar a chamada ao Command correto;

arquivo: /lib/Command/Factory.php

<?php
class Command_Factory {
     public function createCommand(Command_Info $info) {
 
           //Se o module não for informado, ele passa a ser considerado o index;
           $module = ($info->getModule() != null) ? $info->getModule() : 'index';
           //A mesma coisa para a action
           $action = ($info->getAction() != null) ? $info->getAction() : 'index';
 
 
          //Deixa a primeira letra em Maiusculo e o resto da string em minusculo
          $module = htmlspecialchars(ucfirst(strtolower($module)));
          $action = htmlspecialchars(ucfirst(strtolower($action)));
 
          //Cria o nome do arquivo da Action
          $fileName = 'command/'.$module.'/'.$action.'.php';
 
          //Se o arquivo não existir, gera erro
          if (!file_exists($fileName)) {
               throw new Exception_Pagenotfound('Arquivo do Command não encontrado: '.$fileName);
          }
          //Carrega o arquivo
          require_once $fileName;
 
          //O nome da classe é a Action seguida da String Command
          $className = $action.'Command';
 
          //Depois que o arquivo for adicionado, a classe deve existir, caso não existir, o arquivo carregado
          //não contem o Command, então deve gerar outro erro; o parâmetro false no class_exists 
          //é informado para não carregar a classe utilizando o __autoload
          if (!class_exists($className,false)) {
               throw new Exception_Pagenotfound('Command não foi encontrado: '.$className);
          }               
          //Carrega e retorna a Classe
          return new $className();
     }
}
?>

Notem que não é obrigatório a classe Strategy ser informadam no construtor, podendo ser informada como parâmetro do método; Vale tambem ressaltar que foi definido que o Command_Factory deve receber uma instância de Command_Info como parâmetro, e esse é um dos poucos casos onde o PHP trata o tipo da variável, que no nosso caso é essencial essa verificação de tipo, pois caso seja passado uma variável qualquer, o nosso Command_Factory não irá conseguir trabalhar corretamente;
Agora que temos toda a estrutura separada e flexível a ponto de podemos personaliza-la, precisamos de uma maneira setar a configuração; Geralmente se utiliza arquivo texto (XML, YAML, etc) para essa configuração, mas no nosso caso vamos utilizar uma classe PHP, que na minha opinião é a melhor escolha, pois pula a etapa de abrir e ler um arquivo para armazenar as configurações em variáveis do PHP, tornando o sistema mais rápido;

Obs.: A forma de configuração utilizada nesse artigo não é apenas um exemplo, e sua implementação não faz parte do foco; Existem outras formas de fazer essa configuração, podendo você escolher a que mais lhe agrada

arquivo: lib/Config.php

<?php
//Arquivo de configuração do FrameWork
class Config {
	private $commandInfo;
	public function configure() {
 
		//Configura a Classe que irá ler os parâmetros da URL
		$this->commandInfo = new Command_Info_Default();
	}
 
	// Retorna o CommandInfo
	public function getCommandInfo() {
		return $this->commandInfo;
	}
}
?>

arquivo: index.php

try {
    //Inicia a configuração
    $config = new Config();
    $config->configure();
    //Instancia o Factory e Recupera o Command
    $factory = new Command_Factory();
    $factory->createCommand($config->getCommandInfo())->execute();
} catch (Exception_Pagenotfound $ep) {
    echo '<h1>ERRO 404 - Página não encontrada</h1>';
} catch (Exception $e) {
    echo '<h1>ERRO 500 - Erro na execução</h1>';
}
?&gt;

Vamos agora a partir dessa nova estrutura, alterar o comportamento do FrameWork para utilizar URL amigáveis para acessar os command; Ja existem vários artigos disponíveis na web explicando passo a passo como criar Url’s amigáveis, e a implementação apresentada aqui será totalmente baseada no artigo disponível no fórum do iMasters e escrito por Perfect Lion;

Antes de tudo, é necessário que o modulo rewrite do Apache esteja habilitado dentro do arquivo httpd.conf; Ele é o modulo responsável por redirecionar as requisições, sendo que, a forma de redirecionamento é definida através do arquivo .htaccess, que deve estar localizado na raiz do site;

A Url que vamos utilizar terá o seguinte formato:
http://www.endereco.qualquer/MODULE/ACTION sendo que, caso nenhum dos dois for informado, será utilizado index como padrão;

A seguir, o código do .htaccess adaptado para utilizar no framework:


# << URLs Amigaveis
# verifica se o modulo rewrite está habilitado se sim executa o bloco dentro
# habilita o modulo Rewrite
RewriteEngine On
# Foi comentada essa linha para que o rewrite funcione somente nos arquivos que estão no diretorio do .htaccess
# RewriteBase /
# Verifica se a url digitada é um arquivo caso seja para aqui
RewriteCond %{REQUEST_FILENAME} !-f
# Verifica se a url digitada é uma pasta caso seja para aqui
RewriteCond %{REQUEST_FILENAME} !-d
# Redireciona para o arquivo index.php caso nenhum desses comandos assim seja valido vai para ele.
RewriteRule .(/)?$ index.php
# >> URLs Amigaveis


Vamos agora adaptar a implementação do Perfect Lion para a nossa estrutura, criando assim a classe Command_Info_Rewrite;

arquivo: lib/Command/Info/Rewrite.php

<?php
/**
 * Command_Info utilizando URL Amigável
 *
 * Código Original por Perfect Lion em http://forum.imasters.uol.com.br/index.php?showtopic=203965
 *
 * A unica alteração foi para que o script funcione quando estiver dentro de um diretório no servido, pois o 
 * script original funciona na raiz do servidor
 *
 * @author Everton Emilio Tavares
 */
class Command_Info_Rewrite implements Command_Info {
 
    private $gets;
 
    public function __construct() {
        // Recupera o diretorio em que o sistema se encontra
        echo $diretorio = substr($_SERVER['SCRIPT_FILENAME'],strlen($_SERVER['DOCUMENT_ROOT']),-10);
        // Recupera a URI 
        $uri = $_SERVER["REQUEST_URI"];
        // Recupera os dados da URI. esta sendo utilizada a mesma variável do artigo para melhor entendimento
        $gets = explode("/",str_replace(strrchr($uri, "?"), "", $uri));
        // Primeiro elemento sempre será em branco, então faz um array_shift para remove-lo
        array_shift($gets);
        // Caso o sistema esteja em um diretório, é necessário remover o caminho de pastas do mesmo
        $this->gets = array_slice($gets,sizeof(explode('/',$diretorio)));
    }
 
	// Retorna a primeira parte da URL como o Module
    public function getModule() {
        return $this->gets[0];
    }
    // Retorna a Segunda parte da URL como Action
    public function getAction() {
        return $this->gets[1];
    }
 
}
?>

Basta agora alterarmos a configuração do framework para utilizarmos nossa nova classe:

arquivo: /config.php

<?php
/**
 * Classe de Configuração do FrameWork
 * @author Everton Emilio Tavares
 */
class Config {
	private $commandInfo;
	public function configure() {
		//Configura a Classe que irá ler os parâmetros
		$this->commandInfo = new Command_Info_Rewrite();
	}
 
	// Retorna o CommandInfo
	public function getCommandInfo() {
		return $this->commandInfo;
	}
}
?>

Assim temos nosso Framework configurável e adaptável para qualquer situação e a qualquer tipo de URL sem modificar as classes do coração do FrameWork; É possível ainda possibilitar a configuração de outras partes do FrameWork, como a Factory de Commands, por exemplo;

Códigos desse Artigo

Para tentar melhorar o tratamento de erros, vamos encapsular esse erro em uma função. Vamos chamá-la de erro(), e dentro dela vamos tratar a mensagem e vamos chamar o die para finalizar a execução; Assim teremos, mais ou menos, o seguinte formato:

function erro($mensagem) {
    echo '<h1>Erro na execução do sistema</h1>';
    echo 'Descrição do erro: '.$mensagem;
    die();
}

Vamos aplicar ao nosso factory, para que um erro seja gerado caso o Command não for encontrado;
arquivo: /lib/Command/Factory.php

<?php
class Command_Factory {
     public function createCommand() {
          //Se o module não for informado, ele passa a ser considerado o index;
          $module = (isset($_GET['module'])) ? $_GET['module'] : 'index';
          //A mesma coisa para a action
          $action = (isset($_GET['action'])) ? $_GET['action'] : 'index';
 
          //Deixa a primeira letra em Maiusculo e o resto da string em minusculo
          $module = htmlspecialchars(ucfirst(strtolower($module)));
          $action = htmlspecialchars(ucfirst(strtolower($action)));
 
          //Cria o nome do arquivo da Action
          $fileName = 'command/'.$module.'/'.$action.'.php';
 
          //Se o arquivo existir, carrega-o, caso contrário gera erro
          if (file_exists($fileName)) {
               require_once $fileName;
               //O nome da classe é a Action seguida da String Command
               $className = $action.'Command';
               //Carrega e retorna a Classe
               return new $className();
          } else {
               //Chama nossa função personalizada para tratamentos de erro
               erro('Command não encontrado!');
          }
     }
}
?>

Agora já temos um tratamento único para os erros. E dentro dessa função, pode-se executar uma função para mandar a mensagem de erro para o desenvolvedor por email, ou grava-la em um log; Porem para o desenvolvedor, esse tipo de informação não é algo muito útil. Se houver um erro que não acontece com uma certa freqüência, fica complicado para o desenvolvedor conseguir identificar e reproduzir o erro, pois não sabe o arquivo e o ponto do código que gerou o erro.

Portanto vamos adotar outra política de erros, que é a utilização da função trigger_error, que vem nativo no PHP desde a versão 4.0.1, e tem como objetivo gerar uma mensagem de erro com os niveis E_USER_ERROR,E_USER_WARNING, E_USER_NOTICE, sendo que desses, apenas o E_USER_ERROR termina a execução do sistema; Outro recurso que essa função oferece é a de omitir a notificação de determinados tipos de erros através da função error_reporting, que recebe por parâmetro o nivel do erro que será exibido. Não vamos entrar em detalhes no funcionamento dessa função, mas caso você tenha interesse, pode-se ler o manual dela clicando aqui;

Para capturar os erros gerados por essa função, deve-se criar uma outra função e configurá-la utilizando a função set_error_handler, como a seguir:

function trata_erro($n_erro , $mensagem , $arquivo , $linha , $contexto ) {
    echo '<h1>Erro na execução do sistema</h1>';
    echo 'Descrição do erro: '.$mensagem.'<br />';
    echo 'Local do erro: '.$arquivo.' na linha '.$linha.'';
    die();
}
set_error_handler("trata_erro");

Os parametros recebidos pela função são:

• $n_erro - Tipo do Erro (E_USER_ERROR,E_USER_WARNING, E_USER_NOTICE)
• $mensagem - Mensagem do Erro
• $arquivo - Arquivo onde ocorreu o erro
• $linha - Linha onde ocorreu o erro
• $contexto - Variáveis que existiam no momento em que ocorreu o erro

Com esse mecanismo se torna muito mais fácil para o desenvolvedor poder tratar e identificar os erros, pois temos agora informações do arquivo que gerou o erro, a linha e até as variáveis que existiam no momento que o erro foi lançado, podendo enviar essas informações por email, e/ou grava-las em um log para que possa ser identificada pelo desenvolvedor; Vamos portanto atualizar o nosso Factory;

arquivo: /lib/Command/Factory.php

<?php
class Command_Factory {
     public function createCommand() {
          //Se o module não for informado, ele passa a ser considerado o index;
          $module = (isset($_GET['module'])) ? $_GET['module'] : 'index';
          //A mesma coisa para a action
          $action = (isset($_GET['action'])) ? $_GET['action'] : 'index';
 
          //Deixa a primeira letra em Maiusculo e o resto da string em minusculo
          $module = htmlspecialchars(ucfirst(strtolower($module)));
          $action = htmlspecialchars(ucfirst(strtolower($action)));
 
          //Cria o nome do arquivo da Action
          $fileName = 'command/'.$module.'/'.$action.'.php';
 
          //Se o arquivo existir, carrega-o, caso contrário gera erro
          if (file_exists($fileName)) {
               require_once $fileName;
               //O nome da classe é a Action seguida da String Command
               $className = $action.'Command';
               //Carrega e retorna a Classe
               return new $className();
          } else {
               //Lança erro como E_USER_ERROR para poder finalizar a execução
               trigger_error('Command não encontrado',E_USER_ERROR);
          }
     }
}
?>

Com esse mecanismo o tratamento de erros parece ter ficado mais fácil, porém ainda podemos identificar algumas dificuldades; A primeira é que o erro lançado no Factory não é nada mais que um erro de página não encontrada (erro 404) e não deveria ser exibido para o usuário como um erro fatal;
Também não é possível descobrir os passos feitos pelo usuário até a ocorrência do erro, ou seja, imagine a seguinte função que tem por responsabilidade dividir dois números:

function dividir($n1, $n2) {
   if ($n2 == 0) trigger_error('Não é possivel dividir por zero');
   return $n1 / $n2;
}

Essa função pode ser usada em vários lugares no sistema, e apenas pelo numero da linha e o nome do arquivo é impossível saber em qual das utilizações foi gerado o erro; Outra dificuldade existente é que quando o erro ocorre, a execução do sistema é interrompida imediatamente, e dependendo do erro ocorrido, não é desejável que isso ocorra, como é o caso do exemplo a seguir, onde a mensagem de boas vindas não será exibida caso o erro em dividir ocorra:

$n1 = $_GET['n1'];
$n2 = $_GET['n2'];
$valor = dividir($n1,$n2);
echo 'Resultado: ',$valor,'<br />';
echo 'Obrigado por visitar nosso site!';

Sendo assim, vamos abordar um novo mecanismo de tratamento de erros, que são as Exceptions, que consiste em uma forma Orientada a Objetos para tratamento de exceções no sistema que já existia em diversas linguagens de programação, e que foi adicionado ao PHP somente a partir da versão 5; Se baseia em uma classe chamada Exception que deve ser lançada quando ocorrer um erro ou uma situação inesperada, e possui a possibilidade de existir um ponto de tratamento da exceção para que, quando uma exceção for lançada, a execução do sistema possa parar imediatamente e direcionar a execução para o ponto de tratamento da exceção, onde o sistema possa se recuperar do erro e continuar executando normalmente; Caso a exceção não for tratada, será executado um tratamento interno do PHP; Para entender melhor, veremos um exemplo:

//Alterando a função dividir para a utilização de exception
function dividir($n1,$n2) {
    if ($n2 == 0) {
        //Código do erro (numero inteiro - opcional)
        $codigoDoErro = 10;
        //Lançando a exceção, (throw = lançar)
        throw new Exception("Não é possivel dividir por zero",$codigoDoErro);
    }
    return $n1/$n2;
}
 
//Inicia o bloco que terá as exceções tratadas
try {
    $n1 = $_GET['n1'];
    $n2 = $_GET['n2'];
    $valor = dividir($n1,$n2);
    echo 'Resultado: '.$valor;
//Qualquer exceção lançada dentro do bloco irá executar o bloco de código dentro do catch, onde $e é a exceção lançada no erro
} catch (Exception $e) {
    echo 'Não foi possivel calcular a divisão; Motivo: '.$e->getMessage().'<br />';
}
//Ocorrendo ou não o erro, a mensagem de agradecimento será exibida
echo 'Obrigado por visitar nosso site!';

Qualquer exceção que for lançada dentro do bloco try vai direcionar a execução para o catch presente no final do bloco, que vai tratar a exceção e continuar a execução do sistema normalmente; Dentro da variável $e vem todas as informações do erro gerado, como a mensagem, o código, o arquivo/linha que gerou o erro; Também possui o “trace” da execução, que é um array contendo todos os métodos que foram executados juntamente com seus parâmetros, até chegar no erro lançado, que é uma informação muito útil para o desenvolvedor pois da a possibilidade de ter todos os passos do usuário até o acontecimento do erro; Para maior detalhes, veja a documentação da classe exception aqui;

Outra vantagem do exception é poder criar tipos de erro, e tratá-los de forma diferente; Para isso basta criar uma nova classe de exceção que estende a classe Exception padrão, e adicionar um catch que recebe a nova classe que você criou; Veja como fazer no seguinte exemplo:

//Exceção personalizada para tratamento de erros aritméticos
class ExcecaoAritmetica extends Exception {
    //Valores que serão armazenados no momento de lançar a exceção, e que serão recuperados no tratamento da mesma
    private $valor1,$valor2;
    //Construtor personalizado recebendo os valores da exceção
    public function __construct($mensagem,$codigo,$valor1,$valor2) {
        parent::__construct($mensagem,$codigo);
        $this->valor1 = $valor1;
        $this->valor2 = $valor2;
   }
   //Funções personalizadas para a exceção
   public function getValor1() {
        return $this->valor1;
   }
   public function getValor2() {
        return $this->valor2;
   }
}
 
//Função dividir lançando exceção especifica
function dividir($n1,$n2) {
    if ($n2 == 0) {
        $codigoDoErro = 10;
        //Lançando a exceção 
        throw new ExcecaoAritmetica("Não é possivel dividir por zero",$codigoDoErro,$n1,$n2);
    }
    return $n1/$n2;
}
try {
    $n1 = $_GET['n1'];
    $n2 = $_GET['n2'];
    $valor = dividir($n1,$n2);
    echo 'Resultado: '.$valor;
//Exceções Aritméticas será tratada aqui
} catch (ExcecaoMatematica $em) {
    echo 'Ocorreu um erro aritmético: ',$em->getMessage(),'<br />';
    //Utilizando as funções personalizadas
    echo 'valores informados: ',$em->getValor1(),' e ',$em->getValor2(),'<br />';
    //Demais tratamentos pertinentes
//As outras exceções serão tratadas aqui
} catch (Exception $e) {
    echo 'Ocorreu um erro desconhecido; Motivo: '.$e->getMessage().'<br />';
}
//Ocorrendo ou não o erro, a mensagem de agradecimento será exibida
echo 'Obrigado por visitar nosso site!';

Podemos notar que essa é a melhor opção para o nosso tratamento de erros; então vamos aplicá-la no nosso framework; Primeiramente vamos criar uma nova exceção chamada Exception_Pagenotfound, que será utilizada no Factory de Command e tem por objetivo informar que uma página não foi encontrada;

arquivo: lib/Exception/Pagenotfound.php

//Classe apenas para identificar o tipo do erro
class Exception_Pagenotfound extends Exception {
    //Recebe obrigatoriamente a mensagem, e o codigo pode ser omitido
    public function __construct($mensagem,$codigo = 0) { 
        parent::__construct($mensagem,$codigo);
    }
}

O nosso command ficará da seguinte forma:

arquivo: /lib/Command/Factory.php

<?php
class Command_Factory {
     public function createCommand() {
          //Se o module não for informado, ele passa a ser considerado o index;
          $module = (isset($_GET['module'])) ? $_GET['module'] : 'index';
          //A mesma coisa para a action
          $action = (isset($_GET['action'])) ? $_GET['action'] : 'index';
 
          //Deixa a primeira letra em Maiusculo e o resto da string em minusculo
          $module = htmlspecialchars(ucfirst(strtolower($module)));
          $action = htmlspecialchars(ucfirst(strtolower($action)));
 
          //Cria o nome do arquivo da Action
          $fileName = 'command/'.$module.'/'.$action.'.php';
 
          //Se o arquivo não existir, gera erro
          if (!file_exists($fileName)) {
               throw new Exception_Pagenotfound('Arquivo do Command não encontrado: '.$fileName);
          }
          //Carrega o arquivo
          require_once $fileName;
 
          //O nome da classe é a Action seguida da String Command
          $className = $action.'Command';
 
          //Depois que o arquivo for adicionado, a classe deve existir, caso não existir, o arquivo carregado
          //não contem o Command, então deve gerar outro erro; o parametro false no class_exists 
          //é informado para não carregar a classe utilizando o __autoload
          if (!class_exists($className,false)) {
               throw new Exception_Pagenotfound('Command não foi encontrado: '.$className);
          }               
          //Carrega e retorna a Classe
          return new $className();
     }
}
?>

O tratamento de erros ficará dentro do index.php, onde toda a exceção ocorrida no processo de carregar o Command e excecutá-lo será tratado utilizando um catch para cada tipo de exceção. Note que a classe Exception padrão do PHP deve vir por ultimo, porque senão o tratamento para as classes específicas não serão executados;

arquivo: index.php

<?php
function __autoload($nomeClasse) {
require_once 'lib/'.implode('/',explode('_',$nomeClasse)).'.php';
}
 
try {
    $factory = new Command_Factory();
    $factory->createCommand()->execute();
} catch (Exception_Pagenotfound $ep) {
    echo '<h1>ERRO 404 - Página não encontrada</h1>';
    //O tratamento do Erro não vai ser abordado neste artigo
} catch (Exception $e) {
    echo '<h1>ERRO 500 - Erro na execução</h1>';
    //O tratamento do Erro não vai ser abordado neste artigo
}
?>

A seguir veremos um exemplo de Exception funcionando dentro de um Command:

LerNoticia.php

<?php
class LerNoticiaCommand implements Command {
     public function execute ( ) {
          //Se não conseguir conectar, lança exceção
          if (!mysql_connect('localhost','usuario','senha')) {
              throw new Exception('Não foi possivel conectar com o banco de dados');
          }
          //Se não conseguir selecionar o banco, lança exceção tambem
          if (!mysql_select_db('banco')) {
               throw new Exception('Não foi possivel selecionar o banco de dados');
          }
          $id_da_noticia = $_GET['id'];
          //Verifica se o id passado é um numero 
          if (!is_numeric($id_da_noticia)) {
              throw new Exception('Parâmetro Inválido: '.$id_da_noticia);
          }
 
          //Realiza a busca da Noticia
          $noticia = mysql_query('Select * From Noticia Where id = '.$id_da_noticia);
          //Se não existe a noticia, lança exceção de pagina não encontrada
          if (mysql_num_rows($noticia) == 0) {
              throw new Exception_Pagenotfound('Noticia com id '.$id_da_noticia.' não existe';
          }
          //Continua com a exibição da noticia
     }
}
?>

Portando, podemos perceber que as exceções contem uma gama de recursos que facilitam bastante a vida do programador tanto na correção do erro (informações sobre o erro gerado), no tratamento da ocultação do erro (realizar algum caminho alternativo dentro do catch caso o erro ocorra) e na exibição do erro (exibir de forma diferente determinados tipos de erro), agregando muito mais segurança e praticidade no tratamento de erros no Framework;

Faça o download do resultado final do artigo clicando aqui.

Mas o interessante de se desenvolver seu próprio framework é conhecer o funcionamento do mesmo, e aprender os mecanismos por trás dele para que o nivel de programação do seu código possa ser elevado; Portanto o objetivo principal deste artigo é desenvolver um Framework, para que possa, através da codificação do mesmo compreender os princípios básicos dos frameworks em geral, e conhecer um pouco mais de padrões de Projeto;

Como a maioria dos Frameworks da atualidade, vamos o implementar através do padrão MVC, (Model-View-Controller), que visa separar as camadas de Dados, de Visão e de Controle de forma intercambiável. Na primeira parte vamos desenvolver a parte inicial do Controller que é o responsável pelo fluxo das informações dentro do sistema.

Para muitas pessoas que programam em PHP, a codificação se da em um único arquivo, onde a ação a ser executada era definida a partir de uma variável GET e de IF, que direciona a execução do código dependendo do valor dessa variável; Se for analisar esse código, podemos considerar isso como um pequeno controller, sendo que é a partir dessa idéia iremos desenvolver o Framework;

Sendo assim, a seguir temos nossa primeira versão do nosso Controller, que está “controlando” as actions de um mini-sistema de noticia:

Arquivo: noticias.php

<?php
$acao = $_ GET['action'];
if ($acao == 'ler') {
     $id_da_noticia = $_GET['id'];
     echo 'Lendo a noticia de id '.$id_da_noticia;
} else if ($acao == 'formulario') {
     echo 'Formulário de Cadastro de Noticia';
} else {
     echo 'Home das Noticias';
}
?>

A idéia aqui é intuitiva: Para cadastrar uma nova noticia, invoca-se a URL: noticia.php?action=formulario. Caso o parâmetro action for omitido, ou tiver um valor inválido será exibida uma página listando todas as Noticias cadastradas, que é sera Home do sistema de noticias;

O código é funcional, mantém tudo em um único lugar, porém durante as manutenções, o caos aparece. Com o aumento de tamanho ficará complicado se localizar dentro do arquivo, tanto para encontrar o local para uma correção como para adicionar uma nova action. A fim de conseguir uma melhor organização, vamos começar separando as ações em funções, e em seguida, um switch é utilizado para direcionar o fluxo da aplicação para a função desejada:

Arquivo: noticias.php

<?php
 
function home() {
     echo 'Home das Noticias';
}
 
function ler() {
     $id_da_noticia = $_GET['id'];
     echo 'Lendo a noticia de id '.$id_da_noticia;
}
 
function formulario() {
     echo 'Formulário de Cadastro de Noticia';
}
 
switch($_GET['action']) {
     case 'formulario': formulario();break;
     case 'ler': ler(); break;
     default: home(); break;
}
 
?>

Aparentemente nosso código está significativamente mais legível. Porém o problema da manutenção ainda permanece, o arquivo ficará maior que o da versão anterior, devido a todas as functions que deverão ser criadas; Para melhorar essa organização, vamos separar as funções em arquivos, e incluí-los conforme a action requisitada:

<?php
switch($_ GET['action']) {
     case 'formulario':
          include('formulario.php');
          formulario();
          break;
     case 'ler':
          include('ler.php');
          ler();
          break;
     default:
          include('home.php');
          home();
          break;
}
?>

O código acima aumentou a ainda mais a legibilidade porém a manutenção ainda é trabalhosa pois necessitamos realizar manualmente os includes dos arquivos das funções, o que não é nada empolgante, e caso o nome do arquivo incluído esteja errado, aparecerá um erro, para melhorar esse cenário, vamos adicionar orientação a objetos no nosso código, e também utilizar o padrão de projeto Command;

Esse padrão de projeto, como o próprio nome diz, trata-se de criar classes de comandos, que podem ser executados independentemente ou agrupadas, fornecendo a flexibilidade de serem alternadas em tempo de execução sem muitas mudanças; Cada classe Command implementa uma única interface, que contem um único método, como descrito a seguir:

arquivo: Command.php

<?php
interface Command {
     public function execute ( );
}
?>

Para não nos preocuparmos com os includes, utilizaremos a função __autoload, que tem por responsabilidade, carregar todas as classes que ainda não foram carregadas dentro do script atual; Para maiores informações, veja no site do PHP; Para podermos utiliza-la, o nome do arquivo deve ser padronizado com o nome da Classe. Sendo assim, definimos que o nome da classe sera o nome do arquivo, seguido da string ‘Command’;

Assim teremos:
Formulario.php = FormularioCommand
LerNoticia.php = LerNoticiaCommand
HomeNoticia.php = HomeNoticiaCommand

Como exemplo, vamos criar o Command para a ação de leitura:

LerNoticia.php

<?php
class LerNoticiaCommand implements Command {
     public function execute ( ) {
          $id_da_noticia = $_GET['id'];
          echo 'Lendo a noticia de id '.$id_da_noticia;
     }
}
?>

Simples não? Outra vantagem dessa abordagem é que, se algum curioso tentar acessar o arquivo LerNoticia.php diretamente, ele não irá ver nada, ja que a classe LerNoticiaCommand necessita ser invocada para ser executada;

Assim nosso Controller fica mais simplificado:

arquivo: noticia.php

<?php
 
//Incluindo a interface command, necessária para os command das Action
require_once 'command.php';
 
function __autoload($nomeClasse) {
     $nomeArquivo = substr($nomeClasse,0,-7).'.php';
     require_once $nomeArquivo;
}
 
switch($_ GET['action']) {
     case 'formulario': $command = new FormularioCommand();break;
     case 'ler' : $command = new LerNoticiaCommand();break;
     default : $command = new HomeNoticiaCommand();break;
}
 
$command->execute();
 
?>

O controller ja está bastante prático no momento. Para criarmos uma nova action, basta:

1. Criar um arquivo com uma classe que implemente a interface Command;
2. Adicioná-lo no switch para que ele seja encontrado.

Mas é necessário ainda umas mudanças na organização interna para adaptá-lo nos moldes da orientação a objetos, e um dos principios básico desta abordagem é que devemos separar o que muda do que é estático, e no nosso caso, a parte do código que está sempre em alteração, no período de desenvolvimento, é o switch que diz qual command vai ser executado em qual action; e para separar essa funcionalidade, vamos utilizar mais um padrão de projeto, chamado Factory, que é uma classe cujo papel é instanciar e retornar um Command para a execução, dependendo dos parâmetros informados pela URL. Mais detalhes sobre o padrão factory você pode obter aqui;

Vamos tambem padronizar o nome da factory para que o __autoload possa encontrá-lo, fazendo com que o nome da classe seja o caminho de diretórios dela, separados pelo caractere underline (’_'), além disso vamos separá-las em um diretório específico do nosso framework, que chamaremos de lib; e tambem separaremos as classes de Controller, adicionando-as em um diretório específo, chamado ‘command’;

Nossa Factory terá o seguinte formato:

arquivo: lib/Command/Factory.php

<?php
class Command_Factory {
     public function createCommand() {
          switch($_ GET['action']) {
               case 'formulario': return new FormularioCommand();
               case 'ler' : return new LerNoticiaCommand();
               default : return new HomeNoticiaCommand();
          }
     }
}
?>

e o nosso novo __autoload, juntamente com o novo controller, ficará assim

arquivo: noticia.php

<?php
 
function __autoload($nomeClasse) {
     //Se a classe terminar com Command, carrega o arquivo da maneira 'antiga';
     if (substr($nomeClasse,-7) === 'Command') {
          $nomeArquivo = 'command/'.substr($nomeClasse,0,-7).'.php';
     } else {
          $nomeArquivo = 'lib/'.implode('/',explode('_',$nomeClasse)).'.php';
     }
     require_once $nomeArquivo;
}
 
$factory = new Command_Factory();
$factory->createCommand()->execute();
 
?>

E se quisermos ter, alem das noticias, um sistema para exibição de galeria de fotos no site? teremos que criar outro Factory? outro Controller?
R.: Não! podemos mudar nossa factory para que possa adicionar mais tipos de ’subsistemas’ no framework;

Para tanto necessitaremos de parametro adicional na URL que será chamado de ‘module’; Nossa Factory terá que ler esses dois parâmetros para direcionar o fluxo de informações ao Command correto; Sendo assim:

arquivo: lib/Command/Factory.php

<?php
 
class Command_Factory {
     public function createCommand() {
          switch($_GET['module']) {
               case 'noticia':
                    switch($_ GET['action']) {
                         case 'formulario': return new FormularioCommand();
                         case 'ler' : return new LerNoticiaCommand();
                         default : return new HomeNoticiaCommand();
                    }
               case 'galeria':
                    switch($_ GET['action']) {
                         case 'vergaleria': return new VerGaleriaCommand();
                         case 'verfoto' : return new VerFotoCommand();
                         default : return new HomeGaleriaCommand();
                    }
               default: 'index': return new IndexCommand();
          }
     }
}
?>

Agora que o nosso controller não é mais específico para noticias, podemos renomea-lo para index.php, fazendo com que seja a pagina principal do sistema;

Poderiamos finalizar nosso controller por aqui, porém ele pode ser melhorado na parte da configuração dos Command, substituindo o switch por um arquivo de configuração (XML, YML, properties), ou podemos simplismente suprimir o switch, fazendo com que a factory encontre a classe Command conforme a estrutura de diretórios. Assim, vamos fazer com que a classe do Command esteja armazenada em um diretório com o nome do modulo a qual ela pertence;

Esse tipo de configuração é chamado de configuração por convenção, que é a que será utilizada no Controller que estamos desenvolvendo; e é preferível, pois a configuração das actions da-se na existência de um único arquivo, que é o próprio arquivo do Command; Vejamos como fica o Command_Factory com esse comportamento:

arquivo: /lib/Command/Factory.php

<?php
class Command_Factory {
     public function createCommand() {
          //Se o module não for informado, ele passa a ser considerado o index;
          $module = (isset($_GET['module'])) ? $_GET['module'] : 'index';
          //A mesma coisa para a action
          $action = (isset($_GET['action'])) ? $_GET['action'] : 'index';
 
          //Deixa a primeira letra em Maiusculo e o resto da string em minusculo
          //Conforme dica de André Caldas, foi adicionado o comando htmlspecialchars para evitar
          //SQL Injection
          $module = htmlspecialchars(ucfirst(strtolower($module)));
          $action = htmlspecialchars(ucfirst(strtolower($action)));
 
          //Cria o nome do arquivo da Action
          $fileName = 'command/'.$module.'/'.$action.'.php';
 
          //Se o arquivo existir, carrega-o, caso contrário gera erro
          if (file_exists($fileName)) {
               require_once $fileName;
               //O nome da classe é a Action seguida da String Command
               $className = $action.'Command';
               //Carrega e retorna a Classe
               return new $className();
          } else {
               //Não vou me preocupar com o tratamento de erros agora, isso será abordado nos           proximos artigos
               die('Erro 404 - Página não encontrada');
          }
     }
}
?>

Tambem é necessário mudar a função __autoload, ja que o carregamento da classe do Command fica agora por responsabilidade da Factory.

arquivo: index.php

<?php
function __autoload($nomeClasse) {
require_once 'lib/'.implode('/',explode('_',$nomeClasse)).'.php';
}
 
$factory = new Command_Factory();
$factory->createCommand()->execute();
 
?>

Arvore de diretório final:

• /
• index.php
• lib/
  • Command.php
  • Command/
    • Factory.php
• Command/
  • Noticia/
    • Lernoticia.php
    • Index.php
    • Listar.php
  • Galeria/
    • Index.php
    • Vergaleria.php
    • Verfoto.php

Com esse recurso, a manutenção do código fica somente por conta dos Commands. Para adicionar um novo, basta apenas criar o arquivo com a classe implementando a interface Command e adicionar no diretório do módulo específico. Muito prático, e rápido; Com esses artifícios ja da para começar a usar o Controller, mas ainda temos muito a fazer;

Editado: Conforme dica de André Caldas, foi adicionado o comando htmlspecialchars no Factory, afim de evitar códigos maliciosos vindos via URL

Clique aqui para fazer o Download do código gerado nessa primeira parte;