WordPress-laajennusten rakentajien ei pitäisi määritellä koukkuja

WordPress-laajennusten rakentajat näyttävät olevan yhä enemmän keskustelunaiheena, kun on kyse siitä, mitä niiden pitäisi määritellä. Olen puhunut siitä ennenkin, mutta on okei palata tähän aiheeseen aika ajoin, eikö niin?

Loppujen lopuksi on asioita, joita opimme ja asioita, joita muutumme, kun saamme lisää kokemusta.

Ei ole ollenkaan harvinaista nähdä liitännäisiä, jotka määrittävät koukkuja ja muuta käyttäytymistä, mutta en ole tämän lähestymistavan fani. Sen sijaan koukkurekisteröinnin käsittelyn pitäisi mielestäni tapahtua omassa funktiossaan tai, vielä rajummin, ryhmien joukossa.

Mutta ennen kuin menen siihen, haluan selittää, mitä WordPress-laajennusten rakentajassa pitäisi mennä, miksi sen pitäisi mennä konstruktoriin ja kuinka tämä voidaan käsitellä laajennuksiasi käsiteltäessä.

WordPress-laajennusten rakentajat

Alusta alkaen olen sitä mieltä, että rakentajia tulisi käyttää yhteen asiaan:

• Objektin tilan alustaminen.

Se, mikä määrittää objektin alkutilan, saattaa riippua siitä, onko se luotu "tyhjästä" vai ladataanko siihen tietoja aiemmasta sarjasta (kuten istunnon sarjoittaminen). Tapa, jolla näen sen:

• attribuutit ovat substantiivit, jotka kuvaavat objektia,
• Funktiot ovat verbejä, jotka kuvaavat, mitä objekti voi tehdä.

Toiminnot tekevät tietysti sen työn, jonka objekti pystyy tekemään. Ne voivat muuttaa objektin tilaa kutsuttaessa, tai ne voivat käsitellä funktioihin välitettyjä argumentteja.

Mitä konstruktorissa pitäisi mennä?

Kun objektia rakennetaan, se tulee yksinkertaisesti asettaa siten, että sen attribuutit on asetettu ja sen toiminnot ovat valmiita toimimaan.

Jos konstruktorissa on jotain, joka ei vaikuta objektin alkutilaan, sen ei pitäisi olla siellä.

Miksi attribuuttien pitäisi olla konstruktorissa?

Ehkä parempi tapa esittää tämä kysymys on:

Miksi koukkuja ei saisi määritellä konstruktorissa?

WordPressin koukkujärjestelmä on osa tapahtumalähtöistä suunnittelumallia (jonka olen fani), mutta koukkujen rekisteröinti ei kuvaa objektin tilaa. Sen sijaan perustavanlaatuisimmalta tasolla se on jotain, joka luo suhteen objektiin ja WordPressiin.

Objektin alkutilan ei tarvitse tietää WordPressistä, sen toimintoja ei tarvitse olla yhdistettynä WordPressiin tai mitään käsittelyä WordPressillä.

Muista, että attribuutit alustetaan rakentajassa. WordPress ei ole attribuutti. Se on riippuvuus. Riippuvuuden luominen on toiminnan suorittamista, joka on verbin määritelmä.

Siksi kaikki koukun rekisteröinti tulisi tehdä funktiossa.

Kuinka voimme hoitaa koukun rekisteröinnin?

Tämä on yksi niistä aiheista, joka voi olla oma viesti tai viestisarja.

• WordPressillä on mahdollista luoda luokka, joka ylläpitää rekisteriä objekteista ja koukuista.
• On myös mahdollista määrittää koukun rekisteröinti luokan funktiossa.
• Voimme myös tehdä useita asioita riippuvuuden inversiolla.

Kaikki edellä mainitut ovat asioita, jotka eivät kuulu tämän viestin piiriin, mutta yksinkertaisuuden vuoksi näytän esimerkin siitä, kuinka luokka voi rekisteröidä funktionsa WordPressiin init-funktiossa :

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

Tällä tavalla voimme instantoida objektin, testata sitä, käyttää sitä jne., mutta meidän ei tarvitse käsitellä mitään WordPressiin liittyvää kutsumatta nimenomaisesti init – funktiota.

Kun sitä kutsutaan, riippuvuus luodaan, WordPress tarvitaan ja asiat muuttuvat monimutkaisemmiksi.

Ja se testausjuttu

Haluan mainita vielä yhden seikan, joka on hieman tämän postauksen laajuuden ja tarkoituksen ulkopuolella, mutta on silti ajankohtainen: Kun on kyse luokan testaamisesta, meidän pitäisi pystyä:

1. luo luokasta ilmentymä,
2. testata sen logiikkaa kutsumalla toimintoja,
3. sen parametrien välittäminen ja sen palautusarvojen arvioiminen.

Ja meidän pitäisi pystyä tekemään tästä mahdollisimman paljon eristyksissä. Jos koukut määritellään rakentajassa, se luo välittömän riippuvuuden WordPressistä, jota ei pitäisi tarvita.

WordPress ei kuvaa objektin tilaa. Se on riippuvuutta kohteesta.

Joka tapauksessa yritän sanoa, että WordPress-laajennusten rakentajien ei pitäisi käsitellä koukkujen rekisteröintiä, koska koukut eivät kuvaa sen tilaa. Ne liittyvät johonkin, jota luokka tekee, ja ne estävät meitä pystymästä testaamaan objektia eristyksissä.

Joten niillä on paikkansa, mutta se ei ole rakentajassa.