Como criar sua própria biblioteca PHP

No PHP é possível construir e usar as próprias bibliotecas de funções e arquivos mais comumente usados. Esta prática ajuda significativamente na produtividade de um desenvolvedor.
Não demora muito para um programador iniciante perceber que, à medida em que avança em um projeto de software, muito do que está fazendo é repetitivo — conectar ao banco de dados, fornecer feedback do sistema aos usuários etc.
Capa do tutorial PHP - a função include e require
Neste texto, vou mostrar como tirar código referente a tarefas repetitivas em arquivos de bibliotecas, para ser compartilhado entre os vários módulos de um ou vários sistemas.
O encapsulamento ou modularização não é uma dica. Trata-se mais de uma técnica de programação que vale a pena incorporar ao seu dia a dia, o quanto antes.
A principal vantagem desta técnica é não precisar repetir código a cada novo programa que você criar.
Escreva uma vez, use várias.
Uma das funções mais usadas é a da conexão. Se um sistema precisa, em diversos momentos, se conectar a um banco de dados, basta escrever a rotina de conexão (com todas as informações de que ela precisa) uma vez só, dentro de uma função. A partir daí, toda vez que alguma parte do seu sistema precisar fazer uma conexão, usa o código que já está pronto.
É preciso pensar nisto o tempo todo, enquanto se está projetando um sistema ou, mesmo, digitando o código — como escrever o mínimo possível de código e reaproveitar o máximo.
Há outras vantagens em se adotar esta metodologia:

  • Portabilidade facilitada — Você pode iniciar novos projetos, com as bibliotecas de funções que você sabe que foram exaustivamente testadas e que funcionam. Elas podem ser levadas a outro computador, pode ser disponibilizadas a outros desenvolvedores na rede etc.
    Se você tem uma função que conecta a algum banco de dados, ela pode ser usada em outro sistema, com outro banco de dados. Para isto, basta alterar os parâmetros com que a função é chamada. A função, em si, permanece sempre a mesma.
  • Manutenção facilitada — Se, nesta mesma função, houver algum erro, basta corrigi-lo uma vez. Não há necessidade de corrigir o erro em cada módulo de programa que faz alguma conexão.

Se você tem interesse em aprender mais sobre metodologia de programação, sugiro ler sobre o MVC. Ao usar a caixa de busca, no topo do site, é possível também encontrar vários outros artigos sobre programação.

Como chamar funções e arquivos externos no PHP

Neste texto, vou me concentrar em mostrar como aplicar a metodologia de modularizar seus scripts em PHP. É simples e os exemplos podem ser adaptados a outras linguagens.
A linguagem PHP, provê a declaração include que permite incluir código de um arquivo externo, em seu script, incorporando-o.
Este mecanismo torna a inclusão de bibliotecas mais natural.
Assim, você pode pôr várias pequenas funções importantes em um arquivo arquivo.php (ele pode ter qualquer outro nome ou extensão) e chamá-lo de qualquer script que possa vir a precisar das informações que lá estiverem contidas.
Basta incluir, em seu código PHP, o seguinte:

include "arquivo.php";

Todas as funções e variáveis que estiverem definidas e declaradas dentro do arquivo arquivo.php, passam a poder ser usadas no script que o incluiu.
O conteúdo dos arquivos include PHP deve seguir as mesmas normas que qualquer outro arquivo PHP.

Alternativas a declaração include no PHP

Alternativamente e de acordo com suas necessidades, é possível usar outras formas de trazer informações externas.
Veja quais são:
A declaração require, que quer dizer requeira ou requisite, em uma tradução livre, faz a leitura do arquivo externo mesmo que o contexto da execução não passe por onde ele se encontra dentro do código. Em outras palavras, ele carrega obrigatoriamente o código externo.
Exemplo:

require "functions.php";

Outra possibilidade é que o código externo já tenha sido lido e carregado, por alguma rotina no seu sistema e ele encontrar outro require ou include para carregar novamente o mesmo arquivo.
Para evitar que isto ocorra, use as variações include_once e require_once.
Estas duas verificam se o código externo já foi incluído ou requerido anteriormente — evitando, assim, redundâncias.

Referências: Wikipedia: encapsulamento ou modularização.

PHP, MVC e hello world!

Neste post, vamos abordar a implementação da arquitetura MVC, com um exemplo prático, em PHP do clássico programa Hello World, para iniciantes.
Em artigo anterior, expliquei os conceitos básicos da arquitetura de projetos de software MVC (MODEL — VIEW — CONTROLLER). Agora, o objetivo é mesclar a teoria com a prática.

O que é a arquitetura MVC?

Embora possamos traduzir “model, view, controller” para “modelo, visão, controlador”, vou optar, neste post por mantê-los na forma original, para enriquecer um pouco o vocabulário do artigo.
A implementação original do MVC, na linguagem Smalltalk-80, com algumas variações, contém conceitos que se descrevem assim:

MODEL

Na sua forma mais simples, o MODEL armazena dados que serão acessados pelo VIEW e escritos pelo CONTROLLER.
É a parte mais complexa do sistema e contém toda a lógica específica da aplicação e é onde as entidades de domínio (domain entities), relativas aos conceitos do mundo real são armazenadas — tais como “um usuário” ou “uma ordem”).
É a parte da aplicação que recebe dados e os processa.
Além disto, lida com todos os acessos e armazenamento de dados — e não tem conhecimento dos CONTROLLERS ou VIEWS que fazem uso dele (o MODEL).

MODELS são aqueles componentes do sistema que realmente fazem o trabalho.

Por exemplo, no PHP, o MODEL pode representar um “usuário”, no sistema.
Ele pode tomar conta de todas as operações relacionadas aos usuários — gravando registros, recuperando-os, validando-os etc.
O que o MODEL NÃO É:

  • um simples ponto de acesso a dados;
  • uma classe chamada “model” que representa uma tabela dentro do banco de dados.

O VIEW

O view contém toda a lógica do display.
No PHP, esta é a parte da aplicação que gera o HTML.
Tem acesso direto ao MODEL e pode inquiri-lo para obter seus dados.
O VIEW pode criar callbacks para seu CONTROLLER — como um botão que, ao ser clicado, inicia uma ação).
No MVC, o VIEW interpela o MODEL para obter dados, diretamente.
Para evitar erros de interpretação, o VIEW NÃO É:

  • ausente de lógica;
  • receptor de dados do CONTROLLER.

O QUE É CALLBACK

Literalmente, callback quer dizer “chame de volta”.
Em computação, é uma porção de código executável, passado como parâmetro a outra porção de código.
Quando apropriado, a callback pode ser invocada e executada.

O CONTROLLER

O CONTROLLER recebe as entradas do usuário e atualiza o MODEL onde requerido.
Quando não houver interação humana direta, não há necessidade do CONTROLLER.
Em função disto, é importante que se diga, que não se trata de um mediador ou passagem entre qualquer uma das duas outras entidades.
O CONTROLLER acessa o MODEL, mas não contém qualquer lógica de display — tudo o que ele faz é responder às entradas do usuário.

CONTROLLERS são usados para enviar mensagens ao MODEL e prover uma interface entre este e os VIEWS associados a ele (p. ex., teclado, mouse etc.)
Cada VIEW deve ser pensado como sendo associado a um CONTROLLER cada qual com seu próprio MODEL. Mas este último, podendo ter muitos pares de VIEW/CONTROLLER.

Cada CONTROLLER está ligado a uma única instância de um VIEW e a uma única instância de um MODEL.
Coisas que o CONTROLLER NÃO É:

  • encarregado de instanciar o MODEL ou o VIEW — ele os enxerga, mas a flexibilidade é reduzida nas implementações que o forçam a selecionar qual VIEW ou MODEL está sendo usado;
  • uma passagem ou mediador entre o MODEL e o VIEW;
  • local onde os VIEWS são inicializados com base no estado de um MODEL. O CONTROLLER está ligado a uma única classe VIEW (embora possa ser atribuído a múltiplas instâncias) e responde a ações relacionadas.
    Uma lista de produtos constituiria uma única VIEW.

O fluxo do programa

O fluxo típico de um programa sob os padrões MVC, segue estes passos:

  • Inicialização do MODEL, do VIEW e do CONTROLLER.
  • O VIEW obtém dados do MODEL e é exibido ao usuário.
  • O usuário interage com o VIEW (clicando em algo, por exemplo), o que dispara uma ação do CONTROLLER.
  • O CONTROLLER atualiza o MODEL, de alguma forma.
  • O VIEW é renovado para exibir os dados atualizados do MODEL.

Hello World!

Já vimos um bom tanto de teoria.
Faz sentido ver como tudo isto se aplica à “vida real”, em uma pequena aplicação PHP.
Me acompanhe!

class Model {
     public $text;
     public function __construct() {
         $this->text = 'Hello world!';
     }        
} 

class View 
     private $model;
     private $controller;

     public function __construct(Controller $controller, Model $model) {
         $this->controller = $controller;
         $this->model = $model;
     }

     public function output() {
         return '<h1>' . $this->model->text .'</h1>';
     }
}
class Controller {
     private $model;

     public function __construct(Model $model) {
         $this->model = $model;
     }
}
// aqui inicia a triade
$model = new Model();
// eh importante que o CONTROLLER e o VIEW compartilhem o MODEL
$controller = new Controller($model);
$view = new View($controller, $model);
echo $view->output();

Os aplicativos “hello world!” não costumam ter interação com o usuário — pelo menos, este aqui, não tem.
Portanto, como ele só exibe dados, o CONTROLLER não faz nada aqui.

Interação do usuário

Se você ficou frustrado pelo fato de o CONTROLLER não ter sido relevante no exemplo anterior, vamos usar outra abordagem que preveja este tipo de interação.
Interação com o usuário é o primeiro problema da arquitetura MVC, na web — não há como criar uma callback pro CONTROLLER diretamente.
Além disto, toda a página tem que ser recarregada — o que ainda não é um grande problema, mas precisamos adicionar código que direcione a ação de volta ao CONTROLLER certo.
No nosso próximo exemplo, vamos adicionar ao código anterior algumas linhas que fazem com que a string “Hello world” seja seja substituída por “Texto Atualizado”, quando clicada.
Primeiro adicione um link pro VIEW. Você pode fazer isto adicionando uma callback ao CONTROLLER a partir do VIEW.
Em aplicações GUI, o CONTROLLER poderia ser apenas outro objeto na memória e a callback poderia ser uma simples chamada de função.
Na web, isto não é uma opção — uma requisição HTTP é a única maneira de acessar o CONTROLLER.

class View {
     private $model;
     private $controller;
     public function __construct(Controller $controller, Model $model) {
         $this->controller = $controller;
         $this->model = $model;
     }
     public function output() {
         return '<a href="mvc.php?action=textclicked">' . $this->model->text . '</a>';
     }
}

Na segunda requisição (callback), todos os componentes precisam ser reinicializados. Algum código precisa ser adicionado para direcionar a ação de volta ao CONTROLLER. Veja como:

$model = new Model();
//Eh importante que o CONTROLLER e o VIEW compartilhem o MODEL
$controller = new Controller($model);
$view = new View($controller, $model);
if (isset($_GET['action'])) $controller->{$_GET['action']}();
echo $view->output(); 

Tudo o que este código faz é chamar a ação do CONTROLLER — especificada por $_GET['action'], baseado na interação do usuário.
Enfim, uma ação do CONTROLLER, que lide com o evento, precisa ser adicionada ao código:

class Controller {
     private $model;
     public function __construct(Model $model) {
         $this->model = $model;
     }
     public function textClicked() {
         $this->model->text = 'Texto Atualizado';
     } 
}

Agora, quando a página for visitada, ela vai dizer “Hello World” e, quando o link for clicado, o texto muda para “Texto Atualizado”.
Pegue o código completo abaixo:

<?php
class Model {
	public $text;
	
	public function __construct() {
		$this->text = 'Hello world!';
	}		
}

class View {
	private $model;
	private $controller;
	
	public function __construct(Controller $controller, Model $model) {
		$this->controller = $controller;
		$this->model = $model;
	}
	
	public function output() {
		return '<a href="mvc.php?action=textclicked">' . $this->model->text . '</a>';
	}
	
}

class Controller {
	private $model;

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

	public function textClicked() {
		$this->model->text = 'Texto Atualizado';
	}
}


$model = new Model();
//It is important that the controller and the view share the model
$controller = new Controller($model);
$view = new View($controller, $model);
if (isset($_GET['action'])) $controller->{$_GET['action']}();
echo $view->output();
?>

Leia mais sobre o assunto

Outros textos sobre a arquitetura MVC, neste site.
Outros textos sobre programação PHP, neste site.

http://www.siliconinfo.com/open-source-web-application/mvc-development.html

https://coderwall.com/p/l-a79g
https://r.je/mvc-in-php.html
Wikipedia
Leia mais sobre as definições usadas neste texto:
http://pt.wikipedia.org/wiki/Callback

Os princípios do MVC para desenvolvedores PHP

Os conceitos por trás do MVC, remontam à década de 60 e influenciaram linguagens de programação orientadas a objetos, como o Smalltalk-80 e incontáveis projetos, como o Apple Macintosh.
Sigla para Model-View-Controller ou Modelo-Visão-Controlador, o MVC pode ser definido como uma arquitetura de software ou padrão de projetos (design patterns).
diagrama da arquitetura MVC
Se isto fizer alguém se sentir mais seguro e confiante, não estamos falando de conceitos que “surgiram ontem” aqui.
Quando me pediram para escrever sobre o MVC (Model-View-Controller), tal como Marc Plotz, tive a percepção de que há muito pouco escrito sobre o assunto, que se possa chamar de relevante (eu sei, isto é apenas uma opinião) — alguns termos carecem de uma definição mais aprofundada.
Mas, quem deseja se aprofundar mais sobre um determinado assunto, deve procurá-lo em livros, enquanto meios mais adequados e confortáveis para se explorar conceitos.
Neste artigo, vou procurar expor o que sei sobre MVC, da maneira mais simples possível e sob a ótica de um programador PHP – onde reside boa parte da minha experiência enquanto desenvolvedor.

Vantagens do MVC

Para ser objetivo:

  • robusto;
  • escalável;
  • enxuto e muito bem escrito.

Quando eu era adolescente, meu pai, doutor em matemática, me deu alguns conselhos sobre como programar melhor. Um deles dizia “seu código não deve ultrapassar o tamanho de uma tela”.
Pode parecer bobagem, mas seguindo este princípio, nos anos 90, antes de ter qualquer formação acadêmica, eu já aplicava alguns dos conceitos da boa programação de que vamos falar aqui.
Ao seguir este princípio, sou obrigado a pensar o meu código para ser enxuto e livre de redundâncias.

O que é o MVC

A arquitetura de software MODEL – VIEW – CONTROLLER, usada na engenharia de softwares tem como princípio fundamental a idéia de que a lógica de uma aplicação deve estar separada de sua apresentação — ou seja, o MVC é uma maneira melhor de separar a lógica de construção da sua aplicação do modo como ela é vista.
Sua fundamentação é separar a aplicação em 3 partes principais, conhecidas como o Modelo, a Visão e o Controlador.
Observe o diagrama:

  • As linhas contínuas representam as associações diretas
  • As linhas tracejadas representam as associações inferidas

Estas últimas, são associações visíveis pelo ponto de vista do usuário, mas que não representam necessariamente a realidade do projeto de software.

Design patterns - MVC - padrões de projeto de software
Clique, para ampliar.

Uma das formas de pensar o MVC é considerar as seguintes situações:

  • Um usuário interage com o view, clicando em um link ou enviando dados em um formulário.
  • O Controller manipula os dados fornecidos pelo usuário e os transfere ao Model.
  • O Model recebe a informação e atualiza seu estado — o que significa realizar um cálculo envolvendo os dados fornecidos, adicioná-los a um banco de dados, pra citar alguns exemplos.
  • O View verifica o estado do Model e responde — listando os dados, fornecendo o resultado de um cálculo etc.
  • O View aguarda uma nova interação vinda do usuário.

Em termos práticos, o MVC representa uma boa filosofia de projetos.
A ideia de separar a ĺógica do display não é nova — mas o MVC consegue apresentá-la de uma forma mais amigável.
A apresentação e o layout são mais simples — e, como consequência, seu aplicativo pode ter uma manutenção mais fácil.
O View fica entre os arquivos de view, a lógica dentro do modelo (template) e o Controller manipula tudo.

A lógica de negócios

O termo, em inglês, é Business Logic.
O conceito é simples: lógica de negócios é o processo de calcular os processos lógicos de uma aplicação.
Exemplo: no caso de um calendário, a lógica de negócios consistiria em calcular a data atual, em que dia da semana estamos, quantos dias já se passaram desde o início do ano ou do mês etc.
Não se deixe confundir por termos bonitinhos — em uma aplicação a lógica de negócios se refere ao processamento das informações — simplesmente.

São rotinas que realizam entradas de dados, consultas aos dados, geração de relatórios e mais especificamente todo o processamento que se realiza por trás da aplicação visível para o utilizador (Backoffice). (Wikipedia)

Modelos

O termo, em inglês (para facilitar sua busca, caso deseje pesquisar mais sobre o assunto) é templates.
É comum frameworks MVC usarem algum tipo de sistema de modelos, para enfatizar o princípio DRY (veja abaixo), tornando mais fácil reusar código já pronto.
Há frameworks que rodam sobre o Smarty ou seus próprios mecanismos de modelos – ou nenhum.
Especialistas avisam que alguns mecanismos de modelos (template engines) possuem sintaxe um tanto complicada — o trabalho de aprendizagem pode não valer a pena. Se informe antes de começar a aprender uma nova linguagem, que pode servir apenas para renderizar páginas.

DRY

A palavra dry, em inglês, que dizer “seco” ou “enxuto” — isto pode ajudar a memorizar.
No contexto de que estamos tratando, tem outro significado: Don’t Repeat Yourself — ou seja, não se repita ou não seja redundante.
A ideia é que você escreva código uma vez apenas e o reuse sempre que for necessário.

Na engenharia de software, o princípio DRY (não seja redundante) é usado para evitar repetição de informações e de trabalho.
“Cada peça de conhecimento deve ter uma única e não ambígua representação autoritativa dentro do sistema”. (Dave Thomas, 2003).
O princípio foi formulado pelos autores do livro “The pragmatic programmer“, Andy Hunt e Dave Thomas.
Sua aplicação inclui esquemas de bancos de dados, planos de testes, documentação etc.

A correta implementação deste princípio, implica que alterar um elemento dentro do sistema, não afeta outros elementos não-relacionados.

Programação por convenção

Este é um paradigma de projeto de software, que busca reduzir o número de decisões que os desenvolvedores precisam tomar — tornando o processo mais simples mas, nem por isso, menos flexível.
Assim, o programador só precisa especificar aspectos não convencionais da aplicação.
Por exemplo: havendo uma classe Vendas, dentro do modelo, a tabela correspondente, dentro do banco de dados, vai se chamar também “vendas”, por padrão.
Código “extra” relacionado a estes nomes, só vai precisar ser escrito, se alguém usar um nome diferente pra tabela.
Se pensar bem, é muito simples.
Leve em consideração um formulário:

  • ele tem elementos que sempre são requeridos;
  • estes elementos têm estados que, comumente, são os mesmos;
  • Um formulário, em meio ao código HTML, tem uma tag <form> que especifica uma ação a ser tomada, um método, um nome, uma id etc.
    Se você não precisa alterar nada, é mais fácil obter logo o nome do form, seu id, ação etc. direto da url.

Aplicar esta ideia a todos os elementos torna a construção deste tipo de aplicação muito fácil, rápida e simplificada.

Conclusão

O assunto não se esgota neste artigo — e pretendo retomá-lo em outros posts.
Tal como foi dito, até aqui, o MVC é uma maneira de começar a produzir de maneira limpa, escalável e robusta — e escrever código rápido, no menor espaço de tempo possível, com o mínimo de esforço.
Alguns frameworks MVC possuem apenas um ou dois destes recursos. O conselho é experimentar até encontrar um que te sirva.
Como sempre, sinta-se à vontade para comentar e compartilhar sua experiência comigo e com os outros leitores.

Leia mais

http://c2.com/cgi/wiki?BusinessLogicDefinition
http://pt.wikipedia.org/wiki/Padr%C3%A3o_de_projeto_de_software