Usando classes em vez de funções globais em functions.php


11

Em muitos temas que eu vi (incluindo o TwentyEleven) e nos exemplos que encontrei on-line, ao criar o functions.phparquivo para um tema, todas as funcionalidades são declaradas em um escopo global. Para esclarecer, é assim que um arquivo de funções típico se parece:

function my_theme_do_foo() { // ... }

function my_theme_do_bar() { // ... }

add_action( 'foo_hook', 'my_theme_do_foo' );

Parece-me que as coisas poderiam ser "encapsuladas" um pouco melhor se uma classe fosse usada:

class MyTheme {
    function do_foo() { // ... }
    function do_bar() { // ... }
}

$my_theme = new MyTheme();

add_action( 'foo_hook', array( &$my_theme, 'do_foo' ) );

As vantagens da segunda abordagem (aos meus humildes olhos):

  • Nomes de funções mais curtos
  • Acesso a variáveis ​​de instância (a maior vantagem da IMO)
  • Nenhuma função global

As desvantagens:

  • O nome da classe ainda pode causar conflitos
  • Não é tão claro "personalizar" com um tema filho (teria que estender uma classe pai)
  • A maioria dos temas não é assim, então você estaria contrariando a tendência

Provavelmente estou ignorando algumas coisas, mas estou me perguntando por que não adotar a abordagem OOP? Parece um pouco "mais limpo" para mim, se é que alguma coisa. Talvez eu esteja enganado?

Eu sou bastante novo no desenvolvimento de temas para WordPress, então me desculpe se esse é um conhecimento comum na comunidade WP :). Apenas tentando aprender por que as coisas são do jeito que são.


Você pode verificar temas em Kovshenin - wordpress.org/extend/themes/profile/kovshenin ele usa a abordagem OOP em functions.php
Mamaduka

Respostas:


9

Usar uma classe para encapsulamento é uma abordagem muito comum por vários desenvolvedores de plugins. Eu faço isso e acho mais limpo. Mas para plugins. Os temas são mais processuais por natureza.

Nós não fazemos isso para temas padrão do WordPress, porque aumenta a barreira de entrada. As funções são bastante simples. A remoção de ações vinculadas às classes pode ser difícil (e potencialmente com erros em circunstâncias específicas).

Além disso, várias funções nos temas padrão são conectáveis. Estender uma classe e substituir os métodos é muito mais complicado do que apenas definir a função. E enquanto dois aspectos diferentes do código podem substituir funções diferentes, você não pode estender dinamicamente classes. Como você apontou, a necessidade de estender uma classe pai é definitivamente uma desvantagem.

Pensei em transformar as opções de tema do Twenty Eleven em uma classe, mas nunca cheguei a isso. Esse tipo de funcionalidade separada, semelhante a um plug-in, parece ser um bom candidato ao encapsulamento.


Obrigado pela resposta, Nacin. Eu não tinha pensado na dificuldade de "desengatar" ações com as classes. Em relação às opções de encapsulamento - temos pensado a mesma coisa: github.com/jestro/struts
Andy Adams
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.