Por que usar PHP OOP sobre funções básicas e quando?

Existem algumas postagens sobre esse assunto, mas não entendi claramente quando usar codificação orientada a objects e quando usar funções programáticas em um include. Alguém também me mencionou que o OOP é muito pesado para correr e faz mais carga de trabalho. Isto está certo?

Digamos que eu tenho um grande arquivo com 50 funções. Por que vou querer chamar isso em uma class? E não por function_name ()? Devo mudar e criar um object que contenha todas as minhas funções? Qual será a vantagem ou diferença específica? Quais os benefícios que traz para o código OOP em PHP? Modularidade?

Em muitos cenários, a programação processual está bem. Usar o OO por causa do uso é inútil, especialmente se você acabou por acabar com objects POD (dados simples).

O poder da OO vem principalmente da inheritance e do polymorphism. Se você usa aulas, mas nunca usa nenhum desses dois conceitos, você provavelmente não precisará usar uma class em primeiro lugar.

Um dos lugares mais bonitos da OMI que a OO brilha, está permitindo que você se livre do código de troca de tipo. Considerar:

function drive($the_car){ switch($the_car){ case 'ferrari': $all_cars->run_ferrari_code(); break; case 'mazerati': $all_cars->run_mazerati_code(); break; case 'bentley': $all_cars->run_bentley_code(); break; } } 

com sua alternativa OO:

 function drive($the_car){ $the_car->drive(); } 

O polymorphism permitirá que o tipo apropriado de “condução” aconteça, com base em informações de tempo de execução.


Notas sobre o polymorphism:

O segundo exemplo aqui tem algumas premissas: isto é, todas as classs de carros irão estender uma class abstrata ou implementar uma interface .

Ambos permitem que você force a extensão ou implementação de classs para definir uma function específica, como drive() . Isso é muito poderoso, pois permite que você drive() todos os carros sem ter que saber qual você está dirigindo; Isso é porque eles estão estendendo uma class abstrata contendo o método drive() ou implementando uma interface forçando o método drive() a ser definido.

Então, enquanto você se certificar de que todos os seus carros específicos estendam o car class abstrata ou implemente uma interface como o canBeDriven (ambos devem declarar o método drive() ), você pode simplesmente chamar o método drive() em um object que Você sabe que é um carro (mas não que tipo de carro) sem medo de não ser definido, pois o PHP lançará erros fatais para você até que você defina esses methods em suas classs específicas de carros.

Usar uma abordagem de programação orientada a objects ao invés de uma abordagem de programação processual em um programa na verdade não depende do idioma (seja PHP ou não), mas sobre o tipo de problema que você está tentando resolver.

(Eu só vou usar o pseudocódigo em meus exemplos, pois não estou familiarizado com o PHP).

Por exemplo, se você tem um programa onde você está apenas executando um conjunto de funções em ordem, então o processo será bem. Por exemplo, se é um simples programa de manipulação de cordas, uma abordagem processual seria suficiente:

 perform_truncation(my_string, 10) to_upper(my_string) perform_magic(my_string, hat, rabbit) 

No entanto, se você estiver lidando com muitos itens diferentes (como arquivos ou qualquer outra representação de, bem, objects), uma abordagem orientada a objects seria melhor.

Por exemplo, se você tivesse um monte de Car e queria que eles drive , então, em procedimentos, você pode fazer algo ao longo da linha de:

 drive_car(first_car) drive_car(second_car) 

Onde, no OOP, o Car pode dirigir-se:

 RedCar myRedCar(); BlueCar myBlueCar(); myRedCar.drive(); myBlueCar.drive(); 

E, como cada carro é uma class diferente, seu comportamento pode ser definido de forma diferente. Além disso, eles podem ser subclasss ou Car eles podem ter funcionalidade comum.

Realmente se resume ao tipo de problema que torna a abordagem processual melhor do que orientada a objects e vice-versa.

Além da questão de procedimentos ou orientados a objects, pode ser um tipo de “cheiro de código” para ter um arquivo de origem com muitas funções. Isso também pode ser dito sobre as classs que contêm muitas funcionalidades que podem ser melhor realizadas como funções separadas em classs separadas.

O problema aqui pode ser de organização de códigos ao invés de decidir escolher programação processual ou orientada a objects. Organizar funções em arquivos de origem separados pode ser o que é necessário aqui do que abandonar a abordagem processual para escrever o programa.

Afinal, há muitos programas escritos na abordagem de programação processual que está bem escrita e fácil de manter.

Vou tentar manter minha resposta como uma adição porque as respostas de Majd Taby e Coobird são realmente boas.

Eu era principalmente um programador processual por vários anos e não lutei contra a programação OOP, mas nunca vi muita relevância … até que eu comecei a trabalhar em uma equipe e a construir projetos mais importantes e complexos.

OOP realmente brilha, na minha opinião, quando você precisa escrever um código simples e fácil de manter para aplicações mais complexas. E lembre-se de você, não em todas as situações, mas há alguns onde o procedimento apenas não funcionará tão bem.

A maioria dos meus exemplos de ótimas implementações OOP são para projetos onde eu tinha várias coisas que estavam todas relacionadas, mas todas ligeiramente diferentes. Sites com muitas formas, muitos usuários, muitos produtos etc.

Todos eles têm nomes de comportamento semelhantes, como print (), update (), etc … mas, encapsulando-os como objects e variando as implementações dos methods nas classs, posso tornar meu código em tempo de execução muito simples e limpo em todo o site. Além disso, e essa foi a chave, apesar de ter comportamentos diferentes, eu poderia trabalhar com objects diferentes usando as mesmas chamadas de método em toda a aplicação . Ele permite que um segundo desenvolvedor trabalhe na implementação real enquanto eu trabalho em um código mais profundo.

Eu não sei se isso ajuda a falar, mas falando como alguém que estava em sua situação há pouco tempo, eu adoro OOP.

Digamos que eu tenho um arquivo grande com 50 funções, por que eu quero chamar isso em uma class? e não por function_name (). Devo mudar e criar um object que contenha todas as minhas funções?

Mover-se para OOP não deve ser visto como um “switch” simples da maneira que você descreve acima.

OOP requer uma maneira completamente diferente de pensar sobre a programação, que envolve a reconexão de seu cérebro. Como a reconexão de um cérebro não acontece durante a noite, muitas pessoas não estão dispostas a expor-se ao processo de recarga requerido. Infelizmente, o rewiring vai levar um investimento em tempo e esforço: pesquisa, tutoriais, teste e erro.

Realmente envolve dar um passo atrás e aprender sobre os conceitos por trás do OOP, mas o retorno valerá a pena falar como alguém que passou por esse processo nos dias pré www.

Depois de “obtê-lo” e siga as melhores práticas de OOP em seu dia-a-dia, você estará contando aos outros como sua vida de programação mudou para melhor.

Uma vez que você realmente entenda o OOP, você terá respondido sua própria pergunta.

Se você tiver 50 funções em vez de 50 methods estáticos na class Utilities, você “polui” o namespace global.

Usando uma class com 50 methods estáticos, os nomes dos methods são locais para sua class.

Não posso dizer qual é melhor. Mas, na minha experiência, você pode ter um melhor gerenciamento de código usando o OOP. Você sabe qual código é onde, qual funcionalidade é definida em qual arquivo, etc. sobre a sobrecarga de tempo de execução para o OOP que eu ligo em algum lugar (e acho que é verdade) que se você escrever um código ruim em funções clássicas e o mesmo código ruim No OOP, a versão da function funciona melhor. então, se seu código não está escrito como ruim, não há nenhuma prova de que o OOP esteja mantendo seu aplicativo lento. Lembre-se também que esses itens “lentos” e “sobrecarga” são todos medidos em milissegundos. então, se o seu aplicativo não estiver servindo muitos usuários (como mais de 100 usuários em um minuto), você pode não sentir nenhuma diferença.

OOP permite que você crie recipientes estruturados de código, chamados de classs, que podem ser pais / filhos uns dos outros. Isso pode ajudar na construção de um aplicativo, pois é mais fácil de manter e pode, se feito, reduzir corretamente a redundância do código. O OOP adiciona um pouco sobrecarga, mas não é realmente perceptível e é superado pela falta de manutenção do código processual. Se você escreve um grande aplicativo, def go OO, especialmente se ele for trabalhado por muitas pessoas.

Por exemplo, digamos que você está projetando um site simples. Você pode criar um object de página. O object da página é responsável por ir ao database e obter várias configurações para a página, como meta-dados, tags de título ou mesmo o número de certos “componentes” na página e seu tipo (como um controle de calendar, um widget , etc.).

Então, você pode criar outra class, diga Index, que estende a página. O índice seria o índice ou página inicial. Se você tivesse um catálogo de produtos, você poderia ter uma página de extensão de class de catálogo. Uma vez que tanto a seção do catálogo como a sua página inicial precisam obter dados do database sobre os metadados da página e a construção básica da página, ter um object que já o faz para você ajuda. Em ambas as situações, a página faz todo o trabalho e obtém os dados da página do database, carrega-os em variables, que são acessíveis em sua class de índice e sua class de catálogo. Você não precisa escrever o código para entrar no database e obtê-lo novamente em cada página que você escreve.

Agora, existem outras maneiras de fazer isso de forma processual, como por exemplo, com um item incluído. No entanto, você vai encontrar-se fazendo menos erros e erros. Por exemplo, você pode definir um método abstrato na sua class de páginas. Isso significa que esse método DEVE ser definido em qualquer object que o estenda. Então, diga que você criou uma function setPageAttributes () como resumo na sua class de página. Quando você faz isso, você cria uma function vazia. Quando você cria sua class de índice, você DEVE criar uma function setPageAttributes () com a intenção de preenchê-la, como acessar as variables ​​definidas na class da página e usá-la para definir os elementos reais na página, modelo ou visualização que você está usando) ou você obtém um erro PHP.

Se você estiver trabalhando com outras pessoas para que seu projeto seja escrito, methods abstratos direcionarão a pessoa: “Ei, você precisa definir essas funções em qualquer código que você escreva”. Isso obrigou o aplicativo a ser consistente.

Finalmente, você não pode acessar frameworks como os formatos MVC se você não fizer o OOP. Embora não seja necessário ir ao MVC e há algum debate, ele separa todos os componentes da aplicação e é necessário em ambientes onde muitas pessoas (designers, codificadores, funcionários de marketing) trabalham no mesmo código.

A resposta aceita parece ter negligenciado declarar que é possível chamar funções com base em um nome de variável como no exemplo herew:

 function drive($the_car){ $the_car(); } 

É certo que precisaria de uma function para cada carro nesta instância, mas é muito mais eficiente do que a indicação de mudança sugerida.


Variáveis ​​adicionais podem ser fornecidas facilmente como tal:

 function operate($the_car,$action){ $the_car($action); } function ferrari($action){ switch($action){ case 'drive': echo 'Driving'; break; case 'stop': echo 'Stopped'; break; default: return; } } operate('ferrari','drive'); 

Há uma declaração de troca aqui, mas é fornecer funcionalidades adicionais que não estavam no exemplo original, por isso não é de modo algum uma contradição.

O conceito OOPs é usado em PHP, de modo a proteger o código. Como todas as consultas são escritas em arquivo de function em vez de arquivo de código para que ninguém possa facilmente cortar nosso código. Portanto, é melhor usar classs em PHP ao invés de escrever diretamente as consultas.