Programação (II) - Modularização

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.

[ Hits: 44.501 ]

Por: Edvaldo Silva de Almeida Júnior em 05/05/2008 | Blog: http://emeraldframework.net


Unidades básicas



As unidades básicas dos programas estruturados são as procedures e/ou functions. Uma procedure (ou function) executa um certo trecho de código, recebendo ou não valores do programa que a chamou e retornando ou não valores para esse programa.

Em algumas linguagens, como o PASCAL, existem procedures e functions como entidades diferentes. Em PASCAL uma procedure nunca retorna valores, enquanto uma function sempre o faz. Já em C tal distinção não existe explicitamente. Essa é, aliás, a tendência das linguagens mais novas.

Seja de que forma for, o que temos de entender inicialmente é que o nível de complexidade dos problemas que temos de resolver em programação tendem a ser muito altos. Com o aumento da complexidade das relações entre as entidades de negócios do mundo atual, isso é cada vez mais verdadeiro.

Assim, seria impossível escrever um trecho de código único que resolvesse um grande problema. A lógica envolvida seria muito complexa e nossas pobres mentes entrariam em parafuso (segundo alguns isso acontece no instante em que o sujeito decide ser programador... rsrsrs).

Temos então de aprender a "quebrar" grandes problemas em problemas menores, em partes cuja complexidade seja controlável.

Tal tarefa, porém, não pode ser feita de forma aleatória. Não basta sair quebrando, mas devemos também aproveitar para fazer essa quebra de forma útil e interessante, tendo em vista a performance do programa como um todo e alguns outros critérios.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. PE ou POO?
   3. Unidades básicas
   4. O princípio da caixa-preta
   5. Critério nº 01: Reusabilidade / FAN-IN
   6. Critério nº 02: Baixa complexidade / FAN-OUT
   7. Critério nº 03: Acoplamento
   8. Critério nº 04: Coesão
   9. Conclusão
Outros artigos deste autor

Como a Tecnologia pode ajudar a Democracia?

Instalando o Dynebolic sem instalador

Afinal, qual a melhor distribuição?

O "Linux Tinha Chapéu"

Programação (III) - Programação Orientada a Objetos (POO)

Leitura recomendada

Bioinformática - Instalação do Mr Bayes em ambiente paralelo

Aplicativos do Linux em "Desktop"

Como criar um box para o Vagrant

Arapuca - Expandindo as funcionalidades do FreeRADIUS

Como contribuir com a atualização de pacotes no Void Linux

  
Comentários
[1] Comentário enviado por bjaraujo em 05/05/2008 - 14:04h

parabéns, cara; acho que ainda tenho sequelas pela exposição ao BASIC. ahuahuaha

[2] Comentário enviado por stremer em 05/05/2008 - 19:03h

excelente. O dificil é mesmo conhecendo tudo isto conseguir implementar nos prazos malucos que os gerentes de TI e pessoal do marketing impõe (rs)

[3] Comentário enviado por rafastv em 05/05/2008 - 19:17h

De leitura agradável e rápida, parabéns!

[4] Comentário enviado por kabalido em 05/05/2008 - 21:53h

Parabéns cara! Continue assim, os seus artigos são muito bons.
Valeu!!

[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.

Abraço e oobrigado a todos!

[6] Comentário enviado por douglascrp em 06/05/2008 - 09:04h

excelente artigo... assim como o primeiro artigo, depois que se começa a ler, é impossível parar até terminar...

parabéns

[7] Comentário enviado por leowalker em 06/05/2008 - 15:18h

muito bom, estou esperando o proximo para dar continuidade...

Abraço e parabens.

[8] Comentário enviado por vodooo em 07/05/2008 - 09:57h

Cara, parabéns, realmente de leitura muito agradável!

Abraços

[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.

[10] Comentário enviado por rl27 em 09/05/2008 - 11:14h

Parabéns pela série de artigos. Muito boa mesmo!

Estou ansioso pela continuação. Com certeza ainda darei minhas contribuições à comunidade.

Valeu!

[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.


Ed

[13] Comentário enviado por marcio_paim em 14/02/2012 - 22:14h

Excelente série de artigos.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts