Eilses postituses rääkisin WordPressi pistikprogrammi konstruktoritest ja põhjendusest, miks konksud ei tohiks konstruktoris olla.
Kuigi mainisin mitmeid viise konksude registreerimise käsitlemiseks, ei vaevunud ma iga strateegia üksikasjadesse laskuma. Minu arvates väärivad nad oma artiklit, et anda võimalikult palju üksikasjalikku teavet selle kohta, kuidas midagi seadistada.
Näiteks ütles üks meetoditest, mida jagasin:
- WordPressiga on võimalik luua klass, mis haldab objektide ja konksude registrit.
Teisisõnu, see puudutab WordPressi konksude registreerimist objektorienteeritud lähenemisviisi abil, et vähendada pistikprogrammi komponentide sidusust ja suurendada sidusust.
Aga mida see üldse tähendab? Millised on selle eelised, kuidas seda seadistatakse ja kuidas seda kasutatakse?
WordPressi konksude registreerimine
Kui loete seda, olete tõenäoliselt tuttav WordPressi konksusüsteemiga, nende käivitamise järjekorraga ja sellega, kuidas funktsioon või klass saab oma funktsioone WordPressis registreerida, et nad saaksid teha mis tahes töid, mida neil vaja on.
Ja sageli näeme, et klassid teevad seda üksinda. Olenevalt projektist teen seda ise. Neile, kes pole tuttavad, näeb see üldiselt välja umbes selline :
<?php
add_action( 'plugins_loaded', 'acme_start' );
/**
* Start the machine.
* https://www.youtube.com/watch?v=ysoMOefPyRs
*/
function acme_start() {
$plugin = new AcmeColumn();
}
Kuid kõike seda saab jagada sidusamateks klassideks, et anda neile klassidele veelgi vähem vastutust (hea asi) ja vähendada klassi või klasside komplekti seost WordPressiga.
Näide kujundusest, mille ma selles postituses lahti räägin.
Selle intuitiivne olemus seisneb aga selles, et selleks on vaja vähemalt üht teist klassi. Aga see toimib järgmiselt.
Seadistamine
Selle näite jaoks kasutame lihtsalt lihtsat klassi, mis registreerib WordPressis teatud tüüpi toimingu. Arhitektuuri idee töötab umbes nii:
- Seal on põhiklass, millel on funktsioon, mille tahame WordPressiga siduda.
- Seal on klass, mis vastutab klassi funktsiooni WordPressiga ühendamise eest.
Piisavalt lihtne, eks? Kuid siin on konks: klass, mis vastutab antud klassi funktsioonide WordPressis registreerimise eest, on punkt, mis nõuab disainiotsust.
Esmalt nimetame klassi HookRegistry, et saaksime sellele õigesti viidata. Järgmiseks nimetame klassi koos funktsioonidega, mida tahame siduda, AcmeColumniks lihtsalt selleks, et esindada klassi, mis lisab uue veeru, WordPressi administraatorialal lehe armatuurlauaks.
Kui see on paigas, taandub disainiotsus järgmisele:
- Kas HookRegistery peaks AcmeColumnist teadma?
- Kas AcmeColumn peaks teadma HookRegistryst?
Ma tean, et selle korraldamiseks on muid viise ja on ka strateegiaid, kuidas sellega toime tulla (nt juhtimise ümberpööramine) ja need on teemad, mida tasub uurida, kuid et see esialgne idee oleks võimalikult lihtne, esitan selle. tulevane postitus.
Klassi kasutamine
Arvestades ülaltoodud valikuid, edastame AcmeColumni eksemplari HookRegistrysse, kui klassid on WordPressi pistikprogrammi algse käivitamise käigus instantseeritud. See võib välja näha umbes selline :
<?php
add_action( 'plugins_loaded', 'acme_start' );
/**
* Start the machine.
* https://www.youtube.com/watch?v=ysoMOefPyRs
*/
function acme_start() {
$registry = new HookRegistry();
$acme_column = new AcmeColumn( $registry );
$acme_column->start();
}
Järgmiseks, kui on aeg lasta AcmeColumnil WordPressis oma funktsioonid registreerida, helistame HookRegistryle ja juhendame seda tegema.
Esiteks, AcmeColumn :
<?php
class AcmeColumn {
private $registry;
public function __construct( $registry) {
$this->registry = $registry;
}
public function start() {
$registry->add_hook( 'filter', 'manage_edit-page_columns', $this, 'add_page_column' );
}
public function add_page_column( $page_columns) {
$page_columns['template'] = 'Acme Column';
return $page_columns;
}
}
Siis HookRegistry :
<?php
class HookRegistry {
public add_hook( $type, $name, $object, $method) {
$type = strtolower( $type );
if ('filter' !== $type || 'action' !== $type) {
return new WP_Error( '1', 'No proper hook type defined.' );
}
}
private function add_filter( $name, $object, $method) {
add_filter( $name, array( $object, $method) );
}
private function add_action( $name, $object, $method) {
add_action( $name, array( $object, $method) );
}
}
Soovi korral saame pidada ka nimekirja erinevatest registreeritud klassidest ja konksudest. See võib olenevalt teie rakendusest olla kasulik, kuid ei pruugi, nii et jagan ainult kui "siin on midagi, mida võiksite teha".
Ja see võiks välja näha selline (kasutades lihtsat assotsiatiivset massiivi):
<?php
class HookRegistry {
private $registry;
public function __construct() {
$this->registery = array();
}
public add_hook( $id, $type, $name, $object, $method) {
$type = strtolower( $type );
if ('filter' !== $type || 'action' !== $type) {
return new WP_Error( '1', 'No proper hook type defined.' );
}
if ('filter' === $type) {
$this->add_filter( $name, $object, $method );
} else {
$this->add_action( $name, $object, $method );
}
$hook_info = array(
$type,
$name,
$object,
$method,
);
$this->registry[ $id ] = $hook_info;
}
private function add_filter( $name, $object, $method) {
add_filter( $name, array( $object, $method) );
}
private function add_action( $name, $object, $method) {
add_action( $name, array( $object, $method) );
}
}
Pange tähele, et ülaltoodud klassis aktsepteerib see nüüd parameetrina $id . Registrisse siseneva teabe tuvastamiseks on mitu võimalust, millest kõige lihtsam on ID ise luua.
Kui aga soovite kasutada midagi sellist, nagu konksu nimi või klassi nimi, toimiks ka see. Pange tähele, et kuna tegemist on assotsiatiivse massiiviga, võib see säilitada ainult ühe väärtuse võtme kohta, nii et kui te ei ole ettevaatlik, võite varasemad andmed prügikasti visata.
Sellest hoolimata pean seda valikuliseks, kuid kui see on rakendatud, on oluline veenduda, et teil on õiged funktsioonid objekti eksemplari võtme abil toomiseks.
Üks paljudest
Nagu iga seda tüüpi tööga seotud puhul, on ka seda võimalik ümber kujundada või ümber suunata viisil, mis toimib teisiti või vastab teie vajadustele. Eesmärk ei ole näidata kindlat mustrit, kuidas midagi teha, vaid viisi, kuidas sellele läheneda ja seda kohandada (nagu iga disainimustri puhul).
Lisaks on selle eesmärk tagada, et meie klassid säilitaksid kohustused, mille jaoks nad on loodud, võimaldades neil end WordPressis vastavalt vajadusele registreerida. Seekord aga ei pea klass seda ise tegema.
Selle asemel annab see vastutuse klassile, kellel on ainuvastutus nimetatud konksude registreerimise eest. Ehkki see toob sisse rohkem klasse, suurendab see ühtekuuluvust ja vähendab sidumist.
See pakub eeliseid hoolduses, testimises ja üldises disainis.