Usando OOP em temas

36

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?

themes php oop onetrickpony
fonte
5
@ Ameba Ambitious - Você pode explicar por que acredita que o uso de classes para plugins para minimizar colisões de namespace é ridículo? Quanto aos temas, talvez também fosse útil se você desse exemplos do que considera um bom código nos temas e do que considera desnecessário. Não é provável que discutir isso em abstrato tenha uma visão para você ou para os outros, especialmente aqueles que não estão familiarizados com o que você está se referindo.
MikeSchinkel
1
Uso aulas sempre que posso, pessoalmente, é muito mais fácil manter, atualizar e reutilizar. Preferência pessoal à parte, que boas razões existem para usar uma classe?
T31os
1
Estranho, acabei de perder meu comentário original (bug do SE, talvez?) .. Eu vou repetir, porém, que boas razões existem para não usar uma classe?
t31os 22/12
2
@ MikeSchinkel: você pode fazer isso anexando um prefixo ao nome da função. Eu não acho que vale a pena a sobrecarga de classe extra apenas para ter bons nomes de funções. De qualquer forma, estou curioso sobre o porquê de temas fazer isso, não que muito sobre plugins
onetrickpony
4
@ Ameba ambiciosa - Eu certamente darei que você tem direito à sua opinião, mas a minha opinião é diferente. Acredito que a clareza que as classes trazem ao código, minimizando as funções flutuantes no espaço de nomes global, vale o que acredito ser uma quantidade imensurável de sobrecarga adicional, especialmente ao usar um IDE de nível profissional como o PhpStorm. E as classes criam uma unidade independente para que o desenvolvedor possa saber qual código um módulo requer. E, finalmente, depois de evoluir meu estilo de plug-in do WordPress para usar classes, qualquer outro método me parece uma codificação desleixada.
MikeSchinkel

Respostas:

26

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).

EAMann
fonte
Não concordo com a parte "extensibilidade". Você tem o mesmo nível de controle sobre o tema pai como teria se usasse ações e suas funções típicas. Por quê? Você mesmo disse que isso não é verdade OOP. Também não concordo com o namespacing - foi por isso que iniciei esta pergunta em primeiro lugar - tente redefinir qualquer função do Hybrid em qualquer plug-in e você verá que as funções colidirão. Por que você acha que eles ainda adicionaram os prefixos? :) Você só não pode envolver todo o tema em uma classe, ele simplesmente não faz qualquer sentido ...
onetrickpony
Não estou dizendo para não usar OOP em temas, como algumas pessoas aqui podem ter entendido, pelo contrário (consulte 2.8 widgets para, por exemplo, caminhantes etc.), mas não assim.
Onetrickpony
1
Parece que você tem um problema com a implementação específica do Hybrid, não com a prática de usar OOP em temas ou mesmo usando uma classe para namespace as funções definidas em um tema. Eu estava tentando responder suas perguntas mais amplas sobre re: por que fazer isso? e re: quais são as vantagens de fazer isso? Não vou dedicar tempo a defender o que parece ser uma implementação sem entusiasmo ou a argumentar contra sua óbvia animosidade em relação à estrutura de uma estrutura de tema específica. Resumindo, se você não gosta da maneira como o Hybrid é construído, use outra coisa.
EAMann
1
de jeito nenhum, eu gosto de Hybrid (mas não da classe, é claro). A Hybrid me inspirou a criar minha própria estrutura de temas. Tomemos outro exemplo, Suffusion, mesmo tipo de prática. Novamente, os namespaces nesse caso não funcionam com temas, todas as funções da classe wrapper sempre entrarão em conflito com os plug-ins, porque os plug-ins são carregados pelos temas "dentro" do WP.
Onetrickpony
1
Justo. Apenas lembre-se de que a maioria do trabalho do WP não é OOP (já que o WP não é), mas colocar métodos de tema em uma classe para imitar como é feito em um plug-in é pelo menos um passo à direita direção ... mesmo que seja uma classe semi-concebida e mal implementada. Definitivamente, concordo que apenas agrupar tudo em uma classe e chamar as coisas processualmente é um pouco estranho (e não é útil pelo ponto de vista de um desenvolvedor de terceiros que tenta usar o sistema). Mas, se feito corretamente (e no Hybrid aparentemente não), classificar seu código functions.phppode ser muito poderoso.
EAMann
29

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
fuxia
fonte
1
Alguma chance de obter suas aulas de 'tema'? Quero escrever o meu próprio e gostaria de saber como você faz.
Horttcore
1
Ainda não decidi isso. Talvez eu esteja desenvolvendo um novo tema básico junto com o @bueltge no próximo ano, que usa algumas dessas classes. Muito provavelmente não antes de março, receio.
fuxia
5
Especialmente para seus casos, temas e estruturas gratuitos, OOP é o caminho a percorrer. Outras pessoas precisam trabalhar com esses códigos. Os autores devem tornar esse processo o mais fácil e flexível possível. Substituir uma classe é mais fácil do que substituir 20 funções, porque uma classe bem escrita possui uma API claramente definida.
fuxia
2
Não posso dizer nada sobre o híbrido; Eu nunca usei. Mas sim, um controlador que organiza tudo por trás das cortinas, oferece bons filtros e insere algum padrão MVC na bagunça usual do tema - é uma coisa boa. Não confie em mim. Tente. :)
fuxia
3
Chegou a hora, o WordPress precisa de um tema OOP para desenvolvedores; Espero que possamos encontrar tempo para trabalhar para o nosso objetivo. Este pequeno trecho aqui e os benefícios mostram as grandes possibilidades para temas de clientes; uma maneira rápida de perceber novos temas e também excelente para manutenção.
precisa saber é o seguinte
3

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.

kaiser
fonte
2

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.

Tex
fonte
1
Infelizmente, o blog está aberto apenas para usuários "convidados". Apenas mais um lembrete de por que nunca devemos postar nossas informações em um serviço gratuito e, em vez disso, hospedar nossos próprios blogs. O Facebook é praticamente o mesmo a esse respeito. Um link de recurso atualizado seria bom. FWIW Eu vi o lado sombrio do OOP e nunca o utilizarei novamente, a menos que seja absolutamente necessário dentro do contexto, pois as funções de ordem superior geralmente podem ampliar a funcionalidade e ajudar a reduzir o clichê e o uso indevido da classpalavra - chave.
Josh Habdas
2

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.

Jester831
fonte
-4

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" ...

Marca
fonte
10
Esta pergunta não está reclamando do código, está pedindo uma explicação clara de por que o código seria escrito de uma maneira específica. Grande parte do núcleo do WP é processual, com alguns recursos mais recentes usando uma abordagem OOP. Muitos plug-ins modernos também usam o OOP para encapsular a funcionalidade. Mas a maioria dos temas não. O OP estava perguntando por que uma abordagem de pseudo-POO seria usada e deu o híbrido como exemplo. Você não está respondendo à pergunta, está reclamando.
EAMann