Widgets do WordPress: detectar programação orientada a objetos
Se você não leu o primeiro post desta série, eu recomendo, pois estamos começando a escrever código orientado a objetos para WordPress através do uso da API Widgets.
A série vai capturar algumas coisas:
- mostrar o esqueleto básico de um widget e por que ele é orientado a objetos,
- discutir quais coisas você deve ser capaz de perceber e por que
- atualize o Widget Boilerplate diretamente neste site primeiro e depois envie-o para o GitHub,
- construir um widget usando a API com o clichê como base para nosso trabalho.
Mas antes de fazer isso, eu quero ter certeza de que todos que estão lendo isso estão a par dos princípios básicos da programação orientada a objetos e têm tudo o que é necessário para construir uma solução orientada a objetos para WordPress.
Para isso, recomendo o seguinte:
- Dois Pilares da Programação Orientada a Objetos: Parte 1 de 2
- Dois Pilares da Programação Orientada a Objetos: Parte 2 de 2
- Aulas de Resumo, Parte 1 – Comportamento de Abstração
- Classes Abstratas, Parte 2 – Classes Abstratas e Interfaces
- O desenvolvedor independente do WordPress
Se você leu todo esse conteúdo, ótimo. Você estará bem preparado para este post e os próximos posts. Caso contrário, pode haver alguns buracos no resto do que você está prestes a ler, mas a essência do post deve ser clara o suficiente.
Qual é o negócio, exatamente?
Aqui está a coisa: Na semana passada, compartilhei um pouco de código junto com algumas informações sobre a API de Widgets. Vou revisitar isso um pouco mais neste post antes de entrarmos na parte mais intensiva de codificação por dois motivos:
- Eu quero que todos lendo isso estejam na mesma página no que se refere à escrita de código orientado a objetos (no mínimo, neste contexto),
- Reconheço que as pessoas vêm de diferentes origens e quero ter certeza de que estamos todos na mesma página o máximo possível antes de prosseguir.
Se você tem experiência em escrever código orientado a objetos, especialmente em uma capacidade avançada, isso pode parecer mais simples para você; caso contrário, espero que isso o arme com tudo o que você precisa para detectar práticas orientadas a objetos não apenas relacionadas a essa API, mas também ao ler o código de outras pessoas.
Como detectar a programação orientada a objetos
Talvez uma primeira pergunta natural seja por que precisamos ser capazes de detectar, ler ou entender a programação orientada a objetos antes de realmente escrevê-la?
Uma palavra sobre código ruim
A resposta curta para isso é esta:
Você não precisa, mas eu é útil. Se você for capaz de ler programação orientada a objetos, terá uma vantagem inicial em tirar vantagem do que ela oferece como paradigma, porque irá desenvolver as estratégias e o trabalho feito por outros em outros projetos.
Isso não significa que não vamos ler o código ruim, mas faremos o que pudermos para identificar o código ruim, identificar as áreas problemáticas e então fazer o que pudermos para evitar incorporá-lo ao nosso trabalho.
Por enquanto, porém, vamos dar uma olhada na API Widgets para ver o que podemos fazer para detectar a programação orientada a objetos.
De volta à programação orientada a objetos
No post anterior, descrevi duas coisas que indicam que a API é orientada a objetos (pelo menos até certo ponto):
- o uso da palavra-chave extends ,
- funções que devemos implementar.
A razão pela qual quero revisitar este tópico é que ele identifica duas coisas principais que fazem parte dos princípios básicos da orientação a objetos: Herança e implementação de função (que geralmente faz parte de classes abstratas ).
Uma nota antes de olharmos para o acima:
Quando você olhar para a fonte da classe WP_Widget, você notará que não existem métodos abstratos. Mas algumas das funções que devemos implementar, que mencionarei mais adiante neste post, são as principais candidatas a métodos abstratos. E vou discutir o porquê, também.
Vamos separar os tópicos acima em duas seções separadas: Herança e Abstrações.
Herança
Eu abordei herança é profundidade relativa no post anterior, então não vou detalhar o ponto aqui. Vou oferecer algumas palavras, mas estou muito mais interessado em discutir a abstração, o que farei em um momento.
Antes de ir muito longe nisso, porém, consulte o seguinte código:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Mas primeiro, podemos reconhecer que qualquer classe que implemente a API Widgets deve usar herança simplesmente por causa da palavra-chave extends.
Isso significa que há um nível de funcionalidade que vamos herdar (ou obter de graça) e há um nível de funcionalidade que devemos implementar por conta própria.
Do manual do PHP :
Por exemplo, quando você estende uma classe, a subclasse herda todos os métodos públicos e protegidos da classe pai. A menos que uma classe substitua esses métodos, eles manterão sua funcionalidade original.
Quando você herda a funcionalidade de uma classe, no entanto, você pode descobrir que é importante chamar estritamente o construtor do pai (em nossa função __construct ).
Mas isso levanta o que acredito ser um dos problemas mais importantes com herança em PHP (e toda a razão pela qual eu queria incluir esta seção): precisamos chamar o construtor pai explicitamente?
Ainda de acordo com o manual:
Os construtores pai não são chamados implicitamente se a classe filho definir um construtor. Para executar um construtor pai, é necessária uma chamada para parent::__construct() dentro do construtor filho. Se o filho não definir um construtor, então ele pode ser herdado da classe pai como um método de classe normal (se não foi declarado como privado).
Mas podemos simplificar isso. Talvez isso seja mais fácil de lembrar:
- Se nossa classe usa herança, mas não define um construtor, o construtor pai é chamado.
- Se nossa classe usa herança, mas define um construtor, a construção pai deve ser chamada explicitamente.
Ou talvez ainda mais simplesmente:
- Se nossa classe não definir um construtor, o código padrão será o construtor dos pais.
Faz sentido? Resumindo, se definirmos nossas propriedades, inicialização e código em um construtor, a primeira linha do construtor de nossa classe deve ser uma chamada para o construtor pai.
Abstração
Para ser absolutamente claro, o código-fonte da classe WP_Widget não inclui métodos abstratos. Parte disso tem a ver com como a classe é construída, parte disso tem a ver com compatibilidade com versões anteriores e recursos do PHP5.
Isso não significa que não podemos identificar quais funções podem ser marcadas como abstract. Na verdade, acho que é um caso sobre quais classes devem ser abstratas. Mas primeiro, vamos definir funções abstratas.
Ao herdar de uma classe abstrata, todos os métodos marcados como abstratos na declaração de classe do pai devem ser definidos pelo filho; além disso, esses métodos devem ser definidos com a mesma (ou menos restrita) visibilidade.
Ao olhar para a fonte do nosso widget:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Acho que é justo dizer que a função de formulário pode ser marcada como abstrata porque é exclusiva da nossa implementação. Outra maneira de pensar sobre funções abstratas do ponto de vista da programação é perguntar a si mesmo: quais funções exigirão uma funcionalidade exclusiva?
E neste caso, a função de formulário é exatamente isso porque cada widget será exclusivamente diferente em relação ao que ele renderiza. A função de widget também pode ser marcada como abstrata porque gera o conteúdo do widget. Este conteúdo é, naturalmente, baseado na funcionalidade que implementamos em nossa implementação.
Além disso, o código-fonte da própria classe WP_Widget diz:
A função WP_Widget::widget() deve ser substituída em uma subclasse.’
Este é precisamente o tipo de função que deve ser marcada como abstrata. Porque o PHP lançará um erro se uma função for marcada como abstrata e não implementada. Não precisávamos de nenhuma chamada de função die ou algo assim.
As outras funções, no entanto, não precisarão necessariamente ser marcadas como abstratas e aqui está o porquê:
- __construct chamará o construtor do pai, no nível mais básico, e isso é necessário para inicializar a classe base. Não se esqueça, porém; podemos adicionar nossas propriedades a esse método que são exclusivas de nossa classe.
- update usa a funcionalidade na classe pai para serializar informações.
Assim, ficamos com duas funções que poderiam ser marcadas como abstratas em uma iteração mais moderna da classe.
Próximo
Neste ponto, todos nós devemos estar na mesma página no que se refere ao código orientado a objetos. Pelo menos até onde podemos chegar através de uma série de postagens no blog.
A partir do próximo post, vamos voltar a escrever código.
Ou seja, vamos revisitar o WordPress Widget Boilerplate e vou refatorá-lo em seu estado atual para adotar padrões PHP mais modernos.
Vou compartilhar as mudanças que estou fazendo, as justificativas do porquê, e depois também falarei sobre o tipo de widget que vamos construir com base no clichê (e podemos fazer isso).