DevMedia - asp.net, Java, Delphi, SQL e web Design, tudo em um só lugar!
Bem vindo a DevMedia!
LOGIN:     SENHA:
 
 

Programação Orientada à Objetos x Programação Estruturada

Neste artigo fiz segundo meus conhecimentos e preferencias um comparativo sobre POO e Programação Estruturada.

Muito se tem visto, ouvido e lido sobre POO, tanto na internet quanto em revistas e livros sobre programação. Mas porque será que tão poucos programadores comentam e programam em POO se é tão mais simples, a reutilização de código é mais fácil e o sistema acaba tendo um grau de manutenabilidade muito maior? Talvez a resposta para está pergunta seja muito mais complexa do que podemos imaginar. Mais o que realmente diferencia uma programação orientada a objetos de uma programação estruturada com reutilização de código?

Fiquei por meses pesquisando e estudando sobre as duas formas de programação. Acabei chegando as minhas proprias conclusões. Ambas as formas de programação possuem seus altos e baixos. Ambas possuem vantagens e desvantagens. Acredito que o ideal seria termos conhecimento sobre ambos os conceitos e tirarmos o melhor proveito deles. Sei que muitos programadores iram discordar de mim já que muitos trabalham com a programação estruturada e acreditam fielmente que o Delphi não foi projetado para se trabalhar com POO (Programação Orientada a Objetos), já outros ficam completamente indignados quando ouvem alguém dizer que a linguagem pascal (ou delphi language) é "incompativel" com a POO, e são programadores devotos dela.

Hoje fazendo algumas pesquisas aqui no forum mesmo, vi uma pessoa citar que leu em algum livro que a POO consome mais memória, ao ler isso nem sei explicar o que eu senti. Afinal, o que garante a qualidade final de um software? Na minha opinião, a programação seja ela POO ou estruturada, é uma arte. O programador ao adentrar neste mundo tem que estar disposto a aprender, se aprimorar e tratar um novo projeto como um bebê. Um novo projeto tem que ser olhado pelo programador como uma obra de arte e não como um amontoado de códigos e forms sem nenhum padrão. Antes de colocarmos a mão na massa, uma pesquisa de mercado, um levantamento sobre as necessidades dos usuários, é indispensável. Além de um projeto conciso e elaborado sobre o que vamos desenvolver. Na implementação do projeto temos que ter o mesmo empenho e disposição para a programação propriamente dita. Não basta apenas um bom projeto também se na hora "do vamos ver" for feito de qualquer jeito. Outra questão pouco abordada também é a segurança dos sistemas. Do que adianta um super software se a segurança dele for zero? Imagine você gastando horas e horas interminaveis na frente do computador, e ao distribuir seu sistema o mesmo é facilmente pirateado e você, desenvolvedor, acaba ficando sem nenhum retorno do mesmo? Ou então, um sistema com até um pouco de segurança, mas ao cair em mãos experientes de um ou outro cracker a segurança é quebrada.

Todos esses pontos devem ser analisados e estudamos na fase de elaboração do projeto. Ao iniciar a programação você deve saber exatamente o que e como desenvolver. Também é na fase de elaboração, que com estudos sobre as necessidades e funcionalidades que um sistema deva ter que escolhemos a melhor forma de programação (POO ou Estruturada). É claro que um mesmo software pode ser feito de ambas as formas, mas saber perceber e abstrair as vantagens de cada uma é o ponto chave para se escolher com qual vamos trabalhar em um ou outro projeto.

Minha intenção com este artigo não é convercer você sobre qual a melhor técnica, mas sim, dar a minha opinião sobre o tema. E para mim, uma integração entre as duas é a melhor. É certo que através de estudos, leituras e testes, muitos testes rs que você irá perceber qual a forma você melhor se adequa. Não tente se impor uma forma de programação porque um amigo ou professor disse que é melhor. A programação como tudo na vida é algo pessoal e cada um tem suas proprias preferencias.

Bom, chega de tanto blá blá blá e vamos aos conceitos de POO e Programação Estruturada propriamente dita.

Um sistema orientado a objetos é dividido em componentes e não mais em processos. Imagine um sistema financeiro, onde fariamos toda a administração de uma empresa. Teriamos as seguintes diferenças:

  • POO: Teriamos um objeto de fornecedores, por exemplo, onde todas as funções estariam agrupadas no objeto e em nenhum outro lugar.
  • Estruturada: As rotinas e funções de fornecedores estaria espalhada em todo o sistema, como em contas a pagar, contas a receber, cadastro, etc.

Imagine agora o cadastro de fornecedores, com todas as suas rotinas e funções:

  • Estruturada: Se você futuramente precisar alterar algum dado, função ou propriedade, o que em seu programa será afetado? O que terá que ser reestruturado? Imagine a você voltando a fase de testes e analisando todo o seu sistema até ter certeza que a alteração que você fez não desencadeou um finita listas de alterações que você terá que fazer em todo o sistema...
  • POO: as propriedades, funções e rotinas do objeto fornecedores estão todas em um único objeto, encapsulados, facilitando essa necessidade futura de alterações e atualizações.

Reutilização de código:

  • Estruturada: É possivel a reutilização de código na programação estruturada porém, em muitos casos você será obrigado a utilizar o famoso "copiar e colar".
  • POO: Com a POO você é capaz de elaborar um relacionamento entre diversos componentes, estabelecendo comunicação entre eles e facilitando assim, e muito a reutilização de código, além da facilidade de se poder herdar atributos e comportamentos de outros objetos.

Talvez uma pergunta nesse momento povoe a sua mente... Mas e a POO, é mais fácil de se programar com ela?

Talvez para nós que estamos acostumados com a estruturada o ínicio do trabalho com POO seja um pouco complicado, afinal estaremos nos deparando com um novo conceito de programação.

Imagine você desenvolvendo um programa, gastando horas e horas para elaborar, codificar e testar uma determinada rotina, agora se imagine tendo que implementar em um novo programa essa mesma rotina...

Com a Estruturada você gastaria mais horas e horas para implementá-las novamente, agora imagine com a POO, você criando um objeto ou componentes com toda essa rotina e num próximo programa apenas o utilizando... O ganho de produtividade será enorme, além de uma grande facilidade para você mesmo.

Para um próximo artigo irei desenvolver um exemplo de POO. Sei que nesse artigo expressei apenas minha opinião pessoal, mas espero a opinião de você comentando esse artigo, para juntos acrescentarmos mais e mais conhecimentos.

Um grande braço a todos.


Flavia Neves Dos Santos
Formada em 2004 no curso técnico de Informática Industrial e no final de 2005 no curso técnico de Processamento de Dados. Ambos os cursos ministrados pelo Centro Paula Souza na cidade de Mococa/SP. Atualmente executando trabalhos free lancers em .Net e base de dados SQL SERVER. Contato: lightshine...
O que você achou deste post?

    11 COMENTÁRIOS

[Fechar]

Este post é fechado - você precisa ter acesso ao post para incluir um comentário.



Ricardo Júlio
Muito bom esse seu post. Parabéns.
[há +1 ano] - Responder

 

[autor] Flavia Neves Dos Santos
Obrigada Julio. =^.^=
[há +1 ano] - Responder
 

Lindemberg Cortez

É um bom artigo....minhas congratulaçõess.

Algumas Observações:
  - Delphi Language se deu origem com ObjectPascal (POO), logo, Delphi language nao é pascal.
  - POO é bom, mas a medida que um sistema cresce muito, dependendo de como as classes foram implementadas, se com baixa coesão e alto acoplamento, o sistema pode se tornar um inferno como ou até maior que  a programação estruturada. Sendo assim, cuidado com as armadilhas do POO.Ouch
[há +1 ano] - Responder
 

Robson Rocha.
Maurício sua observação foi excelente. Dos artigos sobre introdução a OOP este foi o que mas transcreveu a transição de linguagem estruturada para orientada objeto.
[há +1 ano] - Responder

 

Maurício Vinicius De O. Santos
Para quem esta acostumado com programação estruturada, nada melhor do que exemplos usando OOP, mas exemplos feitos pelo que fazemos no dia-a-dia com programação estruturada...e nao aqueles exemplos como: Carro possui portas, vidros, cor, etc...
mas sim um exemplo como cadastro de clientes por exemplo....e utilizando alguma linguagem.
Fico aguardando o proximo Post...muito bom o artigo!
[há +1 ano] - Responder

 

[autor] Flavia Neves Dos Santos
Obrigada pelo feedback Mauricio. Estou criando um artigo em 03 partes de um sistema de cadastros utilizando POO. Em breve o postarei....
Flávia
[há +1 ano] - Responder
 

Ignacio De Loyola Oliveira De Castro
flavia, sinceramente não entendi ainda a POO existe alguem que de aula alno e professor de POO..
[há +1 ano] - Responder
 

Wesley Yamazack
Olá Ignacio,

A filosofia POO, realmente é muito complexa para se "explicar" em um único artigo, ela não é uma linguagem de programação mas sim mecanimos e boas práticas que te ajudam no desenvolvimento de seus sistemas. Não é uma linguagem de programação! Ela pode ser aplicada em qualquer linguagem de desenvolvimento.

Uma pessoa que hoje domina POO, pode facilmente programar em qualquer linguagem que deseja, .net, java, delphi, etc, a única coisa que ele terá que aprender é o conceito da linguagem em si e como fazer o que se quer fazer, pois o POO estando no sangue basta você aprender a sintaxe da linguagem desejada.

Em Delphi tem este curso que o amigo Rodrigo Carreiro esta finalizando

http://www.devmedia.com.br/curso/dominando-a-orientacao-a-objetos-e-componentes-em-delphi-avancado/120

Uma dica que te dou, somente ler não adianta, falo isso por experiência própria, eu lia muito sobre POO, quando decidi programar em POO eu falei, e agora? Pra onde vou ? Ou seja, se você não praticar não vai conseguir entender.
Fica ae minha dica! Quem quiser acrescentar algo fique a vontade.

Blz?

Um abraço

[há +1 ano] - Responder
 

Jorge Augusto C. Dos Reis
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... [Vai ficar longo]

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

Mais um dentre os milhões de texto quem pregam 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...

O que eu sou absolutamente contra são generalizações e comparações absurdas como esta... Até a tão almejada, sonhada e pregada, reutilização de código, torna-se problemática para certos propósitos que o diga em já usou STL em C++.
Então por fim, quero dizer que essas pessoas deveriam investigar mais as teorias formais, avaliar a história e também a realidade dos fatos (mundo opens source), antes de sair repetindo o que ouvem nos corredores das faculdades... POO é algo fascinante eu sou um grande admirador, estudante e entusiasta... Enfim sou fascinado por POO, mas a POO de fato... Com polimorfismo, herança e toda a teoria por trás e não apenas no “uso-zinho” de classes no que mais me parece a tal “programação baseada em objetos” e não ORIENTADA AOBJETOS.

É isso... [Ficou grande, desculpem.]
[há +1 mês] - Responder
 

Geraldo Costa Jr
É isso aí, nem 8 nem 80, o ideal em tudo é a convivência de coisas e sistemas concorrentes. Uma sugestão: montar um exemplo de uma breve rotina, desenvolvida em linguagem estruturada e em programação orientada a objeto. Assim ficará clara a diferença entre ambas.
[há +1 mês] - Responder

 

Reginaldo Donizete Felix
Muito bom o post, parabens
As diferenças entre as linguagens de programação estão sempre presentes em calorosas discussões nos grupos de programadores, encontrei uma piadinha antiga criada originalmente para explicar as vertentes do Metal que foi reaplicada para as linguagens de programação e dar uma visão das diferenças entre cada linguagem.
Segue o link abaixo
http://regifelix.com/2013/04/23/linguagens-de-programacao/

Abraço
[há 26 dias] - Responder

 
Cursos relacionados
Publicidade
[Fechar]

Você precisa estar logado para dar um feedback.

Clique aqui para efetuar o login
[Fechar]


Este post está fechado. Saiba mais sobre a assinatura MVP!
web-03
DevMedia  |  Anuncie  |  Fale conosco
Hospedagem web por Porta 80 Web Hosting
2013 - Todos os Direitos Reservados a web-03