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.
Parte 3: 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.
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.