Programação Estruturada versus Programação Orientada a Objetos


A Wikipédia define a programação imperativa como um paradigma que descreve a computação como ações (comandos) e estados (variáveis) de um programa. O nome do paradigma, Imperativo, está ligado ao tempo verbal imperativo, onde o programador diz ao computador: faça isso, depois isso, depois aquilo... Este paradigma de programação se destaca pela simplicidade, uma vez que todo ser humano, ao se programar, o faz imperativamente, baseado na ideia de ações e estados, quase como um programa de computador.

Programação Estruturada
Em linguagens puramente imperativas, como Assembly, é muito fácil o programador criar códigos de difícil leitura, pois esse tipo de linguagem possui o que se chama de saltos (jumps) em sua estrutura. Estes saltos funcionam da seguinte forma: o programador define uma marcação (label) no código e depois, a partir de qualquer parte do programa, ele pode executar um desvio de fluxo de execução (salto) para aquela marcação. Pode ser que à primeira vista isso não tenha problema, contudo, na depuração do código, o programador fica em apuros com tantas marcações e saltos, pois isso dificulta o entendimento do fluxo de execução do programa.

Neste contexto, surge a programação estruturada, como uma forma de possibilitar que o programador tenha maior controle sobre sobre o fluxo de execução do programa. Para isso, segundo a Wikipédia, qualquer programa pode ser reduzido a 3 estruturas:
  1. Estruturas de sequência: Onde uma tarefa é executada após a outra, linearmente.
  2. Estruturas de decisão: Onde, a partir de um teste lógico, determinado trecho de código é excutado, ou não.
  3. 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.

No trecho de código Python a seguir, podemos reparar o emprego das três estruturas citadas. Nas linhas 1, 2 e 3 temos um exemplo de uma estrutura de sequência. Cada linha é executada após a anterior, começando da primeira. Entre as linhas 5 e 9, temos uma estrutura de decisão, exemplificada pelo comando if. Na linha 5 este comando executa um teste lógico. Caso o valor seja verdadeiro, as linhas 6 e 7 serão executadas. Caso contrário, o fluxo se desvia para a linha 8, que executará a linha 9. Nas linhas 6 e 7, temos uma estrutura de iteração. Na linha 6 está declarada a estrutura, que regula quantas vezes a linha 7 será executada.

print "Tabuada!"
a = int(raw_input("Entre com a tabuada que deseja [0-9]: "))
print  # Apenas para deixar uma linha em branco.

if 0 <= a <= 9:
    for i in range(10):
        print "%d x %d = %.2d" % (a, i, a * i)
else:
    print "Entre ZERO e NOVE!"
Listagem 1. Exemplo de código estruturado.

Vantagens
  • Provê um melhor controle sobre o fluxo de execução do código, quando comparada com a programação imperativa.
  • É fácil de se entender, sendo amplamente usada em cursos introdutórios de programação.

Desvantagens
  • Ainda se foca em como a tarefa deve ser feita e não em o que deve ser feito.
  • Tende a gerar códigos confusos, onde tratamento dos dados são misturados com o comportamento do programa.

Programação Orientada a Objetos
Uma das desvantagens da programação estruturada, como foi citado, é a tendência em gerar códigos onde tratamentos de dados são misturados com o comportamento do programa. Além disso, caso o programador quisesse criar um programa semelhante a um que já tivesse feito, era complicado pegar determinadas partes deste programa já pronto e trazer para o novo projeto, uma vez que eram necessárias, na maior parte das vezes, realizar mudanças substanciais no código.

Neste cenário surgiu a Programação Orientada a Objetos (POO – lê-se Pê-Ó-Ó). Ela foi criada para tentar simular o mundo real dentro do computador e para isso utiliza objetos. Desta forma, fica a cargo do programador modelar objetos e a interação entre eles. Essa modelagem leva em consideração alguns conceitos, dentre os principais, pode-se citar:
  • Classe: É o molde para criar objetos. Possui todas as especificações de um grupo deles. Ex.: Os objetos Eddie Vedder e Kurt Cobain, apesar de serem diferentes, derivam da mesma classe Pessoa
  • Atributos: Definem características de objetos, e.g., a classe Pessoa tem os Atributos Nome, Endereço, Telefone e Sexo.
  • Métodos: Definem o comportamento dos objetos, tendo seus nomes normalmente definidos por verbos. Para a classe Pessoa, por exemplo, podem haver os métodos Comprar, Vender e Alugar.
  • Abstração: É a habilidade de se concentrar nos principais aspectos de um grupo de objetos, em vez de se preocupar com as suas especificações. Ex.: Para a classe Pessoa são definidas as principais características comuns à maioria das pessoas, sem que haja preocupação especial com objetos muito específicos e, por conseguinte, pouco comuns (e.g., pessoas com dedos a mais ou a menos).
  • Encapsulamento: É a habilidade de esconder de outros objetos, as características intrínsecas de um dado objeto. Toda a comunicação inter objetos deve ser realizada via métodos. Um objeto não deve ser capaz de acessar, e tampouco alterar, atributos de outro objeto diretamente.
  • Associação: É a habilidade pela qual um objeto utiliza recursos de outro. Por exemplo: Corda é parte de um Violão.
  • Herança: É a capacidade de criar subclasses a partir de uma superclasse. Essas subclasses herdam, então, todas as características da superclasse. É normalmente definida como uma associação do tipo "é um", e.g., Cliente é uma Pessoa.
  • Polimorfismo: É o princípio pelo qual uma subclasse sobrescreve um comportamento (método) herdado de sua superclasse. Por exemplo, a classe Pessoa implementa o método Comprar, mas a classe Cliente, derivada da classe Pessoa, precisa de algo mais específico, envolvendo mais dados. Então a classe Cliente sobrescreve o método Comprar, tornando-o mais específico.

Estes são alguns conceitos da POO. Sugiro a leitura da página da Sun, na seção de leituras recomendadas, no rodapé deste texto, para mais informações sobre eles. No código abaixo temos implementadas algumas das características da POO, que foram citadas. É um código bastante simples, sem aplicação direta em problemas reais. Contudo, serve como exemplo de implementação de Classes, Atributos, Herança, Polimorfismo e instanciação de objetos.

# -*- coding: utf8 -*-

class Pessoa:
    def __init__(self, nome_, endereco_, telefone_, sexo_):
        self.__nome = nome_
        self.__endereco = endereco_
        self.__telefone = telefone_
        self.__sexo = sexo_
    
    def comprar(self):
        pass
    
    def vender(self):
        pass
    
    def alugar(self):
        pass

class Cliente(Pessoa):
    def __init__(self, nome_, endereco_, telefone_, sexo_):
        Pessoa.__init__(self, nome_, endereco_, telefone_, sexo_)
    
    def comprar(self, nome):
        print "Sobrecarregando o método comprar()"

#
# Main
# 

eddie = Pessoa("Eddie Vedder", "Seatle", "555-6332", "M")
kurt = Pessoa("Kurt Cobain", "Paradise", "555-disk_god", "M")
Listagem 2. Exemplo de código Orientado a Objetos.

Vantagens
  • Provê uma melhor organização do código.
  • Contribui para o reaproveitamento de código.

Desvantagens
  • Não possui o mesmo desempenho de códigos estruturados similares.
  • Seus conceitos são de difícil compreensão se comparados aos conceitos da Programação estruturada.

Conclusão
Foram apresentados os principais conceitos da Programação Estruturada e da Orientada a Objetos. Ambos paradigmas são herdeiros do Paradigma Imperativo, mas proveem novas funções, criando novas abordagens para o mesmo.

O Paradigma Estruturado é o que domina atualmente cursos introdutórios de programação, mas é o Paradigma Orientado a Objetos que é a estrela da festa em sistemas maiores. Dificilmente encontra-se um grande projeto de software sem a utilização de POO, sendo este, requisito fundamental para profissionais da área de programação. Em suma, cada paradigma tem suas vantagens e desvantagens, sendo indicados para fins específicos. Enquanto que no Estruturado temos simplicidade de termos e facilidade de aprendizagem, que o levam para as primeiras aulas de programação, no Orientado a Objetos, temos mais recursos e melhores organização e reaproveitamento de código, colocando em um novo nível, os paradigmas Imperativo e Estruturado, dos quais ele herda características.




Leituras Recomendadas
  • UNICAMP – Página da Faculdade de Engenharia Elétrica da UNICAMP sobre Programação Estruturada.
  • Guia do Hardware – Programação Orientada a Objetos.
  • Sun – Object-Oriented Programming Concepts

Clube de Revista
  • Anterior – Programação Imperativa versus Programação Declarativa
  • Próximo – Paradigma Funcional

32 comentários:

maurim disse...

Fala brother!!!

Kra eu discordo que as linguagens estruturadas ainda sejam o foco nos cursos introdutórios de programação. Quando vi programação pela primeira vez, acredito assim como vc, foi com Pascal e para mim o mais difícil de se entender é o conceito de tipos.

Então o fato da linguagem se estruturado ou OO, o importante ao meu ver para o ensino é ela ser fortemente tipada, assim como o Pascal.

Existem linguagens OO que se enquadram nesse perfil e essas deveriam ser abordadas desde o início para juntar a parte de aprendizado com o parte profissional da coisa.

Ao meu ver ao invés de Assembly você deveria ter citado uma outra linguagem, por exemplo, o Pascal. Porque acontece que o código Assembly já é confuso por natureza. Agora em Pascal o GOTO podem matar o entendimento do código.

So estendendo a definição de polimorfismo existe a possilibidade de ter-se metodos com o mesmo nome dentro da mesma classe, somente com assinaturas diferentes. Porque na explicação parece abranger só no conceito de herança.

Resumindo, eu defendo a OO nos cursos introdutórios. Qual a sua opinião em relação a isso?

[]s

j disse...

Salve!

Pascal é uma linguagem estruturada [1]. Veja os conceitos de Programação Estruturada. Eu citei Assembly por ser uma linguagem imperativa por natureza.

Talvez possa ter parecido no texto, mas, como você mesmo citou, pode haver polimorfismo dentro de uma mesma classe.

Eu creio que começar programação com OO pode ser meio confuso para iniciantes. A evolução, pelo que já li até hoje, se deu assim: Imperativa -> Estruturada -> Orientada a Objetos. Como foi citado, nas linguagens puramente imperativas, como Assembly, há muita confusão no código, por não haver os conceitos na programação estruturada. Já na programação estruturada temos uma melhor organização do código e conceitos que usamos para construir algoritmos, mesmo em liguagens OO. Creio que a ideia de cursos introdutórios de programação é ensinar ao aluno como criar algoritmos, usando as 3 estruturas básicas da programação estruturada. Quando o aluno aprende isso, aí sim eu defendo o uso de OO. Seria algo como um período para aprender a programar e desenvolver o básico (incluindo conceitos de vetores e ponteiros), outro para listas, filas, pilhas, recursão, ordenação e acesso à memória secundária e aí, já começar com os conceitos de OO.

Abraço!

[1] http://pt.wikipedia.org/wiki/Pascal_(linguagem_de_programa%C3%A7%C3%A3o)

Fabricio Kelmer disse...

Grande zezim!

Realmente concordo com a sua sitação, acho que esta ordem é esta para o aprendizado, pois se aprendessemos por exemplo ao contrário, o início seria árduo. Imagina comerçar aprender a programar sem nunca ter visto programação na vida e já comerçar com OO? Acho meio ilógico! Acho que para comerçar aprender OO, temos que aprender alguns outros conceitos antes (algumas pessoas pulam esta parte, mas é importante), conceitos estes nem sempre ligados a programação direta, se é que me entende (ex.: aquela máteria que o prof. Elio Lovisi lecionava, Engenharia de Software).
OO como inicial a programação é a mesma coisa que ensinar uma criança a multiplicar e dividir, sem antes ensiná-la a somar e subtrair, ela com certeza vai aprender, até é possível ela aprender somar e subtrair sem saber o que é, mas pode ser mais espendioso (tempo, recursos, etc).

Abraço!

j disse...

Fabrício,

Era exatamente isso que eu queria dizer. A OO utiliza conceitos dos paradigmas dos quais descende. Não dá pra fazermos um algoritmo de ordenação, por exemplo, só com os conceitos de OO. Já a programação estruturada possui ferramentas que possibilitam levar o aluno a pensar ordenadamente, transformando as suas ideias em algoritmos.

A própria OO, se você parar para pensar, termina na declaração de classes, métodos e seus demais conceitos, pois o que encontramos dentro dos métodos, em grande parte das vezes, é a programação estruturada, que tende a ser o mesmo paradigma que liga os objetos, dando sentido a sua existência.

Como você mesmo bem disse, é como aprender a multiplicar, sem saber somar. Vai ficar uma coisa abstrada para a pessoa, algo que acontece meio que como mágica e não algo a que se chega ao conhecimento por lógica.

Abraço!

maurim disse...

Fala Ze!!!!

Pelo visto sou o único que prefere ensinar alguma linguagem OO ao invés de linguagens somente estruturada. Se partimos pelo conceito que você não sabe programação, ao meu ver, não faz diferença entre as duas(como citado uma é basicamente a extensão dos conceitos da outra), você terá que ver os dois conceitos. Foram citadas estruturadas de dados, busca, ordenação. Imagine você dentro de um mesmo semestre podendo ensinar o aluno o método díficil e o método fácil?

O que pode dificultar mais ao aprendizado, ao meu ver, é a tipagem e não a estruturação do código.

[]

j disse...

Salve.

Há um engano da sua parte. Ninguém disse que deve-se ensinar uma linguagem estruturada em vez de uma linguagem OO. Falamos em programação estrurada em detrimento de programação OO. Há um abismo entre estes 2 conceitos.

Você pode ensinar Python de forma estruturada. Depois, ao ensinar OO, o impacto para o aluno seria reduzido. Contudo, ainda defendo a aprendizagem da linguagem C em cursos introdutórios, pois ela é um trampolim para outras linguagens. O objetivo de cursos introdutórios, como dito, não é ensinar ao aluno a criar super sistemas. O objetivo é ensiná-lo a pensar organizadamente, utilizando conceitos estruturados para criar algortimos que são utilizados na própria OO. Ensinar programação (note-se que a discussão é sobre programação, não sobre linguagens) OO sem que o aluno saiba programação estruturada é queimar etapas.

Além disso, como exposto, uma hora a pessoa, mesmo usando OO precisa recorrer à programação estruturada. Seja na implementação de um método ou no corpo do programa, que vai instanciar as classes e amarrar todo o código.

[]!

Fabricio Kelmer disse...

Realmente acho que não haja restrição quanto a ensinar OO antes de qualquer linguagem estruturada como o maurim disse que prefere, mas eu não concordo, como no meu exemplo da multiplicação antes da soma:
se eu tivesse aprendido quando criança a multiplicar antes de somar, acredito que com certeza eu teria adquirido talvez até um grau de intelecto superior a minha idade e superior a de alguns colegas, porém o tempo que um professor gastaria para colocar isto na minha cabeça seria maior do que o normal (disperdicio de recursos). E eu ainda ia acabar aprendendo a somar, pois multiplicação nada mais é do que somar um numero eu certa quantidade de vezes, porém eu jamais saberia que aquilo é somar, se é que me entendem, eu ia aprender indiretamente.

Concordo novamente com o zezim, o impacto é reduzido quando se começa com a base e eu acho estruturado a base.

Primeiro deve-se aprender a construir os métodos, para depois sim, aprender a reaproveitá-los. É uma ordem natural da vida!

Abraços!

maurim disse...

Não estou discordando que a forma estruturada é a base para o ensino, pois ela é a base da maioria das linguagens de alto nível. Mas alem da estruturação, o conceito de tipagem é muitíssimo importante.

Entendo sua preferência por linguagem C nos cursos introdutórios, por ser a base das linguagens em uso no mercado, e a migração seria um pulo.

Porém, os conceitos existentens em C existem nas linguagens OO, e.g., Java. Digo a nível de síntaxe. A lógica vai ser a mesma. O cast implícito das linguagem C pode dificultar o entendimento inicial, daí um linguagem fortemente tipada para ensino.

No meu entendimento, o exemplo de somar, é um conceito de escopo. Poderiamos multiplicar sem somar, atribuir um tipo inteiro a um double, isso é intuitivo e se adquire com o tempo.

Deve-se ensinar o que está em uso no mercado para ter-se profissionais adequados.

t+

j disse...

# Estou configurando o sistema aqui, por isso nao tem acentos.

Zé Mauro,

Voce leu o meu ultimo comentario? A discussao nao é sobre linguagens ou tipagem. E sobre paradigmas de programacao. Deixa eu tentar jogar uma luz no assunto.

As linguagens de programacao possuem diversas classificacoes. Algumas classificacoes comuns sao com relacao a geracao, paradigmas, tipagem e abstracao.

Em geracao temos linguagens de 1a, 2a, 3a... varias geracoes. Em paradigmas e' o que estamos discutindo. Tipagem tem a ver com fracamente, fortemente ou dinamicamente tipada. Quanto a abstracao, temos linguagens de baixo, medio, alto e altissimo nivel. Obviamente, na criacao da linguagem, os desenvolvedores nao se focam em criar uma linguagem OO, de 6a geracao e dinamicamente tipada. Eles tem as metas e ideias deles e depois da criacao eh que se verifica onde essas linguagens se encaixam nas classificacoes que normalmente sao feitas. Tomando por este ponto de vista, temos, por exemplo, Pascal, que se analisada a nivel de tipagem, e' fortemente tipada, a nivel de paradigma, pode ser OO, estruturada ou imperativa, a nivel de abstracao, alto nivel e a nivel de geracao, 3a.

Agora, voltando ao tema, fica facil entender em qual nivel estamos falando. Nao interessa aqui citar linguagens de programacao e tampouco se a linguagem A e' melhor que a linguagem B. A questao aqui sao paradigmas (OO e estruturado).

Dito isso, tem-se a programacao estruturada com seus conceitos simples e a OO, mais complexa. Quando comecamos a aprender programacao, a ideia eh que comecemos a pensar de forma ordenada, utilizando as construcoes basicas. Se formos seguir a sua sugestao de ensinar o paradigma OO, teremos alunos com 2 semanas de aula, muitos que nem sabem direito como programar, tentando entender como um objeto fica dentro do computador. Provavelmente alguns vao imaginar uma bola ou uma pessoa dentro do gabinete. Hoje em dia voce sabe multiplicar, porque aprendeu a somar. Dessa forma, quando voce le 2 * 3, o seu cerebro sabe que o que o asterisco esconde e' 2 + 2 + 2. Nao fosse isso, poderia parecer magica. Da mesma forma, mesmo que a pessoa consiga entender o que e' um objeto e todos os conceitos da OO, quando chegar na implementacao dos metodos, ela nao vai saber o que fazer (lembre-se que a OO nao ensina a fazer iteracoes, sequencias e decisoes).

Entendeu porque nao da' pra ensinar o PARADIGMA OO antes do ESTRURADO?

Talvez uma falha aqui tenha sido nao deixar claro o que esta' sendo discutido (paradigmas), ja' que como eu disse, as linguagens possuem varias classificacoes.

Abraco!

maurim disse...

Kra,

Segundo a Wikipédia: "Paradigma (do grego Parádeigma) literalmente modelo, é a representação de um padrão a ser seguido...".

Como OO herda as características do estruturado deve e pode ser ensinado primeiro. Não vai haver conflito nenhum entre as idéias, ao contrário, haverá um pensamento ainda mais modularizado.

As instruções herdam realmente dos paradigmas estruturados mas estão presentes, e nada impedem de ensiná-los por ela.

Pra mim o exemplo de somar e multiplicar e totalmente noção intuitiva. Você tem controle sobre um piscar de olhos, um bocejo?

E mais, o que um ponto ou uma reta?

Todos sabemos o que é mais isso não se explica. Todos nós pensamos estruturado kra, com o tempo só melhora.

T+

Fabricio Kelmer disse...

Bem,

"DEVE" ser ensinado OO antes eu não concordo, mas acho que "PODE" ser ensinado eu até concordo, não há empecilho algum, conforme falei, você perderá mais tempo. Se for levar em consideração o mundo de hoje, que esta "corrido". Por que seria poupar tempo a longo prazo ensinar OO. Mas eu aprendi estruturado e depois OO, o impacto foi muito mais agradável para mim.

Agora Zé Mauro disse que OO herda as características da estruturada, certo, é possível dizer quem veio primeiro, o ovo ou a galinha? Agora é possível dizer quem veio primeiro estruturada e OO. Quando aprendemos história na escola a gente começa do governo Lula e vai voltando até Dom Pedro I (por exemplo)? Não, como eu disse sobre a ordem natural da vida, deve-se aprender primeiro o básico, depois o avançado.

Vamos mudar o exemplo do soma e multiplicação, pegue então este exemplo: o sistema de governo feudal e o sistema de governo democrático.
Enxergo o feudal como estruturado e o democrático como OO. Comparando os dois veremos métodos que foram aperfeiçoados do feudal para o democrático.

O que acham?

Abraços!

j disse...

Agora estamos falando em paradigmas! ;-)

@maurim Existe uma região do cérebro (parte posterior do mesmo), responsável por comandar reações involuntárias [1]. Por isso, há uma parte de cada um de nós responsável por fazer o trabalho "sujo", como respirar, piscar e bocejar. Acontece que, para tornar comum uma ação dessas, você tem que saber o que é a ação. Pegando gancho na analogia do Fabrício, é uma ordem natural aprender do básico ao avançado e isto está implícito em várias coisas. Por que nós não saímos da 4a. série e vamos direto para o 1o. ano? Eu respondo: porque é necessário amadurecer o cérebro, tornando comuns termos que serão revistos e expandidos nas séries posteriores.

@Fabrício Kelmer Neste ponto, pensamos igual. É necessário ensinar do básico ao avançado. Principalmente em cursos de graduação, onde não basta que a pessoa saiba usar determinada ferramenta ou conceito: é necessário saber de onde veio, como evoluiu. Em cursos de graduação, tão importante quanto o conhecimento técnico, é a visão ampla sobre o assunto, o que cria críticos e não meros usuários. É como diz a famosa frase: Conhecer o passado, para projetar o futuro. O que acontece aqui é que o passado ainda é presente, uma vez que os conceitos estruturados são usados na OO e exigem tempo para assimilação (não podem ser explicados como quem ensina a localização da rodoviária da cidade a um estranho).

Sintetizando: pode-se conhecer um determinado termo e não saber muitos detalhes sobre ele. Da mesma forma, que pode-se conhecer o mesmo termo mais a fundo, o que, normalmente, garante mais consciência no uso. Se tratarmos de ensinar termos importantes, como aqueles que compõem a programação estruturada, de forma superficial, ou sem dar-lhes a atenção necessária, podemos acabar por mistificar esses termos, o que nos levaria a uma situação delicada. Eu afirmo categoricamente que os 3 que participam desta discussão utilizam muito mais if e for do que class.

Inté!

[1] http://redeglobo.globo.com/Globoreporter/0,19125,VGC0-2703-3131-3-48080,00.html

gabriel disse...

alguém pode me informar quando surgiu a programação estruturada?

Anônimo disse...

CARA ISSO É MUITO LOKO!

José Lopes disse...

Eu diria mais: Isso é muito louco demais... hehe

Anônimo disse...

Obrigado pelo excelente tópico!

José Lopes disse...

Valeu Anônimo! =D
Lembrando que agora o site está em joselop.es

loren disse...

Para início de aprendizado, estruturada, após a lógica a programação está bem clara na cabeça do indivíduo OO sem dúvidas, mais organizado eu digo que mais limpo..rs

Paulo Riceli disse...

Se forem só os conceitos envolvidos em cada paradigma não vejo razão para se preocupar com a ordem de aprendizado de cada um. Aliás se aprender os conceitos em apenas uma linguagem as outras serão assimiladas naturalmente... O problema é que o novato quer resultados sen esforços: aprender de verdade, o conceito por detrás da(s) coisa(s), enfim o átomo...

Parabéns pelo artigo e pelo site...

José Lopes disse...

@Paulo
Eu ainda defendo que o paradigma estruturado precisa ser explicado antes da OO, porque ele faz parte dela. De qualquer forma, é preciso que, como você bem disse, se aprendam os conceitos. Sem isso, tudo fica mecânico. Saber o porquê das coisas é muito importante.
Valeu!

digo disse...

Caracás, aprendi mais sobre o que é estruturação e OO nesta discussão do que no próprio texto.

Talyne Morais disse...

ADOREI.. MAAS PODIA REVER UMA AULINHAS DE HTML

José Lopes disse...

Aulas de HTML? :S

Anônimo disse...

Excelente post! =) E árdua discussão! Tirei muito disso! Apresentarei uma palestra sobre paradigmas e essa discussão será de ótimo proveito. Abraços!

José Lopes disse...

Essa discussão entrou pra história! :)

Thomas Velasques disse...

Olá
Realmente a discussão foi bem interessante.
Estou procurando coisas relacionadas a paradigmas entre POO , POE e PE porque tenho uma prova essa semana.
tem mais algum conteudo sobre isso?

se puder me enviar
thomasvelasques@hotmail.com

José Lopes disse...

Infelizmente, isso é tudo. Boa sorte.

Felipe disse...

Pelos comentarios e por minhas experiencias percebo que ensinar OO no inicio gera mais dificuldades, com isso o tempo para aprender é maior.
Aprender OO depois de Estruturada é dito como o certo, mas o aluno demora para abandonar más praticas aprendidas na estruturada e a pensar de forma mais abstrata, entao pergunto: será que o tempo a mais para aprender OO no inicio não é menor que o tempo para se acostumar e perder más praticas da estruturada, quando se aprende OO depois?

Nao defendo o ensino de OO no inicio, mas vejo muitos, as vezes eu, pensando de forma estruturada mesmo trabalhando com uma linguagem POO. Isso me faz pensar, as vezes, que é melhor ter dificuldade no inicio para evitar erros depois. Ate porque quando se aprende OO se aprende um pouco de estruturada, com isso a mudanca de OO para Estruturada é facil.

Ola disse...
Este comentário foi removido pelo autor.
Ola disse...

Minha opinião sobre Programação Orientada a Objetos [POO] vs Programação Estruturada [PE]

Primeiro e antes de tudo... Que esta comparação é absurda e infantil pra dizer o mínimo. Programação Estruturada não é um paradigma (Isso mesmo... lamento se você não sabia!) é uma técnica, uma forma, um método... Que foi, e é largamente utilizado junto com o Paradigma Imperativo (este sim um paradigma) e outra técnica chamada de Modularização (“Dividir pra conquistar...” Já ouviu isso né?) que também não é um paradigma...

Então que fique:
Modularização NÃO É PARADIGMA;
Programação Estruturada NÃO É PARADIGMA.
O PARADGIMA É IMPERATIVO.

*** A comparação deveria ser entre POO e Programação Imperativa. ***

Explicação...

Navegando por ai em blogs sobre programação encontrei esse texto

Mais um dentre os milhões de texto que prega a superioridade do Paradigma Orientado a Objetos em relação à Programação Estruturada, coisa que vejo no meu dia a dia em meu curso (Hordas e Hordas de “garotos de programas”, falando em termos de POO em detrimento de PE, como se nunca fossem usar PE na vida!)... E o quê me deixa mais perplexo com isto tudo é a grande confusão que fazem em relação à Programação Estruturada, que alias nem é um paradigma, caso não saibam o paradigma é o Imperativo que por fim acabou sendo associado a outra técnica conhecida como Modularização...

A programação Estruturada que não é necessariamente a programação Modular como essas pessoas infelizmente confundem, ela diz respeito ao controle de fluxo do código e não a visão abstrata que o programador terá ao implementar o programa; Colocando de outra forma, já existia o Paradigma de Programação Imperativo e também já existia a técnica de Modularização quando Michael A. Jackson escreveu Principles of Program Design em 1975, que é basicamente onde nasce a PE, digo isso por que:
Call, “sempre” existiu em assembly e esta é uma linguagem Imperativa, portando passível de ser Modularizada; Caso tbm não saibam é possível escrever funções e procedimentos e chama-los suando-se o mnemônico call em assembly, logo fica evidente que a Programação Estruturada não trata da modularização (da criação de “funções” ou “procedimentos” ou tão pouco do tema: “Como” e não o “o quê” fazer, como algumas pessoas insinuam).

Então do que trata a programação estrutura? Já disse: “Controle de fluxo”, Michael A. Jackson, Bohm e Jacopini, mostram que todos os programas podem ser escritos em termos de apenas 3 estruturas de controle.

1 – sequencia;
2 – seleção;
3 – iteração.

É disso que trata PE, de forma sucinta, do uso de sequencia (que é trivial, afinal os comandos são executados em uma ordem sequencial), seleção (if/else, switch/case...) e iteração (for, while, do while...), de forma que não é possível utilizar POO sem que haja PE dentro dos métodos que implementam as interfaces dos objetos... (vocês realmente não utilizam mais if, else, while, for?) O que por fim torna a comparação ridícula...

Não digo isso por que sou um “amante” da Programação Imperativa (estruturada no contexto errado dessa comparação!), muito embora acredite fortemente que este paradigma (Imperativo) ainda viverá por muito tempo... Que o diga quem já leu alguma parte do Kernel do Linux, do código fonte do Git ou do PHP ou do Ruby, entre outros... É tudo feito em C de forma Imperativa, Estruturada e Modular... E continuará sendo assim por muito tempo ainda...

Mas não digo isso por que sou um “amante” ou “fanático” da programação Imperativa, por que em verdade estudo muito POO e meus projetos todos seguem os princípios de POO por que acredito que seja o paradigma que mais se encaixe nos tipos de sistemas que faço...[Ficou muito grande]

Hugo Luiz Cruz disse...

O loco, é muita coisa.Tá show o tópico, eu agradeço muito.

Anônimo disse...

MUITO ÚTIL ESSE DOCUMENTÁRIO

Postar um comentário