Neste post continuaremos a refatorar aquela aplicação – meio mal feita – apresentada na Parte 1.

Terminamos o post anterior colocando as “coisas em seus devidos lugares” correto?

No início tínhamos  um método gigante, cheio de responsabilidades e o dividimos em alguns outros métodos utilizando a refatoração Extrair Método e depois organizamos os métodos nas classes corretas utilizando a refatoração Mover Método

Vamos continuar analisando nossa aplicação para melhorarmos ainda mais o seu design.

Problema: ORA-04091: Table name is mutating, trigger/function may not see it.

Causa: Uma trigger/function está tentando acessar, em sua execução, uma tabela que está sendo acessada pelo comando que gerou a trigger.

Solução: Logo abaixo.

Exemplo: Ao cadastrar um registro na tabela Pessoa, disparo uma trigger que insere um registro padrão na tabela de Endereço para essa Pessoa, em seguida a trigger atualiza o registro da Pessoa que está sendo cadastrada, atribuindo o ID do Endereço recém-criado como uma FK para essa Pessoa.

Vamos criar duas tabelas, Pessoa e Endereco, contendo a seguinte estrutura:

Objetivo:

Introduzir o conceito de View States de maneira simples, possibilitando a sua utilização no dia-a-dia.

O que é:

View States são uma maneira simplificada de implementar aplicações que mudam suas interfaces e conteúdos de acordo com uma atividade que o usuário esteja desempenhando.
De forma simples, uma view state define uma visão particular de um componente. Por exemplo uma foto de um produto em um site de venda: No estado base o componente mostra a foto e uma breve descrição, já em um outro estado exibe botões para maiores informações e adicionar ao carrinho de compras.

Tópicos

• O que é;
• Strategy;
• Composite;
• Factory Method;
• Abstract Factory;
• Adapter;
• Como Aplicar;

Objetivo:

Mostrar através de exemplos como funciona e como utilizar determinados design patterns.

O que é:

Desenvolver com qualidade um sistema flexível e de fácil manutenção em pouco tempo é o desafio hoje proposto para todos os programadores, independente de empresa ou tecnologia, e para atingir este objetivo, diversas ferramentas e metodologias foram desenvolvidas para facilitar o desenvolvimento,  porém nenhuma delas é tão difundida e estudada quanto os “Design patterns” ou simplesmente “Padrões de projeto”;

Padrões de projetos são soluções estudadas e validadas, para problemas que geralmente encontramos durante o processo de programação, e são divididas em três grandes grupos: Criação, Estruturais e Comportamentais; Apesar de ter uma ampla divulgação, existem programadores ainda possuem muitas dúvidas sobre qual, quando, onde e como utilizar um padrão de projeto; E essas dúvidas surgem geralmente por falta de conhecimento do comportamento dos padrões.

As notícias anunciadas pela Adobe nas últimas semanas têm tirado o sono de muita gente que trabalha com a tecnologia Flash. E não é por menos, pois apesar de o fim do Flash Player para browsers de dispositivos móveis já até ser esperado, a notícia de que a SDK do Flex seria doada para uma fundação não agradou muito a comunidade. Alguns desenvolvedores têm esperança de um futuro ainda brilhante para o Flex, mas outros já estão declarando a sua morte e se preparam para utilizar outras tecnologias, achando que todo o tempo e investimento em Flash foram por água abaixo.

O que é Refatoração?

Refatoração (do inglês, Refactoring) é o processo de alterar o código fonte de uma maneira que não altere seu comportamento externo e ainda melhore a sua estrutura interna. É uma técnica disciplinada de limpar e organizar o código, e por consequência minimizar a chance de introduzir novos bugs – Martin Fowler.

Durante o desenvolvimento (e manutenção) do software, é comum que algumas pessoas precisem alterar e/ou adicionar novas funcionalidades em códigos que foram escritos por outras pessoas. Isso pode fazer com que o sistema acabe perdendo a integridade pouco a pouco, pois as pessoas geralmente não programam da mesma maneira, e mesmo que o software tenha sido muito bem projetado e documentado, alguns desenvolvedores podem cometer alguns deslizes, como repetir código e colocar métodos em classes inapropriadas. Isso faz com que o código fonte acabe se distanciando um pouco do que foi planejado.

Pensando em evitar que isto ocorra, é interessante refatorar o código para melhorar a sua conformidade com padrões e a legibilidade, o que facilita o seu entendimento sem alterar o seu comportamento externo. Isto é, quando um código refatorado é executado, ele continua tendo o mesmo resultado final.

A refatoração visa apenas a melhoria interna do código fonte.

Flex Events.

Tópicos

• O que é:
• Utilizando em classes .as
• Utilizando em componentes mxml:
• evt.preventDefault();
• evt.stopPropagation();
• evt.stopImmediatePropagation();
• Como Aplicar:

Objetivo:
Explicar de forma simples e prática, o que são eventos na plataforma flex, e como utilizá-los

O que é:

Um Evento é algo que acontece ‘Eventualmente’,  poderiamos utilizar logicamente um evento desta forma: Quando começar a chover quero que a capota do meu Porsche conversível se feche,  também que o vidro subisse automaticamente e o limpador de pára-brisas  começasse a funcionar. Veja que utilizando apenas  um evento conseguimos vincular várias ‘funções’.

Um Evento possui três fases, onde pode ser ouvido e tratado, são elas:

Capturing Phase

Targeting Phase

Bubbing Phase

Capturing Phase – Nesta fase, o evento parte da extremidade da aplicação, e vem se propagando na hierarquia até que atinja o objeto que sofreu o evento, nesta fase o Current Target vai se alterando conforme o nível.

Targeting Phase – Aqui o evento está exatamente sobre o componente que o causou.

Bubbing Phase  - Esta fase é o reverso da Capturing Phase, pois o evento vem subindo do nível que causou o evento até o topo da aplicação, ou seja FlexGlobals.topLevelApplication.

Neste link está um exemplo legal de como perceber estas fases:

http://www.learningactionscript3.com/2007/11/10/event-phases-in-action/

Uma das grandes vantagens de se utilizar Eventos no Flex, é que não precisamos referenciar funções dentro dos componentes, deixando-os totalmente desacoplados e conseqüentemente mais leve ao executar a aplicação, pois desta forma um objeto que não está sendo usado pode ser descartado pelo Garbage Collection, o que não acontece quando vinculamos uma função dentro do componente, pois este passa a guardar um valor que ainda está sendo usado em outro contexto.

SCRUM acima de tudo

Atualmente o que mais se ouve falar nas empresas de Software
é sobre os processos SCRUM. Praticamente essa palavra está ganhando uma força
fora do normal, onde muitas discussões são facilmente finalizadas ou
justificadas apenas dizendo: “Isso faz parte do processo SCRUM”, ou ainda “O
processo SCRUM determina que isso seja feito desta maneira”.

Isso pode trazer consequências desastrosas no setor de
desenvolvimento de uma empresa.

Antes de mais nada, precisamos lembrar que SCRUM é um processo
interativo incremental para o desenvolvimento de produtos e gerenciamento de
projetos. É mais um framework que uma metodologia, mais atitude do que
processo.

Empresas de alta performance no desenvolvimento de software
precisam gerenciar de maneira eficaz seus profissionais, que por sua vez, estão
se desenvolvendo cada vez mais, não só no quesito técnico mas também
comportamental, aprendendo e criando um senso crítico de qual é a melhor
maneira de desenvolver software.

Com isso as empresas resolveram implantar o SCRUM que
oferecem boas práticas para o crescimento e amadurecimento dos times de
desenvolvimento, suporte, implantação, etc. Ao se ouvir falar em SCRUM tudo
parece ser muito fácil, simples, oportuno e com isso acaba por não dar a devida
importância ao procedimentos a serem tomados na implantação destes processos.