A Linguagem de Programação – Para quem nunca programou – As Diferenças

Acredito que você tenha dado uma voltinha da internet para pesquisar um pouquinho mais sobre os paradigmas de programação, e acredito que tenha caído em alguns fóruns que, acabou lhe confundindo mais ainda, ao invés de lhe ajudar.

É muito fácil, neste mar digitalizado, encontrar pessoas que ficam desmerecendo alguns paradigmas, as vezes até dou razão, mas em outras não, pois tudo é uma questão de escolha ou simplesmente uma questão imposição.

Diferentemente do que muitos acreditam o paradigma de programação estruturado não é totalmente bagunçado, pelo contrário, ele foi o antecessor direto do orientado a objetos, foi através do estruturado que os estudiosos conseguiram criar a arquitetura OOP nas linguagens de programação.

Quando se fala de uma programação onde tudo fica em um único arquivo, fala-se diretamente do Paradigma Imperativo e não do estruturado. É na programação imperativa que os desenvolvedores têm que utilizar o tão famoso comando GOTO para efetuar os saltos entre blocos de instruções, do qual, na prática, é definido um LABEL (etiqueta) no cabeçalho da instrução e no momento de executar o GOTO é informado o nome dessa etiqueta, fazendo com que a execução salte entre os blocos de instruções. As linguagens que utiliza deste paradigma são, por exemplo, Assembly, Fortran e Clipper.

Nas linguagens de Programação Imperativa, normalmente, todo o código é descrito em um único arquivo, tornando muito fácil o desenvolvedor criar códigos de difícil leitura, devido às quantidades de saltos (jumps) existentes em sua estrutura, tornando a depuração do código um tanto confuso para o desenvolvedor, diante de tantos saltos existentes na estrutura.

Quando falamos de programação estruturada, estamos falando de um paradigma bem mais evoluído, nesse não é permitida a utilização de comandos de saltos, tornando possível ao programador ter maior controle sobre o fluxo de execução do programa. Para isso, qualquer programa pode ser reduzido em três estruturas:

Estruturas de seqüência: Onde uma tarefa é executada uma após a outra, linearmente.
Estruturas de decisão: Onde, a partir de um teste lógico, determinado trecho de código é executado, ou não.
Estruturas de iteração: Onde, a partir de um teste lógico, determinado trecho de código é repetido por um número finito de vezes.

A programação estruturada orienta os programadores para a criação de estruturas simples em seus programas, usando sub-rotinas (funções, procedimentos ou módulos) com finalidades específicas e bem definidas. Foi a forma dominante na criação de software anterior à programação orientada a objetos.

Apesar de ter sido sucedida pela programação orientada por objetos, pode-se dizer que a programação estruturada ainda é muito influente, uma vez que grande parte das pessoas ainda aprende programação através dela. Para a resolução de problemas relativamente mais simples e diretos a programação estruturada é muito eficiente. Além disso, por exigir formas de pensar relativamente complexas, a programação orientada a objetos até hoje ainda não é bem compreendida ou usada pela maioria.

Há de se verificar inúmeras linguagens ainda extremamente relevantes nos dias atuais, entre elas Cobol, PHP, Perl e Python que ainda utilizam o paradigma estruturado (muito embora possuam suporte para a orientação à objetos)

A arquitetura do paradigma de programação orientada a objetos tem algumas características bem parecidas com a programação estruturada, enquanto a programação estruturada separa as sub-rotinas em procedimentos, funções ou módulos, a programação orientada a objetos separa em classes, que por sua vez se transformará, em modo de execução, em um objeto. Uma das características bem claras da orientação a objetos é que cada objeto deve ter um objetivo único e bem definido, ou seja, cada sub-rotina deve executar uma operação específica e objetiva, de forma geral, é isso que irá caracterizar este paradigma em uma arquitetura de código reutilizável.

Claro que quando falamos de orientação a objetos, não estamos falando apenas de reuso das classes, existem outras características que torna este paradigma ímpar, tais como a abstração acentuada, o encapsulamento, a herança, o poliformismo, entre outros conceitos que fazem parte desta arquitetura, apesar de ser trabalhosa e algumas vezes morosa a aplicação de todos estes recursos durante a criação de uma aplicação, após a criação de toda a estrutura básica, a manutenção e a evolução do software se torna muito mais prática e rápida do que em outros paradigmas, e é ai que surgem os famosos frameworks que auxiliam nestas estruturas básicas e naturais entre softwares distintos.

Em suma, podemos dizer que desenvolver em paradigma imperativo só é desejável se utilizado linguagem que só suporte este paradigma, como por exemplo, Assembly que muitas vezes é utilizado para o desenvolvimento de aplicações de baixo nível, tais como gerenciadores de hardware, aplicativos de BIOS e pequenos trechos de Kernel de Sistemas Operacionais. Para aplicações simples, de pequeno porte e que devem ser desenvolvidos em um tempo menor, utilizar a técnicas do paradigma estruturado não é pecado, desde que sejam criadas de forma correta as sub-rotinas, tornando-as especialistas, utilizar as linguagens que são mistas é uma boa opção, pois se acaso desejar migrar para POO o processo será bem tranqüilo. Agora se sua aplicação é de grande porte e a qualidade é o primeiro quesito e o tempo não é necessariamente o gargalo de seu projeto, desenvolver diretamente em POO é a melhor opção, claro, desde que sejam corretamente aplicadas as metodologias do mercado nesse paradigma.

Deixe uma resposta