WordPressi pistikprogrammide konstruktorid ei tohiks konkse määratleda

Tundub, et WordPressi pistikprogrammide konstruktorid on üha enam aruteluteema selle üle, mida nad peaksid määratlema. Ma olen sellest varem rääkinud, aga see on okei, kui sellist teemat aeg-ajalt uuesti üle vaadata, eks?

Lõppude lõpuks on asju, mida me õpime, ja asju, mida me muudame, kui omandame rohkem kogemusi.

Pole sugugi haruldane näha pistikprogramme, mis määratlevad konksud ja muud käitumist, kuid ma ei ole selle lähenemisviisi fänn. Selle asemel arvan, et konksu registreerimise käsitlemine peaks toimuma oma funktsioonis või, veelgi drastilisemalt, klasside komplekti poolt.

Kuid enne sellesse laskumist tahan selgitada, mis peaks WordPressi pistikprogrammide konstruktoris käima, miks see peaks konstruktoris käima ja kuidas seda pistikprogrammidega töötades käsitleda.

WordPressi pistikprogrammide konstruktorid

Algusest peale arvan, et konstruktoreid tuleks kasutada ühe asja jaoks:

• Objekti oleku initsialiseerimine.

See, mis määrab objekti algoleku, võib sõltuda sellest, kas see on loodud "nullist" või laaditakse see eelmise komplekti teabega (nt seansi järjestamine). Kuidas ma seda näen:

• atribuudid on nimisõnad, mis kirjeldavad objekti,
• funktsioonid on tegusõnad, mis kirjeldavad, mida objekt saab teha.

Funktsioonid teevad loomulikult seda tööd, mida objekt on võimeline tegema. Nad võivad kutsumisel muuta objekti olekut või töötada funktsioonidesse edastatud argumentidega.

Mis peaks konstruktoris käima?

Kui objekt on konstrueeritud, tuleks see lihtsalt seadistada nii, et selle atribuudid on seatud ja selle funktsioonid on tööks valmis.

Kui konstruktoris on midagi, mis ei mõjuta objekti algolekut, ei tohiks see seal olla.

Miks peaksid atribuudid konstruktoris olema?

Võib-olla on parem viis selle küsimuse esitamiseks:

Miks ei võiks konstruktoris defineerida konksud?

WordPressi konksude süsteem on osa sündmustepõhisest disainimustrist (mille fänn ma olen), kuid konksude registreerimine ei kirjelda objekti olekut. Selle asemel loob see kõige fundamentaalsemal tasemel suhte objekti ja WordPressiga.

Objekti algolek ei pea teadma WordPressi kohta, ühtegi selle funktsiooni ei pea WordPressiga siduma ega WordPressiga töötlema.

Pidage meeles, et atribuudid lähtestatakse konstruktoris. WordPress ei ole atribuut. See on sõltuvus. Sõltuvuse loomine tähendab toimingu sooritamist, mis on verbi definitsioon.

Seega tuleks kogu konksu registreerimine teha funktsioonis.

Kuidas me saame konksu registreerimisega hakkama?

See on üks neist teemadest, mis võib olla postitus või postituste seeria.

• WordPressiga on võimalik luua klass, mis haldab objektide ja konksude registrit.
• Konksu registreerimist on võimalik määratleda ka klassi funktsiooni sees.
• Samuti saame sõltuvuse inversiooniga teha mitmeid asju .

Kõik ülaltoodud on asjad, mis ei kuulu selle postituse ulatusse, kuid lihtsuse huvides näitan näidet selle kohta, kuidas klass saab oma funktsioone WordPressis init-funktsioonis registreerida :

<?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
        );
    }
}

Nii saame objekti instantseerida, testida, kasutada jne, kuid me ei pea tegelema WordPressiga seonduvaga ilma init – funktsiooni selgesõnaliselt välja kutsumata.

Kui see on kutsutud, tekib sõltuvus, on vaja WordPressi ja asjad lähevad keerulisemaks.

Oh, ja see testimisasi

Ma tahan mainida veel ühte punkti, mis jääb veidi selle postituse ulatuse ja sisu väljapoole, kuid on siiski asjakohane: klassi testimisel peaksime suutma:

1. luua klassi eksemplar,
2. selle loogika testimine funktsioonide kutsumisega,
3. selle parameetrite edastamine ja selle tagastusväärtuste hindamine.

Ja me peaksime suutma seda teha nii palju kui võimalik isoleeritult. Kui konksud on konstruktoris määratletud, loob see kohese sõltuvuse WordPressist, mida ei tohiks vaja minna.

WordPress ei kirjelda objekti olekut. See on sõltuvus objektist.

Igatahes, ma üritan öelda, et WordPressi pistikprogrammide konstruktorid ei peaks tegelema konksude registreerimisega, kuna konksud ei kirjelda selle olekut. Need on seotud millegagi, mida klass teeb ja takistavad meil objekti isoleeritult testida.

Nii et neil on oma koht, kuid see pole konstruktoris.