Usando OOP em temas

Eu vejo muitos plugins usando codificação orientada a objetos quando não é realmente necessário.

Mas o pior é que os desenvolvedores de temas estão começando a fazer a mesma coisa. Temas comerciais e temas populares gratuitos, como Suffusion, até o meu tema favorito - Hybrid, enchem todas as funções dentro de uma classe, instanciam uma vez no functions.php e executam suas funções de maneira processual :)

Wtf? Qual o sentido de fazer isso? Obviamente, você não usará duas ou mais instâncias do mesmo tema, ao mesmo tempo.

Vamos supor que os plug-ins façam isso no namespace (o que é ridículo), mas qual é a desculpa do tema? Estou esquecendo de algo?

Qual é a vantagem de codificar um tema como este?

Eu posso entender sua confusão com base no exemplo que você forneceu. Essa é realmente uma maneira ruim de usar uma classe ... e apenas porque uma classe é usada, não torna o sistema OOP.

No caso do Hybrid, eles estão apenas usando uma classe para nomear suas funções. Considerando que o híbrido é uma estrutura de tema , isso é feito para que os temas filhos possam reutilizar os nomes das funções sem que o desenvolvedor precise se preocupar com a colisão de nomes. Em muitos casos, uma estrutura de temas (tema principal) é tão complexa que muitos desenvolvedores de temas filhos nunca entenderão exatamente o que acontece.

Se o Hybrid não usasse uma estrutura de classe, os desenvolvedores de temas filhos precisariam saber quais eram todas as chamadas de função existentes para evitar a reutilização de nomes. E sim, você pode apenas prefixar todas as suas funções com uma lesma exclusiva, mas isso dificulta a leitura, a manutenção e o inerentemente não reutilizável, caso você desenvolva outros sistemas que desejam usar a mesma funcionalidade.

Para responder às suas perguntas

Wtf? Qual o sentido de fazer isso? Obviamente, você não usará duas ou mais instâncias do mesmo tema, ao mesmo tempo.

Não, você não usará duas ou mais instâncias do mesmo tema. Mas, como eu disse, pense na estrutura de classes nesse caso como namespacing de funções, não criando uma instância de objeto tradicional. Agrupar tudo em uma classe e instanciar para chamar métodos ( myClass->method();) ou chamar métodos diretamente ( myClass::method();) é uma maneira muito clara de nomear as coisas de maneira legível e reutilizável.

É claro que você sempre pode usar algo como isso myClass_method();, mas se quiser reutilizar esse código em outro tema, em um plug-in ou em outra estrutura, precisará voltar e alterar todos os seus prefixos. Manter tudo em uma classe é mais limpo e permite que você se desenvolva e reimplemente muito mais rapidamente.

Vamos supor que os plug-ins façam isso no namespace (o que é ridículo), mas qual é a desculpa do tema? Estou esquecendo de algo?

Na maioria das situações, eu concordo com você. No entanto, essa maioria está diminuindo rapidamente. Eu hospedo vários sites em uma instalação MultiSite que usam variações do mesmo tema. Em vez de recriar o mesmo tema repetidamente com pequenas diferenças, tenho uma única "classe" para o tema pai e todos os temas filhos estendem essa classe. Isso me permite definir a funcionalidade personalizada para cada site, mantendo um senso geral de uniformidade em toda a rede.

Por um lado, os desenvolvedores de temas podem escolher uma abordagem baseada em classe para namespace de suas funcionalidades (o que não é ridículo se você trabalha em um ambiente em que reutiliza partes do mesmo código repetidamente). Por outro lado, os desenvolvedores de temas podem escolher uma abordagem baseada em classe para facilitar a extensibilidade por temas filhos.

Qual é a vantagem de codificar um tema como este?

Se você estiver usando apenas o híbrido em seu site, há pouco para saber a vantagem para você como usuário final. Se você estiver criando um tema filho para o Hybrid, há vantagens no espaçamento de nomes e na extensibilidade. Se você trabalha para o ThemeHybrid , a vantagem está na reutilização rápida e eficiente de código nos outros projetos (Prototype, Leviathan, etc.).

E se você é um desenvolvedor de temas que gosta de um recurso específico do Hybrid, mas não de todo o tema, a vantagem está na reutilização rápida e eficiente do código no seu projeto não-Hybrid (supondo que também seja GPL).

Rapidez

Meu tema base atual tem 13 classes. Quando crio um novo tema, eu uso essas classes como elas são ou as estendo. Esse sistema torna o processo de construção de um novo tema muito, muito rápido.

Escopos apertados

Eu raramente preciso de variáveis ​​globais, porque tudo o que meu código precisa saber está oculto nos membros da classe. Portanto, sou capaz de compartilhar uma variável entre dois filtros ou ações muito diferentes sem o risco de colisão com plug-ins mal escritos.

Manutenção

Cada classe é um arquivo. Se eu precisar atualizar o tema de um cliente, atualizo alguns arquivos. Tudo o que acontece dentro das classes depende de mim, desde que eu ofereça a mesma API.

Um exemplo: acima da comment_form();chamada, eu uso uma ação simples:

do_action( 'load_comment_class' );
comment_form();

Qual classe de comentário será carregada decide meu controlador. O que exatamente acontece dentro da classe de comentários decide a classe individual.

Tente isso com uma abordagem processual pura e você ficará maluco. :)

Legibilidade

É muito mais fácil reler e entender seu próprio código alguns meses depois, se você tiver separado tudo por sua tarefa.

Alguns exemplos para hierarquias de classe úteis

• Meta_Box-> prorrogado por Shortdesc_Meta_Boxe Simple_Checkbox_Meta_Box-> prorrogado porSidebar_Switch
• User_Profile_Addon-> prorrogado por User_Profile_Checkbox(ver pergunta 3255 )
• Comment_Form -> prorrogado por {$theme_name}_Comment_Form

Outro ponto a considerar: Velocidade.

if ( !class_exists('cccYourClassName') )  
// VERSUS  
if ( !function_exists('ccc_your_function_name') )

Após uma breve olhada / impressão, encontrei ~ 1.700 funções internas e ~ 1.400 funções de usuário = ~ 3.100 / 3.200 funções VS. ~ 250 aulas. Acho que isso diz mais sobre o quanto uma consulta seria necessária. Se você precisar de !function_exists('')cerca de 50 a 100 funções no seu tema ... basta definir um cronômetro para um e começar a fazer algumas contas. Mesmo que não seja OOP, é uma boa maneira de criar código

1) reutilizável
2) sustentável
3) trocável
4) um pouco mais rápido

Quando você dá uma olhada nas diferentes classes flutuando na Web que o ajudam a criar meta boxes, widgets etc. rapidamente, é bom usar um controlador como o @toscho mencionado, porque você pode simplesmente conectar e excluir classes e substituir algumas linhas no controlador que lida com suas classes.

Alguns argumentam que o encapsulamento é o único benefício (ou pelo menos primário) que o OOP oferece, e que a herança e o estado estão entre o chato e o mal:

http://obiecte.blogspot.com/2008/09/oop-sucks.html

O autor está falando mais sobre o uso de classes / objetos como estruturas do que como contêineres para funções estáticas, mas é interessante ler uma opinião completamente diferente sobre a questão, de alguém que está diretamente fora do campo de OOP.

Posso escrever meu próximo WordPress Plugin em Haskell.

Oh, bastante a discussão! Também tenho que admitir que uso classes para encapsulamento com mais frequência do que nunca. A ideia aqui é que, em meus plugins, eu posso agrupar minhas funções em uma classe e, dentro dessa classe, usar nomes de métodos muito simples e significativos que são genéricos, mesmo entre outros plugins que eu escrevo. Nesse caso, as classes substituem os espaços para nome, os quais sou forçado a evitar nos ambientes 5.2.x.

Embora haja poucas instâncias em que o OOP seja útil para modularidade, o simples ato de agrupar suas funções também cria o bônus adicional de extensibilidade de plug-in cruzado. Por exemplo, estendi recentemente uma solução de faturamento baseada em classe e, como tal, pude estender a classe principal, adicionar código extra a várias funções (w / parent :: calls) ou até mesmo substituir funções, tudo sem internalizar o plug-in estendido.

No entanto, o agrupamento de classes na maior parte é apenas um substituto para os espaços para nome.

Para que reclamar do código que você não escreveu?

Se você não gosta do código, escreva o seu!

Simples. Problema resolvido.

Programadores gostam de fazer as coisas do seu jeito. Portanto, não presuma que você possa dizer a eles como escrever código, que tipo de uísque beber, que marca de cigarro fumar ou que religião seguir. Eles apenas depuram essa diatribe e continuam fazendo o que querem. ;-)

Código não é poesia. Code é uma variação da música de Sinatra "My Way" ...