Orientado a Objetos x Procedural

[Thiago Dias_132983 3]

ainda tenho muitas dúvidas sobre POO e gostaria que vocês me mostrassem um script em forma procedural e em OO mostrando as vantagens de cada um e a segurança , agradeço :D

[viniciuswebdev 8]

Orientação a Objetos é um paradigma, ele é usado para organizar o seu código e deixar ele mais lógico e mais fácil de dar manutenção, mas ele não vai por exemplo "aumentar a segurança" do seu site.

 

Não da pra explicar a essência da Orientação a Objetos mostrando apenas um exemplo, pra você pegar, você precisa ler bastante e praticar, o objetivo é centralizar e abstrair responsabilidades para que você saiba oque cada parte do sistema faz.

 

Tem muita gente por ai, criando um monte de classes sem logica nenhuma achando que está programando orientação a objetos, para você não cair no meio destes programadores, você precisa ter paciência e estudar, não tem jeito!

 

Livro recomendado:

 

http://www.novateceditora.com.br/livros/phpobj/

 

Abraço!

[Thiago Dias_132983 3]

Cara , muito obrigado , mas é que eu leio muito sobre isso , tento e tento , mas não entra na minha cabeça a vantagem , por isso apelei pra um exemplo :/

[mexicanox 7]

Tem muita gente por ai, criando um monte de classes sem logica nenhuma achando que está programando orientação a objetos

Infelizmente eu fiz parte deste grupo kkkk, mas ja dei uma boa evoluida nesse ponto.

 

Voltando ao foco....

Alem do que o viniciuswebdev disse, tem tambem a questao da reusabilidade de codigo, de forma procedural, pelo menos para mim, era muito mais dificil reutizar codigo.

 

Na verdade eu ate reutiliza, so que do jeito errado, que era peagar o codigo existente em projeto e modificar "algumas coisinhas" para funcionar em outro projeto.

 

Ainda preciso melhorar mais hoje em dia eu faço uma classe pode ser usada em diversos projetos e situacoes, sem a necessidade de mexer em sequer uma linha da classe, simplesmente "jogo" ela no projeto e ta pronta para uso.

 

Talvez nao seja a reposta que voce esperava, mas é uma experiencia minha que talvez te ajude.

 

 

flws

[Nawarian 17]

Cara, acho que tenho uma maneira fácil de você entender melhor essa dúvida da vida ^^

 

A programação orientada a objetos, além te todas suas facilidades como herança, polimorfismo e bla bla bla, lhe ajuda a manter a lógica da programação MUITO bem aplicada. Seu código "passa a fazer parte do mundo real", onde suas classes serão tratadas como Entidades, seus métodos/funções serão tratados como Ações destas Entidades, seus atributos/propriedades serão como Qualidades destas Entidades.

 

Exemplo:

 

Classe Pessoa 
{
    atributo_true_ou_false cansado;
  
     método Andar()
     {
            // Pessoa andando...
            // se cansado for = true, nao ande...
     }
}

 

E com este pedaço de código, você criaria quantas pessoas quisesse, todas elas poderiam andar e saber se estão cansadas ou não.

 

$thiagoDias = new Pessoa;
$nawarian = new Pessoa;

 

E então você poderia fazer com que apenas $nawarian andasse, ou apenas $thiagoDias andasse...

Neste mesmo passo, $nawarian poderia estar cansado, mas $thiagoDias não.

 

O mundo inteiro pode ser visto como uma classe, pode ser subdividido em subclasses, seu aparelho de TV vem de uma classe com atributos ~ volume, canal, polegadas ~, métodos ~ aumentarVolume(), mudarCanal(), desligar() ~

 

Onde a classe define uma TV, mas a SUA TV é um tipo proveniente deste padrão TV.

 

$suaTV = new TV;
$minhaTV = new TV;

 

Porém a sua TV não precisa ter necessariamente os mesmos valores que a minha TV, sabemos apenas que as duas possuem valores para as mesmas coisas.

Ex.: Ambas TVs possuem um volume atual, a minha pode estar em 10 e a sua em 15...

 

Espero ter lhe ajudado mais do que confundido, orientação a objetos é um assunto muito extenso e merece atenção focada ao paradigma, independente da linguagem aplicada.

[Thiago Dias_132983 3]

Cara , Muito Obrigado , sua explicação foi ótima !

[Rodolfo TI 6]

mas é que eu leio muito sobre isso , tento e tento , mas não entra na minha cabeça a vantagem

Talvez não seja nem a melhor pessoa a te responder isso pois também tenho muitas dúvidas sobre OO, mas a maneira que encontrei de amenizar minhas dúvidas foi começar a desenvolver pequenos projetos, comece a desenvolver no papel, com diagrama de classes , caso de uso e outras técnicas UML essas são feitas para ajudar no planejamento de uma aplicação e como tudo nessa vida a prática nos ensina muito, é inviável começar sem um alicerce então pegue uma literatura iniciante para lhe auxiliar e com o tempo e a prática vai se aperfeiçoando, mantenha os pés no chão e os dedos no teclado, e nunca pense que por um sistema ter uma ou outra classe alguns objetos que é java programmer nível hard, acho que se mantermos o pensamento de que sempre podemos aprender mais nossa evolução continua por muito tempo.

[apprendiiz 0]

Pessoal, a maior dificuldade do programador é lidar com o mundo real, por isso ele é tão bom na programação, a programação não tem que ser igual ao mundo real, um código fonte não tem que ser entendido por todo mundo, isso é o que diferencia um programador de outra pessoa não programador. rs

brincadeiras a parte, também tenho minha opinião:

Também não consigo ver vantagens como o Thiago, e eu tento encontrar vantagens já que o mercado tá adotando bastante, e sabe, eu entendo OOP(estou até fazendo uns trabalhos em oo por que umas das exigências é fazer em oo), eu consigo entender a orientação a objetos, e isso ainda piora as coisas por que quanto mais vejo oo, menos vejo vantagens que justifiquem o seu uso em vez do procedural, já dei uma estudada, sei que facilita principalmente pra quem não entende de programação procedural( afinal parece com o mundo real onde todos vivem e para muitos a lógica procedural é mais complicada, mas não para um bom programador), deixa o código mais organizado, legível e etc,

tem muitas vantagens ai que a galera fala mas não sei o por que, logo que eu consigo reutilizar todos meus códigos procedurais com funções, variáveis globais e etc tranquilamente e sem alterar nada, sem conflitos, posso organizar cada conjunto de funções em arquivos php e inclui-los onde quiser por exemplo, é só fazer bem feito, verificar várias condições e etc.

 

Eu entendo que oo tenha vantagens para muitos, mas para mim as vantagens da oo não compensam o esforço de se escrever um código bem maior(não que seja dificil, só desnecessário), com mais atributos e controles em vão, logo que o que se faz em 5 linhas com oop eu faço em menos de uma com procedural.

mas é somente minha opinião pessoal, eu gostaria até que alguém mostrasse vantagens da oo que não seja fazer com que compreendam melhor a programação, segurança e organização, por que sinceramente, não consigo ver e gostaria, por que querendo ou não, tenho que programar em oo pelas exigências de mercado e gostaria de faze-lo feliz e não achando que poderia fazer melhor e com mais agilidade em procedural.

Mas essa é somente a minha opinião e espero não ter falado muita besteira, e espero ver vantagens na oo, por que até agora não vejo uma que vale a pena.

[paulinhosupriano 103]

Olá meus amigos e principalmente meu irmão Apprendiiz.

 

Segue o link http://www.authorstream.com/Presentation/joaogomeso-1651539-programa-estruturada-vs-orientada-objetos-poo/

 

Espero que entenda das vantagens e desvantagens.

 

Bom pegando um gancho no desabafo de nosso amigo Apprendiiz.

 

Orientação a Objeto seria na verdade ganho de tempo para futuros projetos e melhorias sem alteração do que já foi criado dependendo do tipo de visualização informada na classe.

 

a Programação Estruturada é muito influente. Uma vez que grandes partes das pessoas ainda aprendem programação através dela.

Para resolução de problemas relativamente simples e diretos, esta programação é muito eficiente.

Vantagens

Provê um melhor controle sobre o fluxo de execução do código, quando comparada com a programação imperativa.

É fácil de entender , sendo amplamente usada em cursos introdutórios de programação.

 

Vantagens da programação Orientada a Objetos

Continuidade, Reutilização, Manutenção e Produtividade, abstração, herança, implementações, tipo de visualizações, construtores, clones, autoloads, destrutores etc...

Ex: Class Pessoa (Nome, Endereco, Telefone, Email)

Acontece que existe Pessoas Deficientes então Criaria a class Pessoa_Deficiencia.

Então a Class Pessoa_Deficiencia enxtends Pessoa ou seja tela todos os métodos e atributos da class pessoa adicionando apenas na class Pessoa_Deficiencia o tipo de deficiência para está pessoa e os métodos necessário para as deficiências tipo: deficiente auditivo, deficiente visual, deficiente etc....

 

Resumindo que achou que falei de mais, você poderá recriar ou criar acima de outra class extendendo a mesma.

 

Resumindo: A conexão com o banco de dados você extendendo apenas as classes que herdar a conexão poderá fazer o CRUD no banco, ou apenas X coisa no banco. Tudo fica a critério do projeto e do programador.

 

 

 

Este post solucionou a sua dúvida, peço que coloque como resolvido e me der um ponto positivo de reputação para que eu possa continuar ajudando outros colegas como você.

Caso não solucione o seu problema, peço que coloque a sua dúvida abaixo.

 

Att: João Paulo Sousa Supriano

[hinom 5]

#8 o que vc postou é contraditório..

 

primeiro diz que entende OOP e então diz que não vê vantagem em relação ao procedural..

 

oras, então não entende OOP

 

rsrsrsr

[Thiago Dias_132983 3]

Essa pergunta é velha, hoje eu já conseguir "abrir minha mente" rs, mesmo assim obrigado aos que ainda comentaram!!

[raonibs 64]

É difícil para quem esta começando entender todo o potencial de OO, ela existe para resolver problemas que muitos talvez ainda nem tenham passado. Ela resolve os problemas de "dejavu" em escrever uma aplicação que possui um código parecido em outro projeto mas que estava tão embananado que era mais fácil reescrever do zero a nova aplicação do tentar aproveitar e refatorar a antiga.

 

Ela facilita em muito a reutilização, manutenção e teste do código. Gosto muito do texto de Matt Zandstra que ilustra muito bem o problema e quem enfrentou um projeto grande em procedural que não deu certo talvez vai entende-lo melhor do que gostaria.

 

 

O problema

A questão é que PHP é fácil demais, o que o incentiva a implementar suas idéias, retornando, assim, bons resultados. Algumas dessas facilidades são a possibilidade de digitar grande parte de seu código diretamente em suas páginas da Web, adicionar funções úteis (como um código de acesso a banco de dados) a arquivos, incluindo-as de página em página e, antes de se dar conta, você já tem um aplicativo Web em execução.

Bem, na verdade você está indo em direção ao desastre, porém nem percebe, é claro, pois seu site parece fantástico; ele funciona bem, seus clientes estão satisfeitos e gastando dinheiro.

O problema surge quando você retorna ao código para iniciar uma nova fase. Mas, agora, você tem equipe e orçamento maiores e mais usuários. E, sem aviso algum, as coisas começam a dar errado, como se seu projeto tivesse sido envenenado.

Nesse momento, seu novo programador quebra a cabeça para entender o seu código, que para você pode ser óbvio, embora, talvez, um pouco pretensioso em suas declarações e expressões. Porém, ele, o programador, está demorando mais que o esperado para exibir seu potencial e poder vir a se tornar um membro da equipe.

Uma mudança simples, estimada para um dia, aumenta para três dias ao descobrir que será preciso atualizar 20 ou mais páginas da Web. Então, um de seus programadores salva sua própria versão de um arquivo por cima das principais mudanças que você mesmo havia feito no mesmo código. Mas tal perda só é descoberta três dias depois, quando você já alterou novamente a sua própria cópia do mesmo código.

E, assim, mesmo usando um terceiro desenvolvedor, que também estava trabalhando no arquivo, leva-se mais de um dia para organizar toda a bagunça.

Depois, devido à popularidade do aplicativo, você precisa migrar o código para um novo servidor. O projeto tem de ser instalado manualmente e, então, você descobre que, na maioria dos códigos-fonte, os caminhos de arquivos, nomes de bancos de dados e senhas foram codificados permanentemente. Então, você interrompe o processo de migração, pois não quer sobrescrever as alterações de configuração necessárias. Mais à frente, alguém teve a “brilhante” idéia de envolver no projeto o módulo ModRewrite do Apache.As duas horas estimadas viram oito, e, agora, o aplicativo requer o funcionamento adequado de tal módulo.

Pronto, você finalmente prossegue para a fase 2 e, por um dia e meio, tudo corre bem. Porém, quando você está prestes a sair do trabalho, chega a notícia do primeiro bug encontrado e, minutos depois, o cliente telefona para reclamar. A explicação é a mesma, mas após uma análise mais minuciosa, descobre-se que o mesmo problema está sendo causado por um bug diferente. Você, então, se lembra de que lá no início da fase foi necessária uma simples mudança que exigiu diversas modificações no projeto inteiro e percebe que nem todas foram feitas, o que pode ter ocorrido por descuido ou, durante a união dos arquivos em questão, eles foram sobrescritos.

Aí, você apressadamente faz as alterações necessárias para consertar os bugs, pois está ansioso para testá-las. Como essa é uma simples tarefa de copiar e colar, o que pode dar errado?

Na manhã seguinte você chega ao trabalho e descobre que o módulo do carrinho de compras não funcionou a noite inteira, pois nas mudanças corriqueiras feitas de última hora você esqueceu de colocar o ponto de interrogação principal no código, tornando-o inoperável. E, claro, enquanto você dormia, alguns clientes em outras partes do mundo estavam acordados e prontos para gastar dinheiro em sua loja virtual. Você, então, conserta o problema, tranqüiliza o cliente e reúne sua equipe para mais uma jornada de buscas e consertos de bugs no projeto.

Essa historinha muito comum entre os programadores pode parecer um pouco exagerada, mas freqüentemente vejo isso acontecer. Muitos projetos PHP começam simples e pequenos e acabam se tornando verdadeiros monstros, de tão grandes.

Devido à camada de apresentação também possuir a lógica do aplicativo, a duplicação de código surge assim que consultas a banco de dados, autenticações, processamento de formulários e outras coisas são copiadas de uma página a outra. Se um bloco de código for alterado, todas as suas cópias terão de ser modificadas também, caso contrário, certamente haverá bugs.

A falta de documentação dificulta a compreensão do código e a escassez de testes permite que bugs passem despercebidos até a hora da implementação. De natureza dinâmica, o negócio de um cliente geralmente implica que o código acabe se afastando tanto de seu propósito original que chega a executar tarefas para as quais não foi projetado. Como o código freqüentemente se torna um emaranhado confuso de números e letras, fica difícil, senão impossível, trocar ou reescrever partes para que satisfaça às novas exigências.

Porém, nada disso é má notícia se você é um consultor PHP autônomo. Avaliar e consertar um sistema como esse lhe proporciona a regalia de poder pagar festas caras, assim como boxes e mais boxes de DVD por seis meses ou mais.

Mas, falando sério, problemas como este podem resultar no sucesso ou no fracasso de um negócio.

 

[DilsonMarcos 0]

Ainda sou iniciante e pouco sei sobre formas de uso OOP e desde minhas primeiras arriscadas no php sempre foram procedurais, mas sempre insistindo em aprender OOP, hoje nos pequenos projetos que desenvolvo chego a ser eclético, pois parte uso OOP e parte uso procedural e acho que isso já é um fator de fase migratória de técnica (procedural para oop).

 

Duas coisas que gosto de usar com classes atualmente:

 

1 - Classe que organiza a captura e a devolução de dados através do set's e get's. Acho bacana porque todos os campos da minha tabela pré vejo e planejo o fluxo de dados ali.

 

2 - Construção da conexão, então na hora de usar esta classe eu instancio por parametro os dados de conexão. Acho legal porque com isso tenho liberdade de inserir (se for necessário) dados em tabelas de múltiplos bancos, pois o construtor tá lá e cá vou dizendo:

 

dbname=banco_um

dbname=banco_dois

 

Disso já não abro mão, pois conseguimos rastrear com facilidade o canal de dados.

 

Obrigado pelas dicas que já passaram, espero aprender mais.

[Enrico Pereira 299]

um código fonte não tem que ser entendido por todo mundo

 

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." - Martin Fowler.

[Henrique Barcelos 290]

Uma pergunta genérica dessas vai render muitos off-topics -_-

 

Thiago, eu sugiro que você leia sobre o assunto (livros de verdade, não artigos suspeitos das internéitz) e venha com dúvidas mais concretas.

[Williams Duarte 431]

#12

 

Como no texto, já passei por isso em 2009, sai de um curso da Borland e com umas idéias na cabeça resolvi montar uma empresa de marketing place junto ao um sócio.

 

Começamos a desenvolver nosso sistema em PHP "procedural e o pior tudo em spaghetti", e achávamos um máximo, vamos ganhar dinheiro disse, iniciaram as primeiras vendas e logo também as dores de cabeça, tecnologias em OOP surgindo ao nosso redor e precisávamos implementar, comecei a correr atrás do prejuízo apreender OO, na época tínhamos poucas referencias nacionais e a empresa crescendo, e não conseguia achar programadores em php em minha região que entendia do assunto. Eu em stress constante por causa de cobranças de clientes, que a cada dia queriam algo novo que em procedural era inviável, Acabei vendendo a empresa e comprando outra menos estressante.

 

O que aprendi com isso foi, se quer começar algo grande, comece aplicando o conceito básico de OOP e evite gambiarras que a procedural lhe proporciona aos montes.

[apprendiiz 0]

irmão:

gostaria até que alguém mostrasse vantagens da oo que não seja fazer com que compreendam melhor a programação, segurança e organização

na verdade eu até acho oo mais fácil, acho que é só um pouco confuso para alguns programadores que precisam migrar de procedural para oo, já que é um conceito diferente, como todos estão escrevendo ai, oo realmente é bem mais fácil de entender, isso é verdade.

 

e obrigado pela resposta irmão.

 

PS. estudam baixo nível e sem oo em cursos com engenharia da comp. e ciências da comp., linguagens como: C, Assembly e etc, e não são para iniciantes.. são linguagens entre outras coisas usadas em kernel, de fato são usadas em grandes projetos.

 

#8 o que vc postou é contraditório..

 

primeiro diz que entende OOP e então diz que não vê vantagem em relação ao procedural..

 

oras, então não entende OOP

 

rsrsrsr

 

 

mas eu vejo vantagens, só disse que não vejo vantagens que vale a pena a migração para oo.

 

 

É difícil para quem esta começando entender todo o potencial de OO, ela existe para resolver problemas que muitos talvez ainda nem tenham passado. Ela resolve os problemas de "dejavu" em escrever uma aplicação que possui um código parecido em outro projeto mas que estava tão embananado que era mais fácil reescrever do zero a nova aplicação do tentar aproveitar e refatorar a antiga.

 

Ela facilita em muito a reutilização, manutenção e teste do código. Gosto muito do texto de Matt Zandstra que ilustra muito bem o problema e quem enfrentou um projeto grande em procedural que não deu certo talvez vai entende-lo melhor do que gostaria.

 

 

 

 

 

 

rsrs, nossa!

 

vendo por esse ângulo, realmente vejo que no trabalho em grupo realmente oo leva muitas vantagens.

 

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." - Martin Fowler.

 

 

diz isso pra quem usa linguagens de baixo nível ou até RNA, programar em linguagens de alto nível extremamente fáceis que todo mundo entende como php só foi possível graças a outras linguagens bem mais difíceis que poucas pessoas conseguem entender, pense nisso.

 

 

Agradeço a todas as boas respostas. abraços.

[ESerra 744]

Acredito que a sua dificuldade em ver vantagens está mais no modo como é vendido o paradigma, digo isto porque as pessoa falam de OO no PHP como se fosse uma coisa fantástica que separasse programadores jedi de amadores, isto é burrice. O que eu aplico desde sempre no trabalho é: fazer o certo da forma mais simples possível.

 

Aprendi OO na graduação, para "forçar" a pensar da forma correta ensinavam o paradigma usando a linguagem smalltalk "onde tudo é objeto", de fato facilitou o aprendizado, e isso ajudou muito no final a aprender Java, a linguagem mais fantástica do mundo (que fique claro: segundo o mercado).

 

Quer um conselho? Faça a coisa do modo que você acredita que é correto, utilizar OO só porque alguém diz faz algum sentido? OO resolve todos os problemas do mundo? Dá uma pesquisa pelo fabuloso framework "CodeIgniter", na minha opinião um dos maiores engodos do PHP em todos os tempos, essa fabulosa fábrica de aberrações vai te mostrar bem como não trabalhar com OO...

 

Ademais, se você já entende o conceito, vai conseguir trabalhar no mercado, mas não se iluda muito, quando trabalhava como empregado peguei empresa que exigia "sólidos conhecimentos em PHP5 com OO" e nunca criei uma classe, por outro lado tive que dar manutenção em sistemas que a própria empresa de origem tinha desistido de dar manutenção, pois apesar de ser OO, nem eles entendiam como o sistema tinha sido feito, enfim coisas do mercado.

[Enrico Pereira 299]

C, Assembly e etc, e não são para iniciantes.. são linguagens entre outras coisas usadas em kernel, de fato são usadas em grandes projetos.

 

Assembly não, mas C é uma das linguagens mais adequadas para ensinar programação a um novato, pois dá uma clara visão sobre tipos, ponteiros e vários outros fatores que linguagens de mais alto nível simplesmente abstraem e/ou não têm. Mas isso não está relacionado com o tópico.

 

diz isso pra quem usa linguagens de baixo nível ou até RNA, programar em linguagens de alto nível extremamente fáceis que todo mundo entende como php só foi possível graças a outras linguagens bem mais difíceis que poucas pessoas conseguem entender, pense nisso.

 

Perceba bem no que eu dei quote na hora de escrever isso, não foi uma frase aleatória.

 

----

 

Eu acho que para aprender OO, uma boa coisa é se afastar do PHP e só voltar para ele quando souber o paradigma. O PHP é uma caca em questão de design e de material de qualidade disponível e isso pode atrapalhar quem estiver aprendendo OO.

 

A dica de SmallTalk é uma boa também. Outras linguagens que são puramente OOP e que podem ser úteis no aprendizado são Self e Ruby.

[Henrique Barcelos 290]

tem muitas vantagens ai que a galera fala mas não sei o por que, logo que eu consigo reutilizar todos meus códigos procedurais com funções, variáveis globais e etc tranquilamente e sem alterar nada, sem conflitos, posso organizar cada conjunto de funções em arquivos php e inclui-los onde quiser por exemplo, é só fazer bem feito, verificar várias condições e etc.

Reuso não é CTRL+C + CTRL+V :closedeyes:

 

na verdade eu até acho oo mais fácil, acho que é só um pouco confuso para alguns programadores que precisam migrar de procedural para oo, já que é um conceito diferente, como todos estão escrevendo ai, oo realmente é bem mais fácil de entender, isso é verdade.

Entender é uma coisa, saber aplicar é outra completamente diferente.

 

 

PS. estudam baixo nível e sem oo em cursos com engenharia da comp. e ciências da comp., linguagens como: C, Assembly e etc, e não são para iniciantes.. são linguagens entre outras coisas usadas em kernel, de fato são usadas em grandes projetos.

C não é baixo nível e é sim para iniciantes. No meu curso a galera aprende C no primeiro semestre. Claro que demora um pouco até você entender o que são ponteiros e referências, mas C é a "linguagem-mãe".

 

Assembly serve apenas para coisas muito específicas e tende a cair em desuso com o avanço da tecnologia dos compiladores.

 

 

diz isso pra quem usa linguagens de baixo nível ou até RNA, programar em linguagens de alto nível extremamente fáceis que todo mundo entende como php só foi possível graças a outras linguagens bem mais difíceis que poucas pessoas conseguem entender, pense nisso.

RNA não é linguagem... São algortimos muito específicos onde realmente não dá pra saber o que acontece em seu interior, são uma caixa preta pois são autônomos, tentam emular o funcionamento do cérebro humano, que também não sabemos ao certo como funciona. Mas isso não faz parte do escopo da discussão.

 

É possível produzir um código legível tanto em C ou Java quando em PHP ou Python, basta ter conhecimento e boa vontade para isso.

 

Reuso não é CTRL+C + CTRL+V

:graduated: