PHP OO - É sempre melhor usar?

[marcelobbt 7]

Estava desenvolvendo um programa em PHP e como percebi que ia ficar bem grande, resolvi começar a fazer do jeito "certo", usando OO, mas logo no começo me deparei com uma questão. OO é sempre melhor que uma programação no modo tradicional?

 

Porque está pergunta? Bem, eu tinha o seguinte código para acessar o BD:

 

include "/config_bd.php";

 

então acabei mudando para algo assim:

 

include 'classes/configbd.class.php';

$abre = new Banco;

$abre -> conectar ();

Então passei de uma linha para três linhas. Aí fiquei me perguntando se deveria usar OO para tudo ou apenas para onde tenho grande volumes de código?

[erison 63]

seu ponto de vista esta errado, poo e muito melhor que estruturado.

 

eu tenho um função de upload, dentro dela.

 

* ela redimensiona a imagem proporcionalmente.

* pode fazer upload de arquivo, e assim não habilita a opção de redimensionar.

* posso escolher em criar uma ou duas imagem, posso ter uma galeria e criar duas imagens uma grande e outra pequena, para na hora de exibir não demorar tanto.

e outras opção que não estou lembrado no momento, isso tudo e por parâmetros que passo na função.

 

imagina se tive-se que copiar e colar esse codigo em todas as paginas que precisa-se de upload, e depois me depara-se com um erro nesse código futuramente?

iria ter que mudar em todas as paginas, alem de ta aumentando e muito minha linha de programação.

 

e com a função altero apenas nela, e depois só chama-la.

 

deu para entender a diferença?

 

 

isso foi um exemplo meu, mais na internet tem vários outros.

 

 

 

Então passei de uma linha para três linhas. Aí fiquei me perguntando se deveria usar OO para tudo ou apenas para onde tenho grande volumes de código?

 

qual você acha que e o correto.

<?php
/* example 1 */

$i = 1;
while ($i <= 10) {
    echo $i++;  /* the printed value would be
                   $i before the increment
                   (post-increment) */
}

/* example 2 */

$i = 1;
while ($i <= 10):
    echo $i;
    $i++;
endwhile;
?>

ou esse

 

 

<?php $i = 1;while ($i <= 10) { echo $i++;}$i = 1;while ($i <= 10):echo $i;$i++;endwhile;?>

 

 

o segundo e bem menor que o primeiro, nem sempre por que e menos linha esta correto imagine isso no meio de uma programação de 5 mil linhas. o tempo que iria demorar para identificar as coisas.

sempre documente e faça uma boa indentação do código, para no futuro ser melhor de dar manutenção.

[Vinicius Rangel 208]

escrever mais não significa ter mais trabalho.

OO é praticamente isso, você escreve mais para ter menos trabalho no futuro.

[marcelobbt 7]

Entendi o ponto de vista de vocês e de todos materiais que li por aí.

 

Mas nesse caso específico que criei, onde você tem uma página que faz a conexão somente, seria ideal colocar isso em OO?

Pois na hora da manutenção será apenas mudar o código que está na página incluída.

 

Estou falando para esses casos que são pequenos, não é mais fácil simplesmente chamar a página que basicamente tem apenas uma função e que seu código não precisará ser repetido em outras páginas?

[Jonaslhp 39]

seu ponto de vista esta errado, poo e muito melhor que estruturado.

 

Não concordo com isso, tudo depende do que você vai fazer, do tamanho da sua equipe e projeto. Nada impede de termos um projeto bem feito e arquitetado escrito de forma procedural.

Citando seu exemplo de upload, eu poderia simplesmente separar essa função em um arquivo exclusivo para o upload e usá-lo em diferentes partes do sistema apenas incluindo o arquivo. Aliás, tem muita gente que acha que escreve orientado a objetos, mas faz exatamente isso: Inclui as funções dentro de uma classe e chama de OO (Longe de mim estar dizendo que é o seu caso).

 

Mas nesse caso específico que criei, onde você tem uma página que faz a conexão somente, seria ideal colocar isso em OO?

Pois na hora da manutenção será apenas mudar o código que está na página incluída.

 

Imagino que se tiver a possibilidade desse seu script crescer, seria interessante fazer em orientação à objetos. Em alguns casos eu uso PHP estruturado mesmo, como por exemplo, um mini-site feito em HTML que precisa disparar um e-mail ou uma consulta simples no banco de dados.

[Pedro Roccon 9]

Entendi o ponto de vista de vocês e de todos materiais que li por aí.

 

Mas nesse caso específico que criei, onde você tem uma página que faz a conexão somente, seria ideal colocar isso em OO?

Pois na hora da manutenção será apenas mudar o código que está na página incluída.

 

Estou falando para esses casos que são pequenos, não é mais fácil simplesmente chamar a página que basicamente tem apenas uma função e que seu código não precisará ser repetido em outras páginas?

 

Marcelobbt, eu usava bastante programação estruturada, mas agora que passei para OO está difícil largar. Realmente, casos bem pequenos eu utilizo a estruturada ainda. Mas só quando são coisas bem pequenas mesmo, tipo um sisteminha de upload via FTP.

 

Agora, uma coisa que eu acho legal da POO é que você consegue aproveitar muita coisa. Como já tenho várias classes que me ajudam prontas, é praticamente certo que eu faça com POO, as vezes até mesmo se for algo pequeno.

[erison 63]

Não concordo com isso, tudo depende do que você vai fazer, do tamanho da sua equipe e projeto. Nada impede de termos um projeto bem feito e arquitetado escrito de forma procedural.

Citando seu exemplo de upload, eu poderia simplesmente separar essa função em um arquivo exclusivo para o upload e usá-lo em diferentes partes do sistema apenas incluindo o arquivo. Aliás, tem muita gente que acha que escreve orientado a objetos, mas faz exatamente isso: Inclui as funções dentro de uma classe e chama de OO (Longe de mim estar dizendo que é o seu caso).

 

 

Imagino que se tiver a possibilidade desse seu script crescer, seria interessante fazer em orientação à objetos. Em alguns casos eu uso PHP estruturado mesmo, como por exemplo, um mini-site feito em HTML que precisa disparar um e-mail ou uma consulta simples no banco de dados.

 

eu já usei estruturado, e sei que para quem não conhece parece que e correto isso.

 

http://www.guiadophp.yoonix.com.br/2010/10/08/php-orientado-a-objetos-ou-nao/

http://answers.yahoo.com/question/index?qid=20111109185323AAUUmma

 

foi os primeiros links que achei no google.

 

e isso que você fala em dividir em paginas e da include e muito errado.

[Jonaslhp 39]

e isso que você fala em dividir em paginas e da include e muito errado.

 

E por que seria muito errado? Não vejo outra forma de se programar estruturado e não se repetir e embananar todo o código sem separar as funções em arquivos específicos e incluir os arquivos nas páginas necessárias. Como você faria?

 

Não estou nem defendendo o jeito estruturado de ser, até porque hoje estudando OO, vejo que isso é o que o PHP tem pra oferecer de melhor.

[erison 63]

E por que seria muito errado? Não vejo outra forma de se programar estruturado e não se repetir e embananar todo o código sem separar as funções em arquivos específicos e incluir os arquivos nas páginas necessárias. Como você faria?

 

Não estou nem defendendo o jeito estruturado de ser, até porque hoje estudando OO, vejo que isso é o que o PHP tem pra oferecer de melhor.

 

comparado as formas de programar hoje e errado.

 

se você tiver 100 funções separadas em cada pagina,

vai ter que dar 100 include.

 

1º vai deixar muito grande sua view(no caso sua pagina de visualização).

2º proporciona mais erros, caso você erre o caminho tem que achar onde e depois pode ser mais de um include errado.

3º e mais pratico da um include e chamar as funções desejas.

4º ao procurar a função ja vai estar tudo centralizado em um local, não tem que sair procurando.

 

 

 

te dar um outro exemplo de função.

 

tenho uma função de porcentagem.

 

 

não e mais facil chamar assim

 

$function->procentagem($valor,$porcentagem);

do que ter que repetir a formula de calculo em toda linha que eu precisar?

e tem varias vantagens se não vou passar o dia digitando.

[Jonaslhp 39]

se você tiver 100 funções separadas em cada pagina,

vai ter que dar 100 include.

 

Você não precisa dar 100 includes, nem colocar UMA única função por arquivo. Basta separar semelhante ao que fazemos em OO:

 

dataUtil.php

<?php
    function verifica isFriday( $date )
    {
        //verifica se é um dia util
    }

    function isValidDate( $date )
    {
        //verifica se é uma data válida
    }

    function dateToDb( $date )
    {
        //Converte uma data para o formato americano p/ salvar no BD
    }

    //mais funções de data

Se você fizer algo muito diferente disto em OO, estará delegando mais de uma responsabilidade por classe, e estará quebrando o princípio da SRP.

 

 

tenho uma função de porcentagem.

 

 

não e mais facil chamar assim

 

$function->procentagem($valor,$porcentagem); 

do que ter que repetir a formula de calculo em toda linha que eu precisar?

e tem varias vantagens se não vou passar o dia digitando.

 

Depende do contexto. Porque você acha que é mais fácil fazer desse jeito do que assim:

 

$valor = porcentagem( $valor, $porcentagem );

Lembrando que dependendo do contexto, você ainda deveria instanciar o objeto. Sem objeto, não adianta jogar tudo numa classe e falar que é OO.

 

Não estou dizendo que estruturado é melhor que OO, nem vice-versa, só acho que tudo varia de acordo com cada caso, tendo em vista o objetivo do autor do tópico.

[William Bruno 1501]

não é mais fácil simplesmente chamar a página que basicamente tem apenas uma função e que seu código não precisará ser repetido em outras páginas?

hum.. mas nada em OO disse para vc parar de "fazer isso".

 

O primeiro passo é entender que a forma de pensar muda. Fazer estruturado, onde vc tem uma função que conecta, numa extensão global como a mysql_* ou cria variaveis globais para sair usando, é a forma estruturada de pensar.

 

Qndo vc for programar OO, vc vai injetar a dependência do banco nos objetos model, e não "fazer um include de um arquivo que conecta". Entendeu o ponto ? O pensamento é diferente.

 

Se vc tentar programar OO, pensando em funções, e includes.. ai a coisa não vai para frente, e tudo parece fazer menos sentido do que faz.

[Enrico Pereira 299]

OOP é substituir isso:

fun($data, $arg1, $arg2);

Por isso:

$data->method($arg1, $arg2);

Ou seja, combinar dados e comportamentos em objetos que se comunicam entre si. Uma forma bacana de compreender OOP é estudá-la nas linguagens que originaram o paradigma (Simula 67, Smalltalk-80, Self).

 

Agora, se vale a pena ou não, só você pode dizer. Para mim vale.

[raonibs 64]

Se você colocar as funções do dataUtil.php em uma classe você estaria igualmente violando SRP.

Os includes podem ser muitos tanto em procedural quanto em OO. Resolve-se isso, em ambos os casos, com um autoload.

OO é outro paradigma de modelagem de sistemas, para quem o domina ele é mais rápido de programar mais fácil de dar manutenção e de testar e consequente mais barato e fornecendo um código de maior qualidade. O único ponto negativo é a alta curva de aprendizagem, Não é fácil fazer OO da maneira correta e se não for feito certo ela pode ser tão ruim ou até pior quanto procedural.

Para quem domina OO quando o código é realmente pequeno ( um form de contato por exemplo ) até pode valer apena ser objetivo e fazer em procedural, ou em situações onde é preciso economizar todo processamento possível como em servidores de alta demanda o procedural precisa ser considerado, fora dessas situações, e na maioria dos casos mesmo nelas, o melhor é sempre usar orientação ao objeto.

Existe também uma corrente de criticas fortes ao paradigma orientado ao objeto feito por desenvolvedores experientes e que não pode ser ignorada. Apesar de eu ser 100% a favor de OO vou deixar aqui para fazer um contraponto, é importante salientar que alguns dos sujeitos abaixo estão muito além do procedural e OO e de nós simples programadores mortais.

 

Citação

 

"O problema com linguagens orientadas a objetos é que eles têm todo esse ambiente implícito que eles carregam com eles. Você queria uma banana, mas o que você conseguiu foi um gorila segurando a banana e toda a selva. " - Joe Armstrong

 

Obs.: Todo conteúdo abaixo em inglês

Artigo - Bad Engineering Properties of Object-Oriented Languages

Entrevista - An Interview with A. Stepanov

 

Artigo - Why Arc Isn't Especially Object-Oriented

 

Artigo - Execution in the Kingdom of Nouns

 

Vídeo - Are We There Yet?

[CleitonGarcia 31]

Exatamente. Exatamente!

 

O problema com linguagens orientadas a objetos é que eles têm todo esse ambiente implícito que eles carregam com eles. Você queria uma banana, mas o que você conseguiu foi um gorila segurando a banana e toda a selva

 

Tudo depende da ocasião, circunstâncias em que o indíviduo está. Imaginar o futuro não é ruim... Em um exemplo, você cria um formulário mas com já intenções de melhora-lo, vá de OO porque aí você pode preparar a casa para futuras manutenções corretivas e/ou evolutivas.

 

Mas essa questão de OO é igual duscutir qual framework usar... ambos são funcionais e ambos possuem os dois lados da moeda, vai da sua necessidade e prioridade. Nenhum é melhor que outro, é claro que no caso de discutir OO, ele é a evolução portanto é melhor, isso é fato, no entanto,s mesmo assim ainda há dois lados da moeda.

 

Quem decide oque é melhor, oque será melhor, oque será mais prático, etc. É você mesmo! O máximo que será obtido da opinião de outros, é.. ou a análise de porque esse é melhor do que aquele (tipica discusão newbie - talvez pra esse individuo realmente seja melhor, mas para ele, pra você outra coisa pode ser melhor.) ou então as vantagens e desvantagens de cada um, seja framework, linguagem, metodologia, ou até a forma de montagem de um algoritmo.

 

Porque todos nós sabemos que nossa área tudo é possível e temos dezenas de formas de concluir um objetivo.

 

Portanto cabe a cada um escolher oque é mais adepto, analisando prioridades, necessidades, desejos, etc.

[marcelobbt 7]

Obrigado a todos que contribuíram para esta tempestade de ideias. Clareou bastante minha mente e agora posso seguir feliz programando em OO e ver que se achar melhor, posso fazer parte do programa sem OO. :yes: