Organizando classes de acesso ao banco de dados
E então o camarada decide programar orientado a objetos. Coloca todas as funções procedurais dentro de uma classe e acha o máximo. Comete o erro que eu chamo de Programação Orientada a Classes.
Assunto batido demais na altura do campeonato, mas com a quantidade de vezes que tenho visto isso acontecer, melhor tentar esclarecer algumas coisas.
(mais…)
Domain Specific Language externa com PHP
No post sobre Fluent Interface, testei seu uso para nomear métodos de forma clara e reutilizável nas consultas ao banco de dados.
Durante o desenvolvimento, percebi que o Eclipse completava o código conforme eu digitava, tornando o uso das classes extremamente simples:
No final, a linha de código soava como uma frase em português, exceto pelos caracteres adicionais para a sintaxe do PHP.
A idéia então foi exportar a lista de classes e métodos parar criar uma linguagem própria do sistema, de forma que o usuário final pudesse usar o autocomplete pela web para formar uma frase sem as distrações da sintaxe.
A interface ficou assim:
Se o player não abrir, clique aqui para ver o vídeo de demonstração da interface no Youtube.
O autocomplete ainda não acompanha o que o usuário digita sem escolher uma opção, mas já é possível selecionar as opções com o teclado ou mouse, preencher cada parâmetro pelo prompt do Javascript e ter os métodos listados de acordo com o contexto.
A biblioteca e uma aplicação de exemplo estão no projeto DslCatalog que criei no Google Code.
Abaixo seguem os detalhes de como implementar os catálogos em um banco de dados já existente em 3 passos rápidos. Rápidos mesmo, eu juro :)
O problema do contexto nas Fluent Interfaces
No post sobre Fluent Interface no PHP foi apresentada uma API que terminou assim:
$alunos->emOrdem()
->daCidade('Rio de Janeiro')
->matriculados()
->noCurso('Enfermagem');
foreach ($alunos as $aluno) {
echo $aluno->nome, '<br />';
}
O banco de dados estava estruturado com as tabelas de aluno, cidade, matrícula e curso. Como a relação do aluno com o curso é através da tabela de matrícula, foi necessário um catálogo extra para adicionar o critério sem quebrar o significado dos métodos.
(mais…)
Fluent Interface no PHP
Esses dias testei o uso de Fluent Interface para consulta de dados de forma semântica, tentando criar uma API legível e reutilizável que eventualmente servisse diretamente ao usuário.
Em uma API comum, uma classe de negócio tem diversos métodos que retornam uma lista de acordo com diferentes critérios. As consultas ficam próximas do seguinte:
$alunosDoRio = $alunos->getPorCidade('Rio de Janeiro');
/* … */
$lista = $alunos->getMatriculadosPorCursoCidade('Enfermagem', 'Rio de Janeiro');
/* … */
$emOrdem = $alunos->getMatriculadosPorCursoCidade('Enf…', 'Rio…', 'nome');
Em um sistema real são muitas as variações de critérios e a classe acaba crescendo em quantidade de código e dificuldade de uso e manutenção.
A proposta é eliminar a necessidade de um método para cada tipo de consulta. Os critérios apenas configuram a consulta que será realizada uma única vez quando necessário, possibilitando que esses critérios de busca funcionem independentemente.
As chamadas passam a ser realizadas assim:
$alunos->daCidade('Rio de Janeiro');
/* … */
$alunos->emOrdem()
->daCidade('Rio de Janeiro')
->matriculados()
->noCurso('Enfermagem');
Para conseguir esta API é preciso:
- encadear os métodos
- ter a possibilidade de configurar a query dinamicamente
- identificar quando a configuração termina para então realizar a consulta.
Ainda que existam outras técnicas para refatorar a primeira API, o uso de Fluent Interface é um avanço significativo até a implementação de Domain Specific Language para uso do usuário.
