KaizenWeb

Mudanças

Everton Emilio Tavares — Thu, 15 Sep 2011 12:33:37 +0000

Novidades!

A partir do mês que vem, mais especificamente do dia 11, estou mudando de emprego, indo para uma empresa de Maringá, onde irei morar.

O M do MVC – Entidades

Everton Emilio Tavares — Tue, 23 Aug 2011 14:43:17 +0000

O modelo de um sistema é composto por vários objetos, cada um com sua resposabilidade e comportamento, e vamos nessa série tentar abordar um por um, e o primeiro tipo de objeto que vamos ver são as entidades.

Entidades são objetos de dominio que são identificados unicamente por uma identidade. Para exemplificar, vamos considerar um sistema simples de cadastro de clientes.

Olhando este modelo é fácil de identificar que não pode existir clientes duplicados, e sendo assim, podemos considerar logo de cara que Cliente é uma entidade dentro do modelo. Para identificar cada um unicamente precisamos de uma identidade, e para isso podemos utilizar o CPF ou CNPJ, que irá nos garantir que os clientes são diferentes independente se existe algum outro com o mesmo nome, pai, mãe, etc… (acha impossivel? ), sendo assim, consideramos que dois clientes são o mesmo se e somente se a identidade dos dois forem iguais. Cada cliente pode ter um ou mais endereços. Se estes endereços forem utilizados apenas para correspondência ou coisas afins, não tem porque ter uma identidades, agora se ele for utilizado para gerar relatórios de vendas, ou coisas do gênero, é importante que tenha uma identidade bem definida.

Como implementar uma entidade?
Para exemplificar, vamos utilizar a classe de cliente pessoa fisica, que possui as seguintes caracteristicas:
- Possui o CPF como identidade, onde este campo é obrigatório; (ps. Antigamente (muito antigamente) casais podiam compartilhar o mesmo CPF, mas não vamos considerar isso neste exemplo)
- Armazena o nome separado do sobrenome, onde os dois campos são obrigatórios;
- Armazena a data do cadastro do cliente, tambem obrigatória;
- Cada cliente possui um valor de bonus onde ele pode trocar por produtos, inicializando com zero.

Implementar isso é muito simples! Basta criar uma classe que armazena todos esses valores! Vamos lá:


class ClientePessoaFisica {
 
    private $cpf;
    private $nome;
    private $sobrenome;
    private $dataCadastro = date();
    private $valorBonus = 0;
 
    // Trabalho facilitado com http://www.shuchow.com/gettersetter.html
 
    public function getCpf() { return $this->cpf; }
    public function getNome() { return $this->nome; }
    public function getSobrenome() { return $this->sobrenome; }
    public function getDataCadastro() { return $this->dataCadastro; }
    public function setCpf($x) { $this->cpf = $x; }
    public function setNome($x) { $this->nome = $x; }
    public function setSobrenome($x) { $this->sobrenome = $x; }
    public function setDataCadastro($x) { $this->dataCadastro = $x; }
    public function getValorBonus() { return $this->valorBonus; }
    public function setValorBonus($x) { $this->valorBonus = $x; }
}
?>

Ficou com muitas linhas né? E conforme esta entidade for crescendo o numero de campos, vai aumentar ainda mais as linhas! Como o PHP é mais inteligente que isso, vamos automatizar esse processo, utilizando um dos famosos métodos mágicos, chamado __call. O funcionamento dele é muito simples: Toda vez que for invocado um método da classe que não existe, o PHP redireciona para este método informando o nome do método e os parâmetros informados. Sendo assim, podemos criar setters e getters dinâmicos, economizando tempo suficiente para tomar uma xícara de café a mais durante o dia. Veja:


class ClientePessoaFisica {
    private $cpf;
    private $nome;
    private $sobrenome;
    private $dataCadastro = date();
    private $valorBonus = 0;
 
    /**
     * Método simples, sem muita validação.
     * Se quiser um mais completo veja: http://cborrow.wordpress.com/2010/09/18/dynamic-getter-and-setters-in-php/
     */
    public function __call( $sMetodo, $aValor ) {
        if (preg_match('/set(.+)/A', $sMetodo, $aMatch)) {
            // Se for um set...
            $this->$aMatch[1] = $aValor[0];
        } else if (preg_match('/get(.+)/A', $sMetodo, $aMatch)) {
            // Se for um get
            return $this->$aMatch[1];
        }
    }
}
?>

Muito simples, muito fácil, muito prático. Veja nossa super classe em funcionamento:


    $cliente = new ClientePessoaFisica();
    $cliente->setNome("José");
    $cliente->setValorBonus(9000);
 
    echo "Meu cliente favorito é o "+$cliente->getNome()+" por isso ele tem "+$cliente->getValorBonus()+" reais de bonus";
?>

Opa, mas tem um problema nessa classe… no exemplo foi instanciado cliente sem CPF, e não pode existir cliente sem CPF pois este é a identidade do cliente. Também foi possível instanciar sem o sobrenome do cliente, e tudo isso torna esse cliente inválido perante ao modelo, pois está inconsistente com as regras que o definem. Para solucionar este problema, impedindo instanciar classes inconsistentes, basta criar um construtor! Veja como:


class ClientePessoaFisica {
    private $cpf;
    private $nome;
    private $sobrenome;
    private $dataCadastro;
    private $valorBonus;
 
    public __construct($cpf, $nome, $sobrenome) {
        $this->cpf = $cpf;
        $this->nome = $nome;
        $this->sobrenome = $sobrenome;
        $this->dataCadastro = date();
        $this->valorBonus = 0;
    }
 
    /**
     * Método simples, sem muita validação.
     * Se quiser um mais completo veja: http://cborrow.wordpress.com/2010/09/18/dynamic-getter-and-setters-in-php/
     */
    public function __call( $sMetodo, $aValor ) {
        if (preg_match('/set(.+)/A', $sMetodo, $aMatch)) {
            // Se for um set...
            $this->$aMatch[1] = $aValor[0];
        } else if (preg_match('/get(.+)/A', $sMetodo, $aMatch)) {
            // Se for um get
            return $this->$aMatch[1];
        }
    }
}
?>

O Construtor impede que não seja possível cadastrar clientes sem as 3 informações obrigatórias. Ele também inicializa a classe, setando os valores iniciais para o bônus e para a data de cadastro. Veja agora como ficou a classe utilizando o construtor:


    $cliente = new ClientePessoaFisica("000.000.000-00", "José", "Silva");
    $cliente->setValorBonus(9000);
    echo "Meu cliente favorito é o "+$cliente->getNome()+" por isso ele tem "+$cliente->getValorBonus()+" reais de bonus";
?>

Mas ainda não podemos dizer que nossa entidade está completa pois, se notarem o exemplo acima, estamos instanciando um cliente informando um CPF inválido. Para corrigir isso, basta validar o CPF informado no construtor, e para completar, adicionamos as validações para que não seja informado valores nulos para o nome e o sobrenome.


class ClientePessoaFisica {
    private $cpf;
    private $nome;
    private $sobrenome;
    private $dataCadastro;
    private $valorBonus;
 
    public __construct($cpf, $nome, $sobrenome) {
        Validator::validaCpf($cpf, "Somente CPF válido é permitido");
        Validator::validaNotNull($nome, "Um nome deve ser informado");
        Validator::validaNotNull($sobrenome, "Um sobrenome deve ser informado");
        $this->cpf = $cpf;
        $this->nome = $nome;
        $this->sobrenome = $sobrenome;
        $this->dataCadastro = date();
        $this->valorBonus = 0;
    }
 
    /**
     * Método simples, sem muita validação.
     * Se quiser um mais completo veja: http://cborrow.wordpress.com/2010/09/18/dynamic-getter-and-setters-in-php/
     */
    public function __call( $sMetodo, $aValor ) {
        if (preg_match('/set(.+)/A', $sMetodo, $aMatch)) {
            // Se for um set...
            $this->$aMatch[1] = $aValor[0];
        } else if (preg_match('/get(.+)/A', $sMetodo, $aMatch)) {
            // Se for um get
            return $this->$aMatch[1];
        }
    }
}
?>

Agora se tentar passar um valor inválido para a entidade, será barrado pela validação e recebera uma linda e charmosa exception como consolo. Porém, se você perceber nossa classe ainda não está totalmente completa. Lembra que tentamos facilitar nossa vida utilizando o método mágico __call para ganhar uma xícara de café a mais? pois esse método abriu uma brecha na integridade da classe; Veja o exemplo:


    // CPF gerado em http://www.geradorcpf.com/ . Se ele for o seu, me perdoe, não foi intencional
    $cliente = new ClientePessoaFisica("875.618.570-71", "José", "Silva");
    $cliente->setCpf("000.000.000-00"); // Setando um CPF inválido sem gerar erro
    $cliente->setValorBonus(9000);
    echo "Meu cliente favorito é o "+$cliente->getNome()+" por isso ele tem "+$cliente->getValorBonus()+" reais de bonus";
?>

Esse é o problema de se utilizar métodos mágicos, pois ele expõe todos os valores da entidade a alteração, e isso não é desejável para alguns casos, pois, depois de instanciado um cliente, não deve ser permitido alterar o seu CPF, o nome e o sobrenome podem ser alteráveis, mas teríamos que validar se o valor que está sendo informado está correto, e isso também não é possível de fazer facilmente com essa abordagem. Mesmo se implementássemos uma configuração específica para cada campo, isso tornaria o código muito difícil de entender, e qualquer regra nova não contemplada pela configuração, ou algum calculo que possa ser executado quando setar um novo valor, teríamos um trabalhão para aplicar. Sendo assim, acredito que a melhor abordagem para a entidade é voltar ao nossos antigos e eficientes “setters” e “getters”, porém, com alterações para que a entidade se mantenha integra:


class ClientePessoaFisica {
 
    private $cpf;
    private $nome;
    private $sobrenome;
    private $dataCadastro = date();
    private $valorBonus = 0;
 
    public __construct($cpf, $nome, $sobrenome) {
        Validator::validaCpf($cpf, "Somente CPF válido é permitido");
        $this->cpf = $cpf;
        $this->setNome($nome); // Centraliza a validação de nome
        $this->setSobrenome($sobrenome); // Centraliza a validação de sobrenome
        $this->dataCadastro = date();
        $this->valorBonus = 0;
    }
 
    // public function setCpf($x) { $this->cpf = $x; } Não pode alterar o CPF!
    // public function setDataCadastro($x) { $this->dataCadastro = $x; } Não pode alterar a data de cadastro!!
 
    public function setNome($nome) { 
        Validator::validaNotNull($nome, "Um nome deve ser informado");
        $this->nome = $nome; 
    }
 
    public function setSobrenome($sobrenome) { 
        Validator::validaNotNull($sobrenome, "Um sobrenome deve ser informado");
        $this->sobrenome = $sobrenome; 
    }
 
    public function setValorBonus($valor) { 
        Validator::notNegative($valor, "Não é permitido bônus negativo");
        $this->valorBonus = $valor; 
    }
 
    // Getters...
    public function getCpf() { return $this->cpf; }
    public function getNome() { return $this->nome; }
    public function getSobrenome() { return $this->sobrenome; }
    public function getDataCadastro() { return $this->dataCadastro; }
    public function getValorBonus() { return $this->valorBonus; }
}
?>

Agora sim podemos dizer que nossa classe está integra e ela possui garantias de que ninguem irá quebrar sua integridade. Dá um pouco mais de trabalho para codificar, mas agora temos um código limpo, fácil de entender e alterar, e você vai poder ficar tomando seu cafézinho em vez de ficar explicando pro estagiário novo como criar e modificar uma entidade nova que utiliza o método mágico “__call”; Ou corrigindo os problemas que o estagiário por esquecer no meio do sistema um código de teste que modificouo CPF do cliente mais importante da loja.
Agora podemos vamos utilizar nossa classe:

 

    // CPF gerado em http://www.geradorcpf.com/ . Se ele for o seu, me perdoe, não foi intencional
    $cliente = new ClientePessoaFisica("875.618.570-71", "José", "Silva");
    //$cliente->setCpf("000.000.000-00"); // Isso não é mais possível
    $cliente->setValorBonus(9000);
    echo "Meu cliente favorito é o "+$cliente->getNome()+" por isso ele tem "+$cliente->getValorBonus()+" reais de bonus";
 
    // Utilizando uma bonificação de 200 reais
    $novoBonus = $cliente->getValorBonus() - 200;
    $cliente->setValorBonus($novoBonus);
 
?>

Vou finalizar por aqui este artigo, mas ja adiantando que ainda temos muito a melhorar nessa nossa entidade. No proximo item da série vou falar de coesão e acoplamento nas entidades.

Até la

O M do MVC (Introdução)

Everton Emilio Tavares — Tue, 16 Aug 2011 12:42:29 +0000

A partir de hoje vou iniciar uma nova série falando apenas da camada de Modelo, que foi muito pedida pra mim, e vejo que é uma grande icógnita. Acredito que o MVC (Model, View, Controller) é o conceito de desenvolvimento mais conhecido, difundido, defendido e utilizado por programadores de todas as linguagens de programação.

Modelo é um conceito muito utilizado em programação, porém, muitas vezes, com diversos significados diferentes. Eu considero modelo como sendo a abstração de um domínio. Eu explico: Domínio é a área (ou ramo) de conhecimento de um sistema, como por exemplo, área financeira, escolar, industrial, e Modelo é o sub-conjunto de informações e operações do domínio que será utilizada na aplicação, e isso depende muito do tipo de aplicação que se deseja implementar.

Por exemplo, um sistema de controle de alunos, pertence ao domínio escolar, e o modelo é composto pelas caracteristicas de cada aluno (nome, telefone, endereço), pais, turmas, matérias, professores, entre outros. Agora imagine um sistema que apenas utiliza métodos de inteligência artificial para realizar a distribuição de horários entre os professores. Ele também pertence ao domínio escolar, porém o modelo dele é composto apenas pelas matérias, turmas e seus respectivos professores, pois não é necessário o nome de cada aluno para essa aplicação. Ou seja, o domínio é o mesmo, porém o modelo é mais reduzido.

Outra particularidade que se deve observar é que, por mais que os dois sistemas contenham informações sobre professores, matérias e turmas, os casos de uso que cada sistema realiza encima dessas informações também são diferentes, por isso é correto afirmar que o modelo abrange, além da abstração de dados do domínio que a aplicação irá manipular, também as operações (casos de uso) que a aplicação é capaz de fazer. Sendo assim, a camada Model do MVC deve ser responsável por todos os dados e comportamentos que pertencem ao modelo da aplicação.

Acontece que em muitos tutoriais que existem circulando pela internet, eu vejo que a camada de Modelo é representada como sendo apenas uma forma de abstrair o banco de dados para recuperar as informações, e isso acontece inclusive em sites de referência, como por exemplo a documentação do CodeIgniter. Veja:

class Blogmodel extends CI_Model {
 
    var $title   = '';
    var $content = '';
    var $date    = '';
 
    function __construct()
    {
        // Call the Model constructor
        parent::__construct();
    }
 
    function get_last_ten_entries()
    {
        $query = $this->db->get('entries', 10);
        return $query->result();
    }
 
    function insert_entry()
    {
        $this->title   = $_POST['title']; // please read the below note
        $this->content = $_POST['content'];
        $this->date    = time();
 
        $this->db->insert('entries', $this);
    }
 
    function update_entry()
    {
        $this->title   = $_POST['title'];
        $this->content = $_POST['content'];
        $this->date    = time();
 
        $this->db->update('entries', $this, array('id' => $_POST['id']));
    }
 
}

Essa abordagem, apesar de facilitar o desenvolvimento, nos força a colocar as regras de negócio, dentro do controller, misturando assim as camadas M (Model) e C (Controller). Na próxima parte vou abordar a construção e organização de entidades, evitando assim essa mistura indesejada;

Vocês concordam? não concordam? Coloquem suas opiniões nos comentários!!

Ps. Eu não sou contra o CodeIgniter, pelo contrário, gosto muito do Framework, porém é necessário alguns “hacks”, que eu vou mostrar no próximo post.

Criando um FrameWork PHP do Zero Usando Padrões de Projeto (Parte 4)

Everton Emilio Tavares — Mon, 27 Dec 2010 17:32:14 +0000

Olá

Hoje veremos o padrão Composite, que é um padrão que tem um nome meio que “auto-explicativo”; Composite é um padrão que define objetos que é formado pela composição de outros objetos, permitindo assim tratar vários objetos como se fosse um só.

Para exemplificar o funcionamento do padrão composite, vamos utilizar a classe guerreiro utilizada na parte 3 do artigo; Caso você perdeu, leia aqui; Veja novamente a nossa implementação de Guerreiro:

//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();
    }
}

Para iniciar uma “Guerra”, basta criar alguns guerreiros, e mandar eles lutar! Portanto:

$guerreiro1 = new Guerreiro(new ArcoFlecha());
$guerreiro2 = new Guerreiro(new Espada());
$guerreiro3 = new Guerreiro(new Machado());
 
$guerreiro1->lutar();
$guerreiro2->lutar();
$guerreiro3->lutar();

Veja que o trabalho de manutenção nesse código é relativamente grande, pois quando for necessário adicionar mais guerreiros, será preciso sempre adicionar mais duas linhas de código: Uma para instanciar um novo objeto, e outra para mandar o guerreiro lutar, e é nesse cenário que o padrão Composite vem nos ajudar.

O padrão composite permite a manipulação de vários objetos como se fossem um objeto só, facilitando assim a nossa “guerra”, ou seja, podemos criar um “exército de guerreiros” e mandar todo mundo lutar com apenas um comando. Sendo assim, primeiramente temos que extrair uma interface que represente os nossos guerreiros, para que seja possivel alternar entre o uso da nossa classe Guerreiro definida acima, e o uso do nosso composite que compõe vários guerreiros. A nivel de exemplo, vamos manter apenas o método “lutar”, e a interface vai ficar da seguinte forma:

interface IGuerreiro {
 
    public function lutar();
 
}

Para quem não sabe, uma interface é como se fosse um contrato, onde as classes que a implementam devem ter os métodos e parâmetros definidos por ela. Neste caso, as classes que implementam IGuerreiro devem implementar apenas o método lutar.

 
//Implementação anterior de Guerreiro, agora implementando IGuerreiro
class Guerreiro implements IGuerreiro {
    private $arma;
    public function __construct(Arma $arma) {
        $this->arma = $arma;
    }
 
    public function lutar() {
        // Implementação da luta
        $this->arma->golpear();
    }
}
 
// Implementação do composite de Guerreiro
class GuerreiroComposite implements IGuerreiro {
 
    private $guerreiros;
 
        // Método que adiciona os guerreiros no composite
    public function add(IGuerreiro $guerreiro) {
        $this->guerreiros[] = $guerreiro;
    }
 
        // O método lutar deve fazer todos os guerreiros lutarem
    public function lutar() {
        foreach ($guerreiro => $this->guerreiros) {
            $guerreiro->lutar();
        }
    }
 
}

Agora para enviar um exercito de guerreiros para a batalha, basta criar alguns guerreiros, e adicioná-los no composite através do método add, e pronto! Notem que o método add contem o tipo permitido para o parâmetro, para impedir que qualquer outra classe seja adicionada no Composite, mesmo essa outra classe contendo os mesmos métodos da interface. No exemplo a seguir, temos um exercito de arqueiros partindo pra luta:

$exercitoDeArqueiros = new GuerreiroComposite();
$exercitoDeArqueiros->add(new Guerreiro(new ArcoFlecha()));
$exercitoDeArqueiros->add(new Guerreiro(new ArcoFlecha()));
$exercitoDeArqueiros->add(new Guerreiro(new ArcoFlecha()));
$exercitoDeArqueiros->add(new Guerreiro(new ArcoFlecha()));
$exercitoDeArqueiros->add(new Guerreiro(new ArcoFlecha()));
 
$exercitoDeArqueiros->lutar();

Como tanto Guerreiro quanto GuerreiroComposite implementam a interface IGuerreiro, podemos fazer um Composite conter outro composite, como no exemplo a seguir:

$exercitoDeArqueiros = new GuerreiroComposite();
$exercitoDeArqueiros->add(new Guerreiro(new ArcoFlecha()));
// .. Demais arqueiros
 
$exercitoDaMachadinha = new GuerreiroComposite();
$exercitoDaMachadinha->add(new Guerreiro(new Machado()));
// .. Demais guerreiros de machado
 
$exercitoNervoso = new GuerreiroComposite();
$exercitoNervoso->add(new Guerreiro(new Espada()); // Tem um diferentão que resolveu lutar de espada
$exercitoNervoso->add($exercitoDaMachadinha);
$exercitoNervoso->add($exercitoDeArqueiros);
$exercitoNervoso->lutar();

Agora que ja foi explicado o funcionamento do padrão, vamos passá-lo para o nosso Framework.

Toda boa aplicação Web possui alguns elementos que são fundamentais para que ela funcione. Hoje em dia, por exemplo, não encontramos muitas aplicações que não trabalham com banco de dados, ou que não armazenem informações de acesso, e com as aplicações que possivelmente serão desenvolvidas com o nosso framework não é diferente, e sendo assim, vamos supor que nosso sistema irá trabalhar com o banco Mysql, e para isso vamos adicionar uma conexão simples de banco de dados mysql ao nosso projeto:

arquivo: index.php

try {
    //Inicia a configuração
    $config = new Config();
    $config->configure();
 
    // Vamos adicionar aqui para não precisar adicionar dentro dos commands
    $dbname="teste"; // Indique o nome do banco de dados que será aberto
    $usuario="admin"; // Indique o nome do usuário que tem acesso
    $password="SenhaDoAdmin"; // Indique a senha do usuário
    mysql_connect("localhost",$usuario,$password) or dir(mysql_error());
    mysql_select_db($dbname,$id) or die(mysql_error());
 
    //Instancia o Factory e Recupera o Command
    $factory = new Command_Factory();
    $factory->createCommand($config->getCommandInfo())->execute();
 
    mysql_close();
} catch (Exception_Pagenotfound $ep) {
    echo 'ERRO 404 - Página não encontrada
';
} catch (Exception $e) {
    echo 'ERRO 500 - Erro na execução
';
}
?>

Observação: Não está em discussão nesse artigo qual a melhor forma ou ferramente de conexão com banco, a idéia aqui é exemplificar a localização desse tipo de mecanismo

Apesar de estar no ponto correto da execução, ou seja, conectando antes da execução do command e fechando após, o local da conexão não está apropriado, pois estamos misturando configuração/codigo de banco de dados com a execução do nosso framework, que é o papel do index, e tambem temos o problema de necessitar alterar o index a cada cliente que desejarmos configurar.
Alguns de vocês devem estar pensando: “Porque não cria um arquivo separado com a conexão e faz um include?”. Essa realmente é uma prática utilizada por vários programadores PHP, e que com certeza resolve nosso problema, porem devemos remover o mysql_close do final do arquivo, se não iremos condicionar o sistema a utilizar somente mysql (o que não é desejável); Vejamos como ficou:

arquivo: index.php

try {
    //Inicia a configuração
    $config = new Config();
    $config->configure();
 
    // Incluimos o arquivo de conexão com todo o código da conexão
    include("conexao.php");
 
    //Instancia o Factory e Recupera o Command
    $factory = new Command_Factory();
    $factory->createCommand($config->getCommandInfo())->execute();
 
    // mysql_close(); Removido!!
} catch (Exception_Pagenotfound $ep) {
    echo 'ERRO 404 - Página não encontrada
';
} catch (Exception $e) {
    echo 'ERRO 500 - Erro na execução
';
}
?>

Com certeza funciona, mas podemos utilizar uma solução mais orientada a objetos, não podemos? Então vamos criar uma classe para essa conexão. Ela conterá dois métodos: init e finish, que serão executados antes e depois da execução respectivamente;

Conexao.php

class Conexao {
 
    public function start() {
        $dbname="teste"; // Indique o nome do banco de dados que será aberto
        $usuario="admin"; // Indique o nome do usuário que tem acesso
        $password="SenhaDoAdmin"; // Indique a senha do usuário
        mysql_connect("localhost",$usuario,$password) or dir(mysql_error());
        mysql_select_db($dbname,$id) or die(mysql_error());
    }
 
    public function finish() {
        mysql_close(); // Agora da pra colocar novamente
    }   
}

Adicionando a utilização da classe e removendo a inclusão do arquivo no index:

arquivo: index.php

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

Agora sim, temos uma solução totalmente orientada a objetos (totalmente não, pois a conexão com o mysql não é OO), e podemos utilizar o Mysql em nossa aplicação, mas ainda não temos uma solução ideal, pois o mecanismo está preso a classe Conexao, e caso existir a necessidade de alternar entre tipos diferentes de conexão ou simplesmente alterar a configuração, por exemplo, ficamos presos a edição do arquivo conexao.php;
Vamos então alterar nosso código para utilizar o padrão Strategy, que foi visto na parte 3, que irá permitir a gente trocar a classe de implementação da conexão, permitindo ainda a reutilização das classes. Primeiramente é necessário criar uma interface, que irá nos possibilitar a troca da implementação, e vamos fazer com que a nossa classe de configuração retorne a implementação desejada. Eis as alterações:

arquivo: Conexao.php

// Interface para a conexão
interface Conexao {
 
    // Método que será executado na inicialização da requisição
    public function start();
 
    // Método que será executado na finalização da requisição
    public function finish();
}

E agora transferimos a conexão do mysql para uma classe separada, que implementa a conexão:

arquivo: Conexao/Mysql.php

class Conexao_Mysql implements Conexao {
 
    public function start() {
        $dbname="teste"; // Indique o nome do banco de dados que será aberto
        $usuario="admin"; // Indique o nome do usuário que tem acesso
        $password="SenhaDoAdmin"; // Indique a senha do usuário
        mysql_connect("localhost",$usuario,$password) or dir(mysql_error());
        mysql_select_db($dbname,$id) or die(mysql_error());
    }
 
    public function finish() {
        mysql_close(); // Agora da pra colocar novamente
    }
 
 
}

Adicionamos mais um método no Config.php para retornar a conexão desejada.

arquivo: Config.php


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

Alterando o index para funcionar com a configuração;

arquivo: index.php

try {
    //Inicia a configuração
    $config = new Config();
    $config->configure(); // Devemos configurar antes de chamar a conexão
 
    // Recupera a conexão e inicializa ela
    $conn = $config->getConexao();
    $conn->start();
 
    //Instancia o Factory e Recupera o Command
    $factory = new Command_Factory();
    $factory->createCommand($config->getCommandInfo())->execute();
    // Finaliza a conexão
    $conn->finish();
} catch (Exception_Pagenotfound $ep) {
    echo 'ERRO 404 - Página não encontrada
';
} catch (Exception $e) {
    echo 'ERRO 500 - Erro na execução
';
}
?>

Agora temos nosso método de conexão totalmente personalizável! Quando desejarmos personalizar nossa conexão, basta editar somente o arquivo de configuração, e pronto!
Vamos analisar mais profundamente nosso framework. Com certeza o mecanismo de conexão com o banco de dados é fundamental para qualquer aplicação, mas existem outros serviços que podem ser necessário inicializar em toda e qualquer requisição, similar a conexão (como log ou controle de acesso). O framework precisa possibilitar, de maneira fácil, a adição desses mecanismos. Para isto, basta alterar nossa interface de conexão para um nome mais genérico, afim de que ela possa tambem ser utilizada para outros fins. Vamos chama-lá de RequestAction, pois é uma classe de ações que serão realizadas em todas as conexões;

arquivo: RequestAction.php

// Interface para todo e qualquer mecanismo que deve ser executado nas requisições
// É a mesma estrutura da Conexao.php
interface RequestAction {
 
    // Método que será executado na inicialização da requisição
    public function start();
 
    // Método que será executado na finalização da requisição
    public function finish();
}

E agora alteramos a conexão do mysql para implementar a interface RequestAction, em vez de Conexao. Tambem trocamos ela de diretório para ter uma melhor semântica no nome;

arquivo: RequestAction/MysqlConnection.php

class RequestAction_MysqlConnection implements RequestAction {
 
    public function start() {
        $dbname="teste"; // Indique o nome do banco de dados que será aberto
        $usuario="admin"; // Indique o nome do usuário que tem acesso
        $password="SenhaDoAdmin"; // Indique a senha do usuário
        mysql_connect("localhost",$usuario,$password) or dir(mysql_error());
        mysql_select_db($dbname,$id) or die(mysql_error());
    }
 
    public function finish() {
        mysql_close(); // Agora da pra colocar novamente
    }
}

arquivo: Config.php


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

Alterando o index para funcionar com a configuração;

arquivo: index.php

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

Agora temos um mecanismo totalmente genérico que funciona para qualquer coisa, e não somente para conexão com o banco de dados! Caso quisermos fazer um log, é só trocar na configuração o RequestAction_MysqlConnection por uma RequestAction_Log, de forma simples e fácil sem precisarmos mecher com no código do nosso index.php.

Mas, e se quisermos o log e a conexão com o banco? Poderiamos criar uma classe chamada RequestAction_LogAndMysqlConnection, mas não é interessante pois, caso houver vários clientes ou aplicações, o seu sistema de log muito provavelmente será igual para todos. É nesse ponto que entra o nosso amigo Composite! Vamos criar uma classe que compõe vários composites, chamada RequestAction_Composite, que irá possibilitar o reaproveitamento deles. Vamos ao código:

arquivo: RequestAction/Composite.php

RequestAction_Composite implements RequestAction {
 
    private $requestActions = array();
 
    public function add(RequestAction $reqAct) {
        $this->requestActions[] = $reqAct;
    }
 
    public function start() {
        foreach ($this->requestActions as $reqAct) {
            $reqAct->start();
        }
    }
 
    public function finish() {
        foreach ($this->requestActions as $reqAct) {
            $reqAct->finish();
        }
    }
 
}

Agora no nosso config, vamos utiliza-lo para poder utilizar vários RequestActions:

arquivo: Config.php


//Arquivo de configuração do FrameWork
class Config {
    private $commandInfo;
    private $requestAction;
 
    public function configure() {
        //Configura a Classe que irá ler os parâmetros da URL
        $this->commandInfo = new Command_Info_Default();
 
        // Configura os RequestActions
        $this->requestAction = new RequestAction_Composite();
        $this->requestAction->add(RequestAction_MysqlConnection());
        $this->requestAction->add(RequestAction_Log());
        $this->requestAction->add(RequestAction_ControleAcesso());
        // Quantos forem necessários...
    }
 
    // Retorna o CommandInfo
    public function getCommandInfo() {
        return $this->commandInfo;
    }
 
    public function getRequestAction() {
        return $this->requestAction;
    }
}
?>

Agora sim podemos dar como concluída nosso mecanismo de inicialização de recursos, que nos possibilita trocar a implementação com a utilização do padrão Strategy, e também possibilita a utilização de vários mecanismos diferentes em conjunto, e a reutilização deles, com a ajuda do padrão Composite. As configurações continuam sendo feitas em um único local (config.php), mantendo o resto do código do sistema sem a necessidade de alteração.

Voltando a programação normal

Everton Emilio Tavares — Fri, 24 Dec 2010 11:37:55 +0000

Depois de muito tempo, resolvi ressuscitar o blog.

Aconteceu muita coisa durante esse tempo, como meu casamento e o nascimento do meu filho, e para me dedicar melhor a essa fase importante da minha vida, escolhi em deixar o blog de lado, mas agora estou voltando a ativa tendo em mente um monte de novos assuntos para abordar sobre desenvolvimento e arquitetura de software em PHP, e porque não, em outras linguagens.

Para começar ja coloco novamente os posts antigos sobre o desenvolvimento de um FrameWork PHP, e logo estarei postando a quarta parte da série. Também estou preparando um artigo sobre testes, que é algo muito esquecido e algumas vezes mal visto pelos programadores, mas que é uma grande ferramenta para os programadores.

Então, até logo.

Criando um FrameWork PHP do Zero Usando Padrões de Projeto (Parte 3)

Everton Emilio Tavares — Fri, 24 Dec 2010 01:31:29 +0000

Todo bom FrameWork tem que nos dar a possibilidade de personalizá-lo, e um dos requisitos mais necessários de personalização é a URL, e nesse artigo será explicado como obter essa funcionalidade utilizando o padrão de projeto Strategy, que tem por objetivo trocar dinamicamente o comportamento da aplicação;

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,


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:


 
//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:


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


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


//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 'ERRO 404 - Página não encontrada
';
} catch (Exception $e) {
    echo 'ERRO 500 - Erro na execução
';
}
?>

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


/**
 * 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


/**
 * 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

Criando um FrameWork PHP do Zero Usando Padrões de Projeto (Parte 2)

Everton Emilio Tavares — Thu, 23 Dec 2010 11:27:47 +0000

Nessa parte da construção do FrameWork, não vamos utilizar padrões de projetos, e sim, vamos analisar as estruturas de tratamento de erros fornecidas pelo PHP, e escolher a abordagem que melhor se encaixa no FrameWork; Se você perdeu a primeira parte, pode ler ela clicando aqui;

Como foi observado, a nossa factory gera um erro quando não encontra o command solicitado, e esse foi tratado utlilizando a função die, que interrompe a execução exibindo uma mensagem; esse tratamento é o tratamento básico que encontramos em diversos tutoriais de PHP espalhados pela net, e é eficaz para quando o erro ocorrido impede a continuação da execução;
A desvantagem de utilizar esse método em um sistema “real”, é a falta de controle que temos sobre ele, pois a chamada a esta função finaliza a execução, exibe a mensagem para o usuário e só! não existe uma forma de mudar o comportamento para que possamos tratar o erro, gerar log, enviar a mensagem por email, etc… e sendo assim, o desenvolvedor vai ficar sabendo do erro através do usuário do sistema, o que não é uma idéia muito interessante;

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 'Erro na execução do sistema
';
    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


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 'Erro na execução do sistema
';
    echo 'Descrição do erro: '.$mensagem.'
';
    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


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,'
';
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().'
';
}
//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(),'
';
    //Utilizando as funções personalizadas
    echo 'valores informados: ',$em->getValor1(),' e ',$em->getValor2(),'
';
    //Demais tratamentos pertinentes
//As outras exceções serão tratadas aqui
} catch (Exception $e) {
    echo 'Ocorreu um erro desconhecido; Motivo: '.$e->getMessage().'
';
}
//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


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


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


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 inteiro
          if (!is_int($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.

Criando um FrameWork PHP do Zero Usando Padrões de Projeto (Parte 1)

Everton Emilio Tavares — Wed, 22 Dec 2010 11:29:02 +0000

Hoje em dia, para um bom desenvolvimento de softwares em PHP é imprescindível o uso de um Framework. Existe vários disponíveis, dentre eles podemos citar: Symfony; Prado; Zend; Cake, etc. Mas mesmo com tantos frameworks disponíveis atualmente, será que vale a pena o desenvolvimento de mais um framework? Realmente não compensa, já que quase todos os frameworks já possui uma quantidade grande de usuários e de sistemas desenvolvidos, fazendo com que esses frameworks sejam confiáveis e robustos;

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


$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


 
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:


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


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


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


 
//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:

Criar um arquivo com uma classe que implemente a interface Command;
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


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


 
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


 
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


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

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;