Dicas para o desenvolvimento de um software – Parte 5

Dicas para o desenvolvimento de um software - Parte 5Alguns leitores do blog me perguntaram sobre a continuação dos artigos sobre boas práticas de desenvolvimento de software. Na verdade, a intenção inicial era elaborar apenas quatro artigos sobre este assunto, mas logo notei que não seriam suficientes para abranger todas as dicas. Agradeço a todos os leitores que acompanharam e divulgaram essa série de artigos, me motivando a escrever os próximos.
Bom, essa é a quinta parte dessa série, abordando mais algumas práticas avançadas de desenvolvimento. Voilá!

 

Liberação de objetos da memória
Quando um aplicativo é iniciado, o sistema operacional se encarrega de alocar o espaço necessário na memória para a sua execução. Esse espaço é variável, e depende da quantidade de recursos que o aplicativo possui. Ao abrir uma tela do aplicativo, todos os campos de edição, botões e rótulos (labels) são criados na memória em runtime (tempo de execução), e permanessem nela até que sejam liberados. O problema surge quando o desenvolvedor esquece ou deixa de liberar esses objetos, acumulando recursos desnecessários na memória do computador. Por exemplo, supõe-se que instanciamos um objeto chamado “objCliente” da classe Cliente na inicialização de um formulário. Ao terminar de manipulá-lo, é necessário desalocá-lo da memória, já que ele não estará mais em uso. Caso não o fizer, o objeto permanecerá alocado na memória, muitas vezes sem o consenso do desenvolvedor. E mais: na próxima vez que o formulário for inicializado, uma nova instância do objeto será criada em outro endereço de memória. Então imagine: ao abrir o formulário 10 vezes, teríamos 10 objetos “objCliente” criados, ao passo de que somente um seria necessário. É por isso que alguns usuários reclamam que o aplicativo começa a ficar lento após um tempo de uso.
Cada linguagem de programação tem uma forma distinta de liberar objetos da memória. No Delphi, basta utilizar o comando FreeAndNil para essa finalidade:

var
  objeto: TClasse;
begin
  objeto := TClasse.Create;
  try
    // operações com o objeto
  finally
    FreeAndNil(objeto); // libera o objeto da memória
  end;
end;

 

Criação de componentes
Se o seu objetivo é reduzir código e padronizar a aplicação, criar componentes é uma ótima prática. Suponha que em determinado projeto decidimos modificar os campos de texto da seguinte forma:
– ao receber o foco, ele mudar de cor
– o campo não pode possuir conteúdo em branco
– ao sair do campo, se o valor for uma data, a aplicação deve validá-la

Para que essas funcionalidades tenham efeito, é necessário codificar cada campo de texto em toda a aplicação, não é? Oras, por quê não criar um componente com essas características? Dessa forma, utilizaríamos esse componente ao invés do campo de texto nativo da ferramenta e não precisaríamos codificar cada um deles, já que as funcionalidades estariam implícitas no componente criado. Além disso, se futuramente for necessário adicionar uma característica (por exemplo, trocar a fonte de texto), basta modificar o componente e a alteração será refletida em todos as instâncias do componente inseridas na aplicação.
Quando o desenvolvedor cria vários componentes personalizados, pode-ser dizer que ele está definindo um Framework de desenvolvimento.

 

Triggers e Stored Procedures
Implementar algumas regras de negócio no banco de dados pode trazer grandes vantagens para a aplicação, tanto no sentido de automação de operações como no desempenho. Na verdade, Triggers e Stored Procedures nunca deixaram de ser recursos essenciais no desenvolvimento de um software. Vou citar apenas uma das vantagens: em uma aplicação Cliente/Servidor ou Multicamadas, criar Triggers e Stored Procedures no banco de dados evita que várias chamadas sejam feitas ao servidor. Imagine que, ao excluir um pedido, seja necessário também excluir os itens do pedido (no sentido master/detail). Pela aplicação, faríamos duas solicitações ao banco de dados: uma para excluir os itens e outra pra excluir o pedido em questão, certo? Pois bem, se centralizarmos essa operação em uma Trigger no banco de dados, apenas uma solicitação será feita, ou seja, a Trigger se encarregará de excluir os itens antes de excluir o pedido, tornando-se um processo automatizado. Para aplicações de pequeno porte pode não surtir tanta diferença, mas em uma aplicação com vários usuários conectados simultaneamente a vantagem é notável, inclusive pelo motivo de redução de tráfego na rede.
Só para efeito de conhecimento, segue o exemplo da criação de uma Trigger no Firebird:

CREATE OR ALTER TRIGGER EXCLUIR_PEDIDO FOR PEDIDOS
ACTIVE BEFORE DELETE POSITION 0
AS
BEGIN
    DELETE FROM ITENSPEDIDO WHERE NUMPEDIDO = OLD.NUMERO;
END

 

Busca por fonema
Essa dica é bem interessante, embora a implementação dessa funcionalidade seja complexa. Antes de continuar, vale lembrar que um fonema, grosso modo, é a unidade de som produzida ao pronunciar uma determinada letra. Por exemplo, na língua portuguesa, as letras “i” e “y” possuem o mesmo som (mesmo fonema), e isso causa alguns problemas na busca de dados em um aplicativo. Sabe por quê?
Imagine que o sistema tenha vários clientes cadastrados, e três deles tenham o nome de Érica, Erica e Érika, respectivamente. Ao atender a ligação de uma dessas clientes, o usuário solicita o nome, ouve, e digita “Erica” (sem acento) no campo de dados para localizar o registro. Obviamente, apenas um dos nomes aparecerá na tela. Porém, a cliente que ligou é a Érika (com acento e com “k”)! Já que o resultado não apareceu na busca, o usuário irá informar que ela não está cadastrada no sistema. Bom, aí você já viu, rsrs.
Busca por fonema consiste em agrupar letras que tenham o mesmo som em uma mesma consulta. No exemplo acima, ao digitar “Erica”, os três registos seriam exibidos na tela, já que o acento e os fonemas de “c” e “k”, neste caso, produzem o mesmo som. Como disse anteriormente, a implementação é complexa e portanto leva muitos desenvolvedores a procurarem por soluções já codificadas.

 

Por enquanto é isso, pessoal!
Obrigado mais uma vez pela visita!


Confira também as outras partes dessa série de artigos:

Dicas para o desenvolvimento de um software – Parte 1
Dicas para o desenvolvimento de um software – Parte 2
Dicas para o desenvolvimento de um software – Parte 3
Dicas para o desenvolvimento de um software – Parte 4
Dicas para o desenvolvimento de um software – Parte 5
Dicas para o desenvolvimento de um software – Parte 6
Dicas para o desenvolvimento de um software – Parte 7
Dicas para o desenvolvimento de um software – Parte 8
Dicas para o desenvolvimento de um software – Parte 9
Dicas para o desenvolvimento de um software – Parte 10
Dicas para o desenvolvimento de um software – Parte 11


 

Compartilhe!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

2 comentários

  1. Boa noite.
    Hoje estou podendo acompanhar bastante.
    Esta sendo uma leitura útil e proveitosa. Espero que outros tirem proveito.
    É realmente excelente acompanhar os artigos.
    Sempre tomo o cuidado de só criar os forms e abrir tabelas que serão usadas, mas nunca libero elas. Isso já me causou problemas de falta de recursos da máquina. Resolvi, mas não usando esse método, pensava que uma vez criado o form ele não criaria uma nova instância.
    Criar componentes é uma necessidade muitas vezes, mas ainda é um ‘Sonho de consumo’.
    Apoio plenamente o uso de triggers e stored procedures, uso e abuso delas, apesar de como você já comentou, isso pode consumir muito recurso do servidor, a melhora na minha experiencia é excelente, diminui o tráfego de rede e melhora a velocidade de operação dos terminais, mas depende de como forem criados e utilizados (precisa de bom conhecimento de SQL, como comentado em outro artigo). Se mal construídos podem causar inconsistências e danos irreparáveis no BD.
    Quero aprender ou desenvolver essa funcionalidade de busca por fonema, não permito o uso de acentos e só uso maiúscula, mas nesse caso, nem ‘CONTAINING’ resolve. Boa ideia, vou tentar criar.

    Mais uma vez, obrigado pelos artigos.

    1. Olá, Gerson! Legal! Triggers e Stored Procedures ajudam bastante no desempenho e integridade dos dados, além de reduzir as linhas de código na aplicação.
      Bom, a funcionalidade de busca por fonema é bem interessante, embora não seja algo trivial de desenvolver. No projeto que trabalho atualmente, utilizamos uma DLL para essa finalidade, responsável por identificar as letras que possuem fonemas semelhantes e combiná-las na consulta. O grande benefício é a facilidade e abrangência dos dados que são consultados. Vale a pena explorar essa funcionalidade!

      Abraço!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Preencha o campo abaixo * Time limit is exhausted. Please reload CAPTCHA.