Cadastros são flexíveis, podem ser gerados automaticamente, possuem look & feel, podem ser multiplataforma e mesmo conectar em variados banco de dados.
Pontes são fixas, nascem e morrem no mesmo lugar.
Cadastros podem ser validadados, existem alguns simples, outros complexos e outros muito mais complexos ainda. Não obstante, existem mestre-detalhe, mestre-detalhe hierárquicos, multi-modais e até multi-modais paralelos (progamadores, cuidem os deadlocks!).
Pontes se resumem a isso: peso, altura e largura suportadas.
Cadastros evoluem. A cada versão do software eles podem adicionar recursos, reconsiderar comportamentos, mudar a ordem de tabulação, valores default, teclas de atalho (páro aqui). Podem corrigir erros, aumentar a performance, mudar elementos de interface, mudar conteúdo de elementos e ter inúmeras funcionalidades dispersas em lindos botõezinhos pelos arredores da tela.
Pontes sempre funcionam da mesma maneira: entramos num lado e saimos no outro.
Cadastros podem ter cores variadas, efeitos, gradientes, figuras, sons multimídia e qualquer conteúdo embedded (Flash é "da hora, mano"!).
Pontes, não muito além, são cor de cimento. E só.
Cadastros são construídos por fervorosas sessões de brainstorming, reuniões confusas, entrevoltos em atas, diagramas interacionais, navegacionais, estruturais, etc. Dão ênfase aos argumentos dos analistas, ao choro de projetistas, à alegria dos usuários e à penitência de programadores. Não sem histórico, são vistos como exuberantes consumidores de tempo e dinheiro. E de fato, o são.
Pontes são construídas com base na necessidade: fixa ou não; coberta ou não. E só.
Eu poderia elencar mais uma série de diferenças que, grosso modo, dizem o seguinte: cadastros são graciosos e podem funcionar; pontes são inertes e funcionam. E porque será que uma ponte não gostaria de ser um cadastro?
Pontes não querem ser cadastros
Pontes não querem ser cadastros porque, enquanto os cadastros são balizados pelos adjetivos, as pontes são norteadas por objetivos. E termina aqui a história.
Uma ponte serve para passar de um lado para outro. E pronto. Um cadastro serve para ver e modificar dados. E pronto também, ora essas!
E porque as pontes funcionam e os cadastros simplesmente gostariam de funcionar? Não vou menosprezar nossa classe dizendo que as pontes funcionam porque são feitas por engenheiros; isso porque nós informatas, também conhecemos (ou deveríamos conhecer) Cálculo, Integrais e Derivadas (poderia até argumentar em nosso favor, dizendo que somos nós que construímos os programas que os engenheiros utilizam, mas isso não resolve problema, apenas aquece a discussão).
Pontes não querem ser cadastros por elas têm vantagens:
1. Usuários não reclamam de pontes; de cadastros, todos têm o que falar.
2. Pontes têm vida útil expressa; cadastros sempre podem ser ajustados.
3. Pontes que não funcionam são implodidas; os cadastros são alterados.
4. Pontes que não suportam o peso (ou largura ou altura) recebem uma placa de limite máximo; cadastros são alterados.
5. Pontes têm comprimento fixo; cadastros podem ser redimensionados (aleluia aos gerenciadores de layout e ao saco dos programadores!)
...e a lista segue...
Lógico. Lógico?
Mas que raio de coisa é essa que cada vez mais que eu comparo uma ponte com um cadastro, uma ponte fica parecendo uma coisa tão tosca e mesmo assim não posso dizer que um cadastro é melhor que uma ponte? Um cadastro faz maravilhas, uma ponte não faz nada de mais além de permitir que eu atravesse de um lado para o outro! Porque uma ponte não quer ser um cadastro? Talvez porque tenhamos um círculo vicioso...
O Fim, o Começo e o Ciclo
Pontes são seletas: o usuário deve ser assim, se não for eu não aceito (em suma, tome meia-volta e vai procurar outra ponte, seu ignóbil). Cadastros não submissos, não escolhem o usuário, simplesmente o suportam.
PAUSA PARA O CAFÉ
O Engenheiro valida uma ponte em prancheta, no Design, via cálculo. Ele não coloca um cargueiro sobre uma ponte para testar se ela aguenta o peso. Ele coloca sim, uma placa avisando a tonelagem máxima.O Informata especifica um conteúdo válido, mas não garante nada para o cadastro. Ele enche de validadores a sua tela e cruza os dedos esperando que a sequência de Murphi não ocorra enquanto ele for o responsável pelo bendito artefato.
Talvez por esse fim inglório é que os cadastros não funcionem (e consequentemente o porquê das pontes serem pontes mesmo). Não sei quem disse que tem que ser assim (na verdade eu sei, foi n-íade {cliente, vendedor, gerente disso, gerente daquilo, gerente daquilo outro, projetista, programador, analista...}, mas não posso dizer...), mas o fato é que é assim e pronto. Esse é o Fim.
E por esse fim tristonho é que, de tão flexível, robusto, etc. (olha os adjetivos aí gente!) é que um cadastro queria ser uma ponte, mas não vice-versa. Sendo ponte, ele seria simples e funcional (e óbvio, seu nome não seria Cadastro, seria Ponte). Por que não exibir cod_cliente ao invés de "Código do cliente" e pronto? Ah, claro! Fosse assim, não seria um cadastro, seria uma ponte!
Engenheiros (mesmo) são como advogados: é assim, o preço é esse e assino em baixo "se e somente se". Informatas são promíscuos, gananciosos... (vou procurar no Aurélio se Informática e termos correlatos não possuem algo como: Veja também > Adjetivo) garantem que tudo vai funcionar. Não poderiam ser humildes (esse adjetivo é bom, me lembra o Scott Ambler) e dizer: olha isso não pode ser assim (entenda-se, vou estudar mais) e eu não vou fazer (entenda-se, não sou ganancioso). Ou você acha que um engenheiro assinaria o projeto de uma ponte se não tivesse plena certeza (em outras palavras, matematicamente correto - e não simplesmente porque compilou...) do que ela faz e, principalmente, do que ela não faz? Isso é o Começo.
Finalmente, os engenheiros fazem pontes e aprendem com os projetos que não funcionam. Os informatas dizem que aprendem. E esse é o Ciclo.
Enfim, vou ser humilde (adjetivos, agrh!) e dizer que não sei a resposta porque os cadastros podem ser tão bonitos (e dá-lhe adjetivos!) e mesmo assim, as quase-feias e inflexíveis pontes não querem como eles.
0 comentários:
Postar um comentário