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:
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 :
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: