|
Usuários |
|
134 Usuários Online
|
|
[Artigos]
Dicas para o desenvolvimento de um software – Parte 5 |
Publicado por rboaro : Quarta, Fevereiro 13, 2013 - 04:19 GMT-3 (551 leituras)
 comentar  Enviar para um amigo  Versão para impressão
|
Alguns 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. Dessa forma, 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 modificar ou adicionar uma característica (por exemplo, trocar a fonte de texto), basta alterar 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 itens 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 de mestre/detalhe). 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 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, a 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 usuário 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, e se 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.
Por enquanto é isso, pessoal! Obrigado mais uma vez pela visita!
Link Original do Artigo:
http://www.subrotina.com.br/dicas-para-o-desenvolvimento-de-um-software-parte-5-2/#more-1763
|
|
 Comentários | |
| | Comentários pertencem aos seus respectivos autores. Não somos responsáveis pelo seus conteúdos. |
|
|
Edição 112 |
|
|
50 Programas Fontes |
|
|
Produtos |
|
|
