Usando OOP em temas

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

No caso do Hybrid, eles estão usando apenas uma classe para definir o namespace de suas funções. Considerando que o Hybrid é um tema framework , 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 tema (tema pai) é tão complexa, muitos desenvolvedores de tema filho nunca entenderão exatamente o que acontece sob o capô.

Se o Hybrid não usasse uma estrutura de classe, os desenvolvedores de tema filho precisariam saber quais eram todas as chamadas de função existentes para que pudessem evitar a reutilização de nomes. E sim, você poderia prefixar todas as suas funções com um slug exclusivo, mas isso torna o código difícil de ler, difícil de manter e inerentemente não reutilizável se você desenvolver outros sistemas que desejem usar a mesma funcionalidade. / p>

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 das funções, não criando uma instância de objeto tradicional. Agrupar tudo em uma classe e instanciá-lo para chamar métodos ( myClass->method(); ) ou chamar métodos diretamente ( myClass::method(); ) é uma maneira muito clara de classificar as coisas de maneira legível e reutilizável.

Claro que você sempre pode usar algo como myClass_method(); , mas se você quiser reutilizar qualquer um desses códigos em outro tema, em um plug-in ou em outra estrutura, você terá que voltar e mudar todos os seus prefixos. Manter tudo em uma classe é mais limpo e permite que você desenvolva e reimplante muito mais rapidamente.

  

Vamos supor que os plugins façam isso pelo namespace (o que é ridículo), mas qual é a desculpa do tema? Estou faltando alguma coisa?

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 usa variações do mesmo tema. Em vez de recriar o mesmo tema repetidas vezes com pequenas diferenças, tenho uma única "classe" para o tema pai e todos os temas filhos estendem essa classe. Isso permite que eu defina a funcionalidade personalizada para cada site e, ao mesmo tempo, mantenha um senso geral de uniformidade em toda a rede.

Por um lado, os desenvolvedores de temas podem escolher uma abordagem baseada em classes para definir o namespace de sua funcionalidade (o que não é ridículo se você trabalha em um ambiente onde você reutiliza partes do mesmo código várias vezes). 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 Hybrid em seu site, há pouco a saber sobre a vantagem para você como usuário final. Se você está criando um tema filho para o Hybrid, há vantagens de namespacing e extensibilidade. Se você trabalha para ThemeHybrid , a vantagem está na reutilização rápida e eficiente de códigos em seus outros projetos (Protótipo, Leviatã, etc.).

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

Velocidade

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

Escopos apertados

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

Manutenção

Cada classe é um arquivo. Se preciso atualizar o tema de um cliente, apenas atualizo alguns arquivos. O que quer que aconteça dentro das aulas, depende de mim, desde que eu ofereça a mesma API.

Um exemplo: acima da chamada comment_form(); , 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ário decide a classe individual.

Tente isso com uma abordagem processual pura e você vai enlouquecer. :)

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 de hierarquias de classes úteis

• Meta_Box - > estendido por Shortdesc_Meta_Box e Simple_Checkbox_Meta_Box - > estendido por Sidebar_Switch
• User_Profile_Addon - > estendido por User_Profile_Checkbox (consulte Question 3255 )
• Comment_Form - > estendido por {$theme_name}_Comment_Form

Outro ponto a considerar: velocidade.

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

Após um breve olhar / impressão, encontrei ~ 1.700 funções internas e ~ 1.400 funções do usuário = ~ 3.100 / 3.200 funções VS. ~ 250 aulas. Eu acho que isso diz mais sobre o quanto um look up precisaria. Se você chamar !function_exists('') em cerca de 50-100 funções no seu tema ... basta definir um temporizador para um e, em seguida, começar a fazer algumas contas. Mesmo que não seja OOP, é uma boa maneira de fazer código

1) reutilizável
2) mantenível
3) trocável
4) pouco mais rápido

Quando você dá uma olhada nas diferentes classes que navegam na web que o ajudam a fazer meta box, widgets, etc. rapidamente, então é bom usar um controlador como @toscho mencionado, porque você pode simplesmente ligar classes e e apenas substitua algumas linhas no controlador que lida com suas classes.

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

enlace

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

Eu posso escrever meu próximo plugin WordPress em Haskell.

Oh bem a discussão! Eu tenho que admitir também que eu uso classes para encapsulamento muito mais frequentemente do que não. A ideia aqui é que nos meus plugins eu posso envolver 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 escrevo. Nesse caso, as classes são um substituto para namespaces, que eu sou forçado a evitar em ambientes 5.2.x.

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

No entanto, o envolvimento de classes na maioria das vezes é apenas um substituto para namespaces.

Qual é o ponto de reclamar sobre o 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 coisas do jeito deles. Portanto, não presuma que você pode dizer-lhes como escrever código, que tipo de uísque beber, que marca de cigarro fumar ou que religião seguir. Eles só vão depurar tal diatribe e continuar fazendo o que querem. ;-)

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