Continuando a série sobre programação, vamos falar sobre modularização. Como dividir adequadamente um sistema? Qual a unidade ideal? Como quebrar funções? Como saber se um módulo está realmente bom? Esse artigo vai tentar responder algumas dessas questões e dar argumentos para pensarmos em muitas outras.
Antes de iniciarmos, porém, vamos fazer uma pequena pausa e considerar a necessidade de uma classificação.
Durante todo o decorrer deste artigo, estaremos considerando apenas técnicas de PE (Programação Estruturada). Não vou tratar aqui de critérios sobre modularização em POO por uma razão muito simples: teremos um artigo específico sobre POO, no qual essas técnicas serão especificamente comentadas.
A PE foi desenvolvida em meados dos anos 60 e durante muito tempo constituiu o melhor esforço na direção de uma atividade racional de desenvolvimento de software.
Durante todo o artigo vou pressupor que o leitor já tem algum conhecimento sobre PE, mas para quem desejar algumas referências sobre o assunto, aí vão elas:
Essa última referência é sobre Dijkstra, um dos "pais da matéria", além de ser um sujeito de excelente humor, com algumas frases impagáveis, entre as quais uma que diz que é impossível ensinar boa programação para quem começa aprendendo BASIC, pois o aprendizado dessa linguagem causava deformações mentais incuráveis... rsrsrs
[5] Comentário enviado por EdDeAlmeida em 06/05/2008 - 08:51h
stremer,
Tem de fazer ouvido de mercador para os caras que ficam pressionando para acelerar o trabalho. Se você foge dos esquemas bem definidos, acaba perdendo mais tempo no final.
[9] Comentário enviado por EdDeAlmeida em 07/05/2008 - 19:12h
O próximo artigo já está no forno... deve estar pronto para ser postado no início da semana que vem. Aí é só esperar a fila andar. Mais uma vez obrigado pelos comentários e pelo apoio de todos.
[11] Comentário enviado por joaomc em 09/05/2008 - 13:53h
O princípio da caixa preta é bonito na teoria, mas na prática a coisa não é bem assim. Muitas vezes você *precisa* saber o que há por trás daquele método que está chamando, para, por exemplo, saber os efeitos colaterais, se o método é thread-safe, etc.
Mas estou só sendo chato, o artigo ficou bom, parabéns :)
[12] Comentário enviado por EdDeAlmeida em 09/05/2008 - 19:43h
joaomc,
Concordo em parte. Mas saber se um método é thread-safe não viola necessariamente o princípio da caixa-preta. O que viola é escrever código que dependa do algoritmo usado por essa ou aquela função. Isso é uma violação grave, que cria dependência. A questão de ser ou não thread-safe é mais relacionada com o conhecimento dos requisitos do módulo. Vamos discutir isso quando formos falar em análise de requisitos.
rl27,
Obrigado pelo comentário. E tenho certeza que em breve estarei também lendo seus artigos aqui. Basta estudar e estar com a mente aberta para aprender.