WordPress Plugin-konstruktörer borde inte definiera krokar

WordPress plugin konstruktörer verkar vara mer och mer ett ämne för debatt när det kommer till vad de ska definiera. Jag har pratat om det förut men det är okej att återkomma till ett sådant här ämne då och då, eller hur?

Det finns trots allt saker vi lär oss och saker som vi förändrar när vi får mer erfarenhet.

Det är inte alls ovanligt att se plugins som definierar hooks och annat beteende, men jag är inte ett fan av detta tillvägagångssätt. Istället tycker jag att hantering av krokregistrering bör ske i sin egen funktion eller, ännu mer drastiskt, hanteras av en uppsättning klasser.

Men innan jag går in på det vill jag förklara vad som ska ingå i en WordPress-pluginkonstruktör, varför den ska gå i en konstruktor och hur detta kan hanteras när du arbetar med dina plugins.

WordPress plugin-konstruktörer

Från början tycker jag att konstruktörer ska användas till en sak:

• Initiera tillståndet för ett objekt.

Vad som definierar ett objekts initiala tillstånd kan bero på om det har skapats "från grunden" eller om det laddas med information från en tidigare uppsättning (som en session som serialiseras). Så här ser jag det:

• attribut är substantiv som beskriver ett objekt,
• funktioner är verb som beskriver vad objektet kan göra.

Funktionerna gör naturligtvis det arbete som objektet kan göra. De kan ändra objektets tillstånd när de anropas, eller de kan arbeta med argumenten som skickas till funktionerna.

Vad ska gå i en konstruktör?

När ett objekt är konstruerat bör det helt enkelt ställas in på ett sådant sätt att dess attribut är inställda och dess funktioner är redo att utföra arbete.

Om det finns något i konstruktorn som inte påverkar ett objekts initiala tillstånd bör det inte finnas där.

Varför ska attribut finnas i en konstruktör?

Kanske ett bättre sätt att ställa den här frågan är:

Varför ska inte krokar definieras i konstruktorn?

WordPress kroksystem är en del av det händelsedrivna designmönstret (som jag är ett fan av), men att registrera krokar beskriver inte objektets tillstånd. Istället, på den mest grundläggande nivån, är det något som skapar en relation med objektet och WordPress.

Objektets initiala tillstånd behöver inte känna till WordPress, ha någon av dess funktioner inställda för att kopplas till WordPress, eller behöver göra någon bearbetning med WordPress.

Kom ihåg att attribut initieras i en konstruktor. WordPress är inte ett attribut. Det är ett beroende. Att skapa ett beroende är att vidta en handling som är definitionen av ett verb.

Alltså ska all krokregistrering göras i en funktion.

Hur kan vi hantera krokregistrering?

Det här är ett av de ämnen som kan vara ett inlägg eller en serie inlägg i sig.

• Det är möjligt att skapa en klass som upprätthåller ett register över objekt och krokar med WordPress.
• Det är också möjligt att definiera krokregistrering inom en funktion i klassen.
• Vi kan också göra ett antal saker med beroendeinversion.

Alla ovanstående är saker som ligger utanför ramen för detta inlägg men för enkelhetens skull ska jag visa ett exempel på hur en klass kan registrera sina funktioner med WordPress i en init-funktion :

<?php

namespace AcmeAdmin;
use AcmeAdminInterfaces;

class JavaScript_Assets implements InterfacesAsset {

    private $assets_dir;

    private $js_dir;

    public function __construct() {

        $this->assets_dir = trailingslashit(
            plugin_dir_url( __FILE__ ). 'assets'
        );

        $this->js_dir = trailingslashit( $this->assets_dir. 'js' );
    }

    public function init() {

        add_action(
            'admin_enqueue_scripts',
            array( $this, 'enqueue') );
    }

    public function enqueue() {

        wp_enqueue_script(
            'toggle-admin-notices',
            $this->js_dir. 'admin.js',
            array( 'jquery' ),
            false
        );
    }
}

På så sätt kan vi instansiera objektet, testa det, använda det etc., men vi behöver inte ta itu med något som har med WordPress att göra utan att uttryckligen anropa init- funktionen.

När det väl kallas skapas beroendet, WordPress behövs och saker och ting blir mer komplicerade.

Åh, och den där testa saken

Jag vill nämna ytterligare en punkt som ligger lite utanför räckvidden och poängen med det här inlägget men som fortfarande är relevant: När det kommer till att testa en klass bör vi kunna:

1. skapa en instans av klassen,
2. testa dess logik genom att anropa funktioner,
3. skickar parametrarna och utvärderar dess returvärden.

Och vi borde kunna göra så mycket av detta som möjligt isolerat. Om krokar är definierade i konstruktorn skapar det ett omedelbart beroende av WordPress som inte borde behövas.

WordPress beskriver inte tillståndet för ett objekt. Det är ett beroende av objektet.

Hur som helst, poängen jag försöker göra är att WordPress-pluginkonstruktörer inte ska hantera registreringen av krokar eftersom krokar inte beskriver dess tillstånd. De är relaterade till något klassen gör och de hindrar oss från att kunna testa ett objekt isolerat.

Så de har sin plats, men den finns inte i konstruktören.