Blog da família Kerne. Fotos e informações.
22 Feb
Depois de alguns longos anos desenvolvendo em PHP tive conrtato com outras linguagens mais avançadas, e claro que no caminho conheci Java e .Net, porém para desenvolvimento Web ainda prefiro manter a utilização do PHP. Por muito trabalhei mais com orientação a objetos de forma mais detalhada e complexa através de Java e C# e isso me rendeu um conhecimento muito bom, que somente nos ultimos meses decidi começar a aplicar no PHP5.
Como trabalhava com muito código legado do PHP4, o que geralmente cria dependênicias até em relação a forma de trabalhar com variáveis de objetos, o PHP5 se mantinha em segunda instância, e com menor atenção, claro era preciso manter a compatibilidade. Foi então que uni o útil ao necessário e passei a desenvolver um novo framework totalmente em PHP5.
Mas aí vem a grande pergunta:
E os códigos que eu já tenho ? Não servirão mais ? Terei de reescrevê-los para manter o novo padrão ?
Em pouco tempo a minha dúvida foi respondida: Eu poderia utilizar os codigo antigos sim, mas apenas em um novo contexto.
Um exemplo de reaproveitamente de classes antigas e a simples sobrecarga através de uma instância “new objeto…” sem utilizar extends para a classe de trabalho do novo framework.
Apesar disso paracer obvio, quando se trabalha em um novo sistema e de forma a garantir que tudo esteja no mais perfeito padrão, fazer estas coisas é quase o mesmo do que “dar um tiro no próprio pé”.
Enfim dentre mortos e feridos salvaram-se quase todos, porém da salada mistas que eram os objetos antigos toda a parte de modelagem foi refeita, mas no novo mdelo será possível eximir o trabalho repetitivo de programas todas as pequenas excessões em um método que teoricamente poderia ser configurado para simplesmente trabalhar de forma diferente.
Enfim falta muito por faser, uma delas é a classe de manipulação de arquivos e sockets, que devido a sua versatilidade no modelo antigo acaba sendo quase que incompatível com o novo modelo, criando mais trabalho para usá-la do que para refazê-la.
O conceito de utilizar uma classe modelo não refere-se a copiar e colar uma classe para que sejam criados os objetos que montarão um cadastro por exemplo, mas sim, utilizar uma classe que quando extendida já contenha todas as configurações do objeto, tabela de banco de dados, formulários, validações e demais recursos que comumente utilizamos em rotinas de inclusão, alteração, exclusão, consulta e listagem.
Criei uma nova classe que chamei de Modelo e que contem todos os metodos para as principais funções de um sistema, ou seja, rotinas de inclusão, alteração, exclusão e listagem.
Para ter uma ideia da diferença de código em um cadastro contendo cinco campos, e que antes envolvia código HTML mais PHP ou deixava que o PHP gerasse o codigo HTML da página, esta nova classe de modelo permitiu a criação de um novo cadastro com todas as funções, formulários e botões apenas extendendo um objeto e configurando variáveis de campos, validação e visualização diretamente no método __construct().
Um cadastro que tinha duzentas a trezentas linhas passou a ter cinquenta! Isso que é diferença!
Claro que nem tudo são rosas, e como qualquer remédio este também tem um efeito colateral que com o tempo acaba sumindo. Calma… não é gripe :-D, basta dizer que agora é necessário pensar em como a classe de modelo trabalha, centralizando a inteligência da aplicação no modelo e não mais nas pontas onde isso era feito cadastro a cadastro. Outra desvantagem claro é a necessidade de reescrever algumas coisas, principalmente aquelas que se deixa para depois.
Aqui não é necessário falar muito, mas uma palavra resume todo: Tempo
Como tempo perdido não se recupera mais, esta é a vantagem principal e o que convense realmente a trabalhar de forma diferente.
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Nov | ||||||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 | ||||
Leave a reply