Melhor para disparar ganchos específicos ou ganchos genéricos com parâmetros?

O método 1 é muito mais robusto e extensível, na minha opinião.

Método 1: Para adicionar ou remover formulários ou outras funcionalidades, basta adicionar ou remover funções. Em particular, você pode fazer isso de outros arquivos, como módulos separados do seu plugin ou outros plugins externos. Eu acho que este é o principal argumento a seu favor: extensibilidade e modularidade.

Método 2: Para adicionar ou remover formulários ou outras funcionalidades, você precisa modificar uma função existente, que é muito mais propensa a erros. Uma instrução switch como a do método 2 fica fora de controle facilmente. A lista de casos pode ficar muito longa e é fácil introduzir bugs assim que você tiver vários filtros com o mesmo tipo de comando switch. Por exemplo, você pode querer filtros para validação, exibição de formulários vazios a serem preenchidos, exibição do conteúdo de formulários preenchidos, gerenciamento de banco de dados, ... Então agora você tem um monte de funções, cada uma com uma lista muito longa de casos de troca. , que você precisa manter em sincronia.

(Eu tive uma experiência ruim disso com uma extensão popular para formas gravitacionais - não é incontrolável se você é disciplinado, por exemplo, mantenha a lista de casos na mesma ordem em todas as funções, mas também não é bonita.)

Localizando bugs: Muito mais fácil com o Método 1: o culpado normalmente será o filtro ou formulário recém-adicionado, em vez de algum tipo de digitação inadvertidamente introduzido nessa longa função do Método 2.

Exemplos: você encontrará vários exemplos do Método 1 no núcleo do wordpress (por exemplo, enlace ), mas não me lembro de uma única instância do Método 2.

Torne o nome do hook específico para o que ele faz, não onde ele é chamado. Não passe vários parâmetros, porque isso não é fácil de estender. Em vez disso, passe um objeto de parâmetro.

Exemplo

Crie o objeto de parâmetro com uma interface para injeção de dependência:

interface Validation_Parameters {

    public function id();

    public function errors();

    // not a good name …
    public function details();
}

class Form_Validation_Parameters implements Validation_Parameters {

    private $id;

    private $errors;

    private $details;

    public function __construct( $id, $errors, $details ) {

        $this->id      = $id;
        $this->errors  = $errors;
        $this->details = $details;
    }

    public function id() {
        return $this->id;
    }

    public function errors() {
        return $this->errors;
    }

    public function details() {
        return $this->details;
    }
}

$params = new Form_Validation_Parameters( 
    'contact',
    new WP_Error(), // should be prepared better.
    [ 'request' => $_SERVER['REQUEST_URI'] ]
);

Agora passe no seu filtro:

$valid = apply_filters( 'form_is_valid', TRUE, $params );

Um desenvolvedor de terceiros pode lê-lo agora, mas não alterá-lo, para que os outros possam confiar em sua estrutura, porque não há como corrompê-lo.

add_filter( 'form_is_valid', function( $bool, Validation_Parameters $params ) {
    // do something and return a value
});