WordPress Extremo
- Como Criar um Plugin WordPress com Composer e PSR-4 – WordPress Extremo Dia 1
- Como Usar Serviços em Plugins para Código Limpo e Desacoplado – WordPress Extremo Dia 2
- Como Usar Repositórios em Plugins para Separar Lógica de Dados – WordPress Extremo Dia 3
- Injeção de Dependência Manual em Plugins WordPress – WordPress Extremo Dia 4
- Hooks Avançados no WordPress: apply_filters, do_action e boas práticas
- Criando Comandos WP-CLI Personalizados para Plugins WordPress
- Criando Blocos Personalizados com Gutenberg e React
- Estilizando Blocos Gutenberg com CSS e Classes Dinâmicas
E aí, dev! Hoje no Dia 4 da série WordPress Extremo, vou te mostrar um conceito que parece chato, mas que muda completamente o jogo quando você entende:
Injeção de Dependência – ou, como eu gosto de chamar:
“Fazendo seu código parar de criar coisas sozinho e deixar isso pra um gerente que organiza tudo.”
Vamos conversar sobre isso de forma simples, prática e sem frescura.
🤔 O que é Injeção de Dependência (DI)?
Quando um objeto precisa de outro pra funcionar, ele tem duas opções:
- Ele mesmo criar (
new OutraClasse()
) - Ou receber pronto de fora
A opção 1 é mais comum… mas acopla tudo e dificulta testes, manutenção e reuso.
A opção 2 — receber a dependência injetada — permite que você:
✅ Teste mais facilmente
✅ Troque implementações sem mexer no código que usa
✅ Centralize e gerencie seus objetos com clareza
🛠️ Exemplo real no plugin
Hoje vamos ajustar nosso HelloService
para receber o UserRepository
via construtor, em vez de instanciar direto com new
.
🔧 Estrutura atual:
HelloService.php
namespace WpArquiteturaExtrema\Services;
use WpArquiteturaExtrema\Repositories\UserRepository;
class HelloService {
public function execute() {
$repo = new UserRepository();
$editors = $repo->getEditors();
foreach ($editors as $user) {
error_log("Editor encontrado: " . $user->display_name);
}
}
}
Obs: Não preciso dizer que para o código acima funcionar, você precisa de usuários registrados como Editor, certo?
✅ Estrutura com DI (injeção manual)
HelloService.php
use WpArquiteturaExtrema\Repositories\UserRepository;
class HelloService {
protected $repo;
public function __construct(UserRepository $repo) {
$this->repo = $repo;
}
public function execute() {
$editors = $this->repo->getEditors();
// ...
}
}
Obs: repara que agora usamos o $this
para puxar.
Init.php
use WpArquiteturaExtrema\Services\HelloService;
use WpArquiteturaExtrema\Repositories\UserRepository;
class Init {
public function register() {
add_action('init', [$this, 'init_plugin']);
}
public function init_plugin() {
$repo = new UserRepository();
$service = new HelloService($repo);
$service->execute();
}
}
Obs: Repare que aqui instanciamos UserRepository com $repo
e passamos pra HelloService($repo)
.
💡 Benefícios dessa abordagem
- Testes: você pode injetar um “FakeRepository” se quiser simular dados
- Flexibilidade: você troca o repositório facilmente (ex: por um que consulta uma API)
- Organização: seu código não decide suas dependências — ele só executa
⚙️ Próximos passos
- Em breve, podemos automatizar isso com um container de injeção de dependências
- E até usar uma biblioteca como
league/container
para projetos maiores
Mas por enquanto, a injeção manual já resolve 90% dos problemas de acoplamento.
🎯 Recado final
Se você chegou até aqui, parabéns!
Você já está trabalhando com um nível que a maioria dos devs WordPress nunca nem viu. E isso te destaca demais.
💬 Curtiu? Quer mais?
Se quiser se aprofundar nisso:
- 👉 Temos mentorias e cursos
- 👉 Segue lá no IG: @wp24horas
Ou comenta aqui sua dificuldade que eu te ajudo a implementar! 🚀