|
|
 |
| Tecnologias :: Visual FoxPro |
 |
|
| |
|
Modelos de Arquitetura -
Como usá-los no VFP |
| por Victor Campos |
Victor Campos é presidente da Options Software Consulting, LLC e presidente do grupo de usuários do framework Mere Mortals . Ele vem trabalhando com Foxpro desde a versão 1.02 para DOS e continua usando o Foxpro desde então. Recentemente recebeu o título MCP através do exame VFP Desktop. Atualmente trabalha para MCSD e MCDBA. Qualquer questão a respeito deste artigo, projeto ou questões em geral podem ser encaminhadas para victor_fxp@yahoo.com. |
Em 1997 quando o UML tornoEm 1997 quando o UML tornou-se o "Blue Printing" padrão para desenvolvedores e os padrões tornaram-se mais aceitáveis, eu escolhi um livro chamado "Design Patterns: Elements of Reusable Object-Oriented Software" e o li de ponta a ponta. Quando terminei, não fazia idéia do que havia lido. Entretanto, sabia que eu deveria manter estas informações em minha cabeça para usá-las mais tarde.
Em 2001, tempos após ter me familiarizado com OOP e Padrões de Arquitetura, eu voltei ao livro "Design Patterns" para confirmar o sentido e o objetivo dos padrões. O grande desafio que tive foi a dificuldade de encontrar exemplos de como usar esses padrões em VFP. Obviamente existiam muitos exemplos em JAVA, SmallTalk and C++. Mas para desenvolvedores VFP interessados em implementá-los havia muito pouco.
Atualmente desenvolvedores VFP são obrigados a traduzir os exemplos de outras ferramentas. Mas, espere! Outras ferramentas? Sim, outras ferramentas! Acredite ou não, vários desenvolvedores trocaram ferramentas como C++, Java and SmallTalk pelo VFP por causa das suas habilidades em OOP e também trouxeram junto toda sua base de conhecimento em Padrões de Arquitetura.
O que são os Padrões de Arquitetura?
De acordo com Christopher Alexander, cada padrão descreve um problema que ocorre várias e várias vezes em nosso ambiente, e então descreve o núcleo da solução para este problema, assim como a maneira que você pode reaproveitar esta solução um milhão de vezes sem fazer a mesma coisa duas vezes."
Assim que li esta definição, tentei imaginar um modelo real e como se relacionam com OOP. Apenas para dar um exemplo, se nós falamos sobre uma "Pontes" em um mundo real, nós imaginamos uma plataforma construída de madeira, concreto ou aço. A ponte é desenhada para ajudar a transportar objetos numa interrupção em um determinado caminho. Isto é facil de imaginar porque nós todos crescemos sabendo a definição de uma ponte.
Entretanto, alguém teve que sugerir como seria o padrão de uma ponte. Agora quando nós conversamos e você menciona uma ponte, qualquer um sabe o que isto significa.
Por exemplo,suponha que você é proprietário de um lote de muitos quilometros. Você quer construir um lago pequeno em uma parte do seu terreno luxuoso. Para ter uma vista perfeita do lago, você deveria estar diretamente sobre a água. Quando você chamar a empresa responsável pela paisagem, você menciona que gostaria de ter a ponte construida sobre seu lago e gostaria de se encontrar com um engenheiro para discutir os detalhes.
Tendo elaborado o sentido da palavra "ponte" a pessoa do outro lado da linha saberia exatamente sobre o que você está falando. A pessoa não precisa necessariamente saber os detalhes da sua ponte porque com o histórico do modelo das pontes ele poderia determinar se sua empresa estaria capacitada a construir uma. Funcionaria da mesma maneira para Padrões de Arquitetura, quando você está discutindo sobre OOP.
Mais ou menos um ano atrás, eu estava falando com um desenvolvedor SmallTalk sobre um jogo chamado "Rock-Paper-Scissors". Sua intenção era testar as capacidades do VFP em OOP, projetando este jogo sem implementar declaração condicional. Durante o projeto nós discutimos diversos padrões. Um obstaculo foi que eu não conhecia o código em SmallTalk e ele não sabia como codificar em VFP mas nos entendiamos um ao outro porque usamos padrões.
Usando padrões em VFP
Acredite ou não, aqueles que desenvolvem em VFP estão provavelmente usando algum desses padrões que eu estou mencionando e nada sabem sobre eles!
Desde a liberação do original "Design Patterns: Elements of Reusable Object-Oriented Software" milhares de outros padrões apareceram. Eu não abordarei todos eles, mas eu irei falar sobre alguns básicos, que eu acho que são mais amplamente usados por desenvolvedores VFP.
Padrão Ponte (Bridge Pattern)
O Padrão Ponte destina-se "a desacoplar uma abstração [de uma implementação que pode ser subclassificada] de sua [atual] implementação, de forma que os dois [uma implementação da abstração e uma implementação de uma subclasse da abstração] pode variar independentemente" [Design Patterns - Elements of Reusable Software por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides].
Um bom exemplo que eu poderia pensar em VFP foi primeiramente definido no Framework Codebook para VFP 3. Usando o Objeto-Negócios como exemplo, você sempre quis o comportamento dos dados flexível. Dado que você pode abrir uma tabela livre, uma tabela pertencente a um DBC, uma view local, uma view remota ou um cursor somente-leitura podem existir diferenças entre seus comportamentos. Ok,Você pode manejar a maioria deles como se você estivesse manejando qualquer um. De qualquer forma, existem diferenças suficientes para justificar uma classe para cada tipo de dados. Hoje, o acesso aos dados vai além do cursor do FoxPro.
Neste caso, o Objeto-Negócios(BizObj) pode chamar vários diferentes tipos de classes de Objeto-Comportamento_de_dados (DataBehavior) e nunca ter que se preocupar em memorizar cada metodo para cada um dos objetos que ele pode instanciar. Olhando para os diagramas abaixo, você poderá ver onde o Objeto-Negócios tem referencia para o Objeto-Comportamento_de_dados através de uma das suas propriedades. Isto lhe permite criar uma subclasse do seu Objeto-Negócios e não da sua Objeto-Comportamento_de_dados. Você pode facilmente trocar o comportamento dos dados no nível da subclasse se desejar. Internamente o método Salvar(Save) do Objeto-Negócios pode ser executado por This.oObjeto-Comportamento_de_dados.Salvar(). Dependendo do Objeto-Comportamento_de_dados dado ao Objeto-Negócios, o código executado será ou:
*--- FoxPro's native code
TableUpdate()
ou
*--- SQL Passthru
SQLExec(nHandel, cSQLCmd)
Olhando para isto do ponto de vista do diagrama de sequencia, eis como pareceria:
Padrão Mediador(Mediator Pattern)
Padrão Mediador destina-se a "definir um objeto que encapsula como um grupo de objetos interagem. Mediador auxilia acoplamento fraco por manter objetos referenciando entre eles explicitamente, e permite a você variar a interação independentemente " [Design Patterns - Elements of Reusable Software por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides].
Eu poderia pegar este exemplo de modelo voltando para o Objeto-Negócios, mas eu acho que usarei um exemplo mais usual que é largamente usado pelos desenvolvedores atuais. Pegue como exemplo, o formulário do VFP - Quantas vezes você pensou no formulário como mediador? Tecnicamente ele pode ser mais que apenas o mediador, mas neste exemplo veremos como isso funciona.
Adicionando um PageFrame sobre um formulário, você pode certamente colocar vários objetos em um único formulário. Quanto mais páginas você adicionar ao PageFrame, mais controles você poderá adicionar ao seu formulário. Como muitos de vocês sabem, isto pode comprometer a performance do VFP tremendamente. Então, a solução é adicionar os controles nas páginas conforme necessário. Isto funciona muito bem até você começar a referenciar objetos de outras páginas que ainda não existem.
A solução é ter um método no formulário (Objeto Mediador) lendo os valores ou referências de um objeto que você precisa. Desta maneira, o método do formulário pode checar a existência do objeto e criá-lo se necessário.
Padrão Visitante(Visitor Pattern)
Padrão Visitante destina-se a "representar uma operação para ser executada sobre os elementos da estrutura de um objeto. Visitante permite que você defina uma nova operação sem trocar as classes dos elementos sobre qual opera.". [Design Patterns - Elements of Reusable Software por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides].
Se você sempre quis manter o código flexivel, este é o modelo para usar. Pegue como exemplo um documento do MS Word; para executar a correção ortográfica em qualquer palavra de um documento você criaria um objeto Varredor. O Varredor tem uma única tarefa - correr do ínicio do documento até o final e voltar ao ínicio. Entretanto, também pode conter um Visitante (corretor ortográfico). O Varredor percorre o documento, pedindo para o Visitante (corretor ortográfico) checar a ortografia de uma palavra.
Imagine como o Visitante pode se tornar potente. Suponha que você não queira mais continuar com a correção ortográfica, e ao invés disso você deseja procurar no dicionário palavras alternativas para as do texto . Ou talvez você deseje verificar a hífenização do seu documento. O varredor pode ter vários visitantes para terminar a função que foi solicitada.
Fábrica Abstrata(Abstract Factory)
O modelo Fábrica Abstrata destina-se a "Algumas vezes alguém quer construir uma instância de um conjunto de classes, decidindo entre as classes no momento em que for instanciado. Para evitar duplicar o ato de tomar decisões em todo lugar onde a instância é criada, precisamos de um mecanismo para criar instâncias das classes relacionadas sem necessariamente saber qual será instanciada.". [Design Patterns - Elements of Reusable Software por Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides].
De todos os padrões, este não é apenas o meu preferido como provavelmente o mais importante. No mundo dos frameworks, este é o modelo mais usado. Imagine ter dois conjuntos de classes e não saber qual deles será instanciado em tempo de execução. Isto é o que os desenvolvedores dos frameworks tem que tratar quando vão produzir um framework flexivel e robusto.
Um exemplo que posso extrair de minha cabeça é o objeto tratador de erros. Eu estou certo que você sempre teve que lidar com o fato que tratar erros em tempo de desenvolvimento não é o mesmo tratamento de tempo de execução. Aqui é onde o modelo Fábrica Abstrata entra.
No exemplo abaixo, você pode ver que a decisão apenas deve ser tomada uma vez para o comportamento persistir ao longo da aplicaçâo. o resto do tempo se comporta como se supõe.
Este é apenas um exemplo que demonstra o poder por trás da Fábrica Abstrata. Os exemplos são infinitos. Vamos tomar como exemplo um consultório médico: Voce pode criar uma aplicação com uma interface feita para ser usada majoritariamente por pediatras. Pegue a mesma aplicação e ela funcionará para clínica geral. Quando o formulário do paciente é instanciado ,você pode ter o formulário com as informações das crianças ou dos pacientes adultos, dependendo do médico que possui a aplicação.
Conclusão
Eu recomendo todos a dar uma olhada no "Design Patterns". O que foi falado neste artigo é a ponta do iceberg. Padrões de arquitetura são amplamente usados hoje em dia pela indústria da OOP. Mesmo falando com desenvolvedores de outras linguagens use esses padrões como uma forma de comunicação. Você pode não entender outras linguagens como JAVA, C++, C# or SmallTalk mas eu te garanto que aprendendo mais sobre padrões ,você poderá se comunicar com eles e trocar idéias sobre estratégias de desenvolvimento.
topo
|
|
|
formato Word - 378 Kb
