Artigo Clube Delphi 61 - Programação Orientada por Objetos

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Artigo da Revista Clube Delphi Edição 61.

Esse artigo faz parte da revista Clube Delphi Edição 61. Clique aqui para ler todos os artigos desta edição

 

 

Atenção: por essa edição ser muito antiga não há arquivo pdf para download desta revista. os artigos disponíveis somente em doc.

Programação Orientada por Objetos

Parte IV - A Aplicação Completa

por Adail Muniz Retamal

 

Espero que a essa altura do campeonato você já tenha compreendido os fundamentos da análise e projeto orientados por objeto, além de tê-los experimentado na prática e acompanhado o nosso exemplo do estacionamento OOPark. O domínio do problema foi simplificado, mas ainda assim contém material suficiente para boas semanas de trabalho, dependendo do nível de detalhe exigido.

Como é impossível cobrir, em apenas um artigo, tudo o que foi necessário fazer para criar a aplicação completa, explicarei apenas os pontos essenciais. que ressaltam as vantagens de termos seguido o processo de MDD (Model-Driven Development- Desenvolvimento Dirigido pelo Modelo) oferecido pelo Delphi 2005 com o ECO II.Você poderá baixar a aplicação completa no endereço para download deste artigo.

 

O Modelo Final(?)

 

Como já mencionei anteriormente, um modelo de classes sofre muitas alterações, em algumas fases mais do que em outras. Por exemplo,com relação ao modelo da edição anterior, foram acrescentados alguns atributos e métodos: Tipo (derivado) na classe Pessoa; Status, Entrar e Sair (no lugar de Finalizar) na classe Estada; Tipo (derivado) na classe TipoVeiculo; QtdeVagas e CalcVagasOcupadas na classe Estacionamento; Usuário e Senha na classe Funcionário e PlanoAvulso (método estático) na classe TabelaPreco. O diagrama com as modificações pode ser visto na Figura 1.

Essas alterações foram exigidas depois que iniciei o desenvolvimento da aplicação. Como foram feitas? Muito fácil: alterei o modelo, acrescentando os atributos e métodos, e pedi para que o ECO fizesse a evolução do banco de dados! Para isso, abri a unit EcoPersistenceMapperProvider e cliquei no botão Evolve Schema.

Também podemos clicar com o botão esquerdo do mouse na superfície livre do designer e escolher a opção Evolve Schema. O wizard vai mostrar as alterações necessárias na tabela e ao clicar no botão Execute,o banco ficará sincronizado com o modelo! Mas isso só é necessário se foram acrescentados ou retirados
atributos persistentes do modelo.

 

Especificando o tipo de cachê

 

Nossa aplicação será em ASP.NET, portanto, múltiplas requisições podem ser fei-tas, o que exigirá a criação de  diversos EcoSpaces, isso é, espaços de objetos, para atender às requisições. Para melhorar a performance e garantir a integridade de cada um deles. O ECO oferece algumas opções de cache epooling Na unit Eco SpaceProvider existe uma linha que deve ser alterada, para o nosso caso:

 

    const

      MODE: EcoSpaceStrategyHandIer.SessionStateMode –

      EcoSpaceStrategyHand1ei-.SessionStateMode.A1ways;

 

O valor default para essa constante é IfDirty, o que não nos ajuda muito aqui. Outro valor possível seria Never, o que tornaria o EcoSpace inútil para nossa apli-cação, mas é utilizado em Web Serviços. Para maiores explicações sobre essa constante, digite mshelp://borland.bds/bds3dnetguidehtml/ECO_ECOAndASP.htm no Help do Delphi 2005.

 

Atributos derivados

 

Comentei que os atributos 77po,das classes Pessoa e TipoVeiculo, eram derivados. Bom, essa é uma das mil maravilhas do ECO. É algo equivalente a um campo cal-culado de um DataSet, mas muito melhor. No caso desse atributo, ao adicioná-lo à classe TipoVeiculo, altere a propriedade derived para True e coloque a expressão OCL para derivar o valor, que nesse caso é apenas a concatenação dos atributos Fabricante e Modelo,com um espaço entre eles. Portanto, a propriedade Derivation OCL ficou assim: Fabricante +"+ Modelo

 

 

  

Figura1.Diagrama de classes “final”

 

Observe também que o ECO já ajustou a propriedade persistence para transient, pois esse valor não será armazenado no banco. Para indicar que esse atributo é derivado, aparece uma barra'/' no lado esquerdo do nome dele no diagrama.

O atributo Tipo da classe Pessoa é para indicar que se trata de uma pessoa física (F) ou jurídica (J). A Derívation OCL ficou com o seguinte código:

 

     if self.oclIsTypeOf(PessoaJuridica) then 'J'.
    
else 'F' endif.

 

Legenda, por favor!

O if da OCL não serve para desviar fluxo de execução, como é comum nas linguagens de programação, mas para definir um valor de retorno. É similar a um If Then do Delphi, onde você passa como parâmetros uma condição booleana e dois valores. Se a condição for verdadeira, a função devolve o primeiro valor; se for falsa, devolve o segundo valor. Assim, nossa expressão OCL está testando se um objeto é da classe PessoaJuridica. Se for, o valor do atributo será a string 'J', caso contrário, será a string 'F'.

Por que um atributo derivado é melhor que um campo calculado? Porque a expressão de derivação só é avaliada quando os atributos que a compõe são alterados. Nesse caso, somente se houver alteração no Fabricante e/ou no Modelo é que o atributo Tipo será recalculado. Isso economiza bastante tempo de CPU, ao mesmo tempo garantindo que o atributo está sempre atualizado!

 

O "coração" da aplicação

 

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?