fbpx

(44) 99955-1057

Desmistificando a Programação – Parte III

0 Comments

Como foi dito no início da Parte I “programar nada mais é do que criar uma receita que, seguida, resolverá um problema”; a receita de um bolo é o exemplo clássico de uma rotina. Mas…, e a Programação Orientada a Objetos e Orientada a Eventos, como é que ficam nessa estória?!  Esses tipos de programação diferem um pouco da programação tradicional do tipo “receita de bolo”, pois, são os eventos sofridos pelos objetos que vão ditar o fluxo do programa.  Entretanto, por outro lado, pode ser afirmado que as rotinas que comandam as ações disparadas pelo usuário são procedurais, pois, apesar de ser um novo paradigma na programação, com o advento desses novos tipos de desenvolvimento no ambiente Windows© e sob a lógica de OO, as rotinas continuam sendo executadas do modo tradicional; isto é, as instruções são executadas do início para o fim, uma a uma. Isto porque, graças a Deus, o computador ainda não pode decidir por ele mesmo, a despeito das linguagens de Inteligência Artificial onde pesquisadores estão tentando tornar a CPU “inteligente” a ponto de tomar decisões; porém este é um assunto muito polêmico e discutível, e foge do escopo desta publicação. De qualquer forma, sempre é possível considerar um programa como sendo uma receita; não interessa o paradigma da linguagem: funcional, imperativa, orientada a eventos, orientada a objetos, etc, etc, e nem o seu nível de complexidade. De qualquer forma, o bom profissional de programação deve sempre desenvolver sistemas tais que minimizam a taxa de crescimento dos custos de software, pois enquanto os custos do hardware diminuem drasticamente, o mesmo não acontece com os custos dos programas. E para minorar esses custos os sistemas devem ser escritos de forma que possam ser reaproveitados (um dos princípios básicos da orientação a objetos) e modulares, além de serem extensíveis.

Mas, afinal de contas, programação é arte ou ciência?  Segundo os dicionários, programação significa: “elaboração de um programa para um computador”. Isto pode ser traduzido tecnicamente como: “programar é o ato de escrever um conjunto de ordens a serem executadas pelo computador para obter os resultados desejados”. É aí, então, que alguns dizem que programar depende de criatividade, e que seria um dom nato das pessoas; mas, os programas também necessitam ser eficientes, eficazes e robustos, pelas razões expostas anteriormente; e com as novas técnicas de desenvolvimento o programador, mesmo não sendo um artista nato, pode perfeitamente se tornar um grande profissional, pois, basta estudar muito e levar a sério o seu trabalho. Portanto, não existe esse papo de “super raça” em programação: aquele cara com óculos fundo de garrafa, que fica comendo pizza no porão da casa, que não tem namorada, que não penteia o cabelo. Esse estereótipo do “super-homem em programação” é “papo furado”, e não contribui em nada para o aprendizado; qualquer um pode ser Programador! Programador, mesmo; com P maiúsculo, e não apenas um leitor de manual da linguagem, à procura de um comando milagroso que consiga resolver o seu problema!

E finalmente: o Programador não pode se esquecer que, embora intelectualmente o programa seja dela, funcionalmente pertence ao Usuário. Então, quem pode julgar o programa é o Usuário, não o próprio programador, e nem aquele seu colega que se diz um “expert” em programação, só por que sabe a diferença entre font-end  e back-end! E de nada adianta o programa ser “da hora”, telas bonitas, cheio de efeitos especiais, muito rápido, todo “orientado a objeto”, naquele paradigma moderno, etc, etc, se não agradar o Usuário!  Um programa DEVE ser eficiente  e eficaz; entretanto, “fazer certo a coisa” (eficiência) não é o mesmo que “fazer a coisa certa” (eficácia). O que o Usuário verifica é a eficácia; se o programa o agrada e resolve o seu (dele) problema satisfatoriamente!

Portanto, se você se esqueceu de como usar o loop for, use o loop while; ou até mesmo o demonizado goto em vez de break para desviar o fluxo do programa. Não se envergonhe, e nem se reprima; o que tem que ser feito é resolver o problema DO USUÁRIO; e se isto puder ser feito, também, com eficiência, melhor ainda!


 

Mario Leite

Mário Leite é natural de Tombos (MG); estudou física durante dois anos no Instituto de Física da UFRJ; foi aluno de Iniciação Científica no Centro Brasileiro de Pesquisas Físicas (CBPF) e do CNPq, no Rio de Janeiro. É graduado e pós-graduado em engenharia pela Pontifícia Universidade Católica do Rio de Janeiro (PUC/RJ), onde foi professor auxiliar de ensino e pesquisa do Departamento de Ciências dos Materiais e Metalurgia. Tem especialização em Análise de Sistemas pelo Centro Universitário de Maringá (UniCesumar) e mestrado em Engenharia de Produção pela Universidade Federal de Santa Catarina (UFSC). Atualmente é professor-tutor de Técnicas de Programação e Ferramentas Computacionais na Universidade de Uberaba (UNIUBE), e autor de vários livros na área de programação.

Leave a Comment

Your email address will not be published.