Domeeniloogika lahtisidumine WordPressis
Pidage meeles, et WordPress kasutab sündmustepõhist kujundusmustrit ja kuigi me viitame sageli toimingutele ja filtritele, taandub kontseptsioon konksudele. Juhtimisvoog läbi programmi on umbes selline:
- Käivitage programm,
- Kui programm satub konksule (WordPressis näeme
do_actionvõiapply_filters), korrake läbi kõik registreeritud konksud, - Naaske juhtimine programmile,
- Teostage lõpuni.
See ei erine täielikult väljaandja/tellija mustrist (või lühidalt PubSubist ), kuid sellel on oluline erinevus: sündmustest juhitud muster annab lihtsalt märku, et midagi on juhtunud ja konksude korral käivituvad. PubSub Pattern käsib registreeritud tellijal midagi ette võtta.
Igatahes, tagasi WordPressi konksude juurde. Kahe konksude kontseptsiooni säilitamine on kõige lihtsam, kui mõelda neile järgmiselt:
- Teod on millegi tegemiseks,
- Filtrid on mõeldud andmete töötlemiseks.
Kui soovite läheneda WordPressi arendamisele objektorienteeritud viisil, ei ole hea mõte oma koodi tihedalt WordPressi tuumaga siduda, registreerides oma klassid põhirakenduse konksude kaudu.
Teisisõnu, ärge registreerige oma äriloogikat WordPressis. Hoidke neid eraldi. Siin on lakmuspaber selle kohta, kas teie töö on WordPressiga tihedalt seotud. Kui te ei saa oma klassiga ühikutesti ilma WordPressi laadimata käivitada, on see tihedalt seotud.
Mis on siis lahendus? Delegatsioon.
Domeeniloogika WordPressis
Domeeniloogika ja äriloogika on minu arvates omavahel asendatavad, nii et kui olete lugenud eelnevaid selleteemalisi postitusi ja ma olen neist erineval viisil rääkinud, siis teate, miks.
Järgmisena teeb WordPressi loogika delegeerimise idee WordPressi domeeniloogika klassile vaheklass, mis vastutab järgmise eest:
- konksu tellimine,
- Töö delegeerimine klassile.
Ma tean, et klassid peaksid "üht asja hästi tegema", aga mis siis, kui see üks asi on delegeerimine?
teisele agendile pühenduma (volitused, funktsioonid jne).
Ja selleks, et määrata funktsionaalsus korralikult teisele agendile või meie puhul klassile, peab teil olema võimalus teada, mida delegeerite. Mõnikord on ühe asja tegemiseks vaja teada mitut teavet.
Kuidas see siis praktiliselt välja näeb? Kujutage ette, et teil on [AbstractSubscriber](https://github.com/tommcfarlin/remove-empty-shortcodes/blob/master/src/Subscriber/AbstractSubscriber.php)soov võtta konksu nimi selle konstruktorisse:
<?php
/*
* This file is part of Remove Empty Shortcodes.
*
* (c) Tom McFarlin <tom@tommcfarlin.com>
*
* This source file is subject to the GPL license that is bundled
* with this source code in the file LICENSE.
*/
namespace TomMcFarlinRESCSubscriber;
use TomMcFarlinUtilitiesRegistry;
/**
* An abstract implementation of a subscriber that requires a hook and the ability to
* start the class.
*/
abstract class AbstractSubscriber
{
/**
* @var string a reference to the hook to which the subscriber should be registered
*/
protected $hook;
/**
* @var Registry a reference to the simple container used to maintain plugin objects
*/
protected $registry;
/**
* @param string $hook the hook to which the subscriber is registered
*/
public function __construct(string $hook)
{
$this->hook = $hook;
$this->registry = apply_filters('rescRegistry', null);
}
/**
* @return string the hook to which the subscriber is registered
*/
public function getHook(): string
{
return $this->hook;
}
abstract public function load();
}
Ja kui see on tehtud, loadsaadab funktsioon töö klassile, kes vastutab töötlemise eest.
Võtke näiteks see kood jaotisest Eemalda tühjad lühikoodid :
<?php
/*
* This file is part of Remove Empty Shortcodes.
*
* (c) Tom McFarlin <tom@tommcfarlin.com>
*
* This source file is subject to the GPL license that is bundled
* with this source code in the file LICENSE.
*/
namespace TomMcFarlinRESCWordPress;
/**
* Processes the post content by looking to see if any orphaned shortcode
* exists and then removes it from displaying it from the user.
*/
class PostContentProcessor
{
/**
* A reference to the Shortcode Manager for processing orphaned shortcodes.
*/
private $shortcodeManager;
/**
* Initializes the class by setting up a reference to the Registry and the
* Shortcode Manager.
*/
public function __construct()
{
$registry = apply_filters('rescRegistry', null);
$this->shortcodeManager = $registry->get('shortcodeManager');
}
/**
* @param string $content the filtered post content
*
* @return string $content the filtered post content without the shortcode
*/
public function run(string $content): string
{
return $this->shortcodeManager->processShortcodes($content);
}
}
Klass tellib konkreetse sündmuse (nt [the_content](https://developer.wordpress.org/reference/functions/the_content/)) ja delegeerib seejärel töö sisu postituse töötlemise klassile.
See võimaldab sõna otseses mõttes plugina alglaadimisfailil delegaadi instantseerida. Seejärel haakub delegaat WordPressi ja kui WordPress jõuab õigesse täitmispunkti, saadab delegaat vastutuse selle töötlemise eest vastutavale klassile.
Kogu see arhitektuur pole mitte ainult täielikult taaskasutatav (vt abstraktse klassi kasutamist ülal), vaid see võimaldab meil domeeniloogika WordPressist lahti ühendada ja seda eraldi katsetada.
Lisateavet murede lahususe kohta
Olen kirjutanud mõned muud postitused murede lahususe kohta:
