O Programador Pragmático – parte 8

By Gabriel Rubens

E dando continuidade a leitura e o resumo do Programador Pragmático…

Tendo em mente que nunca criaremos um software perfeito, devemos nos precaver, por exemplo, quando temos que alterar uma classe que outro programador fez, nós testamos antes, verificando se não há bugs para só então modificar. Temos a tendência de achar que o que nós fizemos está certo, que o nosso modo é o melhor. Programadores pragmáticos não se previnem só com os outros, eles sabem que também erram e se previnem deles mesmo.

Contratos

No nosso cotidiano estamos acostumados fazer acordos dos mais variados tipos, onde as partes se comprometem a cumprir algo. Alguns usam apenas a palavra, mas isso dificilmente funcionária com a companhias de fornecimento de Água, Luz e etc… O modo mais comum de estabelecer responsabilidades são os contratos, que definem condições para o uso de determinado recurso.
Do mesmo modo que garantimos uma condição em nosso cotidiano podemos fazer com a programação. Definindo contratos que obriguem a todos a cumprirem as pré-condições e assim garantir as condições posteriores. Como foi dito no início do post, programadores pragmáticos são prevenidos, e a técnica de projeto por contrato pode ser uma ótima maneira de garantir pré-condições e pós-condições para o uso de um método.

Para saber mais leia sobre Design by Contract.

Programas mortos

Sempre que algo inesperado acontecer encerre o programa, como os altores escrevem “Programas mortos não mentes.”

Quando um erro ocorrer, o melhor que seu programa pode fazer é parar a execução, pois nada que vier após erro não terá garantia de integridade. Um programa parado não causa danos, mas um programa sendo executado com dados imprecisos podem causas erros, e esses erros podem ser difíceis de serem vistos.

Cuidado com as Exceções

Quando resolver lançar uma exceção, verifique se é mesmo necessário, pois há casos em que um verificação por método ou um if pode ser mais conveniente.

Usar exceções de forma indiscriminada pode quebrar o encapsulamento, já que o chamador pode fica mais acoplado ao método que é chamado.

Lidando com recursos

Como diria o Arnaldo César Coelho “a regra é clara”, crie, utilize e descarte. Há casos e casos, mas no geral é isso que devemos fazer: Abrir um transação, utilizar e fechar, assim evitamos surpresas. Outra coisa que devemos ter em mente é que quem aloca o recurso deve liberá-lo, em muitos casos isso significara que o método que aloca o recurso é quem deve liberá-lo.

Quando trabalhamos com linguagens que fornecem suporte a Orientação a Objetos esse trabalho pode ser ainda mais indolor, podemos encapsular os recursos em classes, e quando criamos instancias dessa classe o recurso é alocado, assim que o objeto sair do escopo o coletor de lixo entrará em cena, varrendo o objeto e consequentemente o recurso que ela encapsula.

Uma prática normalmente utilizada por programadores de C++ é a configurar as referências a Objetos já utilizados com null, e em linguagens como Java isso ajuda a diminuir a quantidade de referencias que apontam para Objeto, desse modo pode ser que ele seja qualificado para o coletor de lixo mais rápido.

Gabriel Rubens

Postagens Relacionadas:

• O Programador Pragmático – parte 7
• O Programador Pragmático – Capítulo 2 – segunda parte
• O Programador Pragmático – Resenha do prefácio
• O Programador Pragmático – Capítulo 2 – primeira parte
• O Programador Pragmático – parte 6
• O Programador Pragmático – Capítulo 1