Muista, että WordPress käyttää tapahtumalähtöistä suunnittelumallia, ja vaikka viittaamme usein toimiin ja suodattimiin, konsepti on kiinni koukuista. Ohjauskulku ohjelman läpi menee suunnilleen näin:
- Suorita ohjelma,
- Aina kun ohjelma osuu koukkuun (WordPressissä, näemme
do_actiontaiapply_filters), toista kaikki rekisteröidyt koukut, - Palauta ohjaus takaisin ohjelmaan,
- Suorita loppuun asti.
Tämä ei ole täysin erilainen kuin Publisher/Subscriber Pattern (tai PubSub, lyhennettynä), mutta siinä on keskeinen ero: Tapahtumavetoinen malli yksinkertaisesti viestii, että jotain on tapahtunut, ja jos koukut ovat päällä, ne laukeavat. PubSub Pattern kehottaa rekisteröityä tilaajaa tekemään jotain.
Joka tapauksessa takaisin WordPressin koukkuihin. Meidän kahden koukkukäsitteen säilyttäminen voidaan helpoimmin tehdä ajattelemalla niitä näin:
- Teot ovat jotain tekemistä varten,
- Suodattimet on tarkoitettu tietojen käsittelyyn.
Jos haluat lähestyä WordPress-kehitystä oliokeskeisellä tavalla, koodin tiivis yhdistäminen WordPress-ytimeen rekisteröimällä luokkasi ydinsovelluksen koukkujen kautta ei ole hyvä idea.
Toisin sanoen, älä rekisteröi liiketoimintalogiikkaasi WordPressiin. Pidä ne erillään. Tässä on lakmustesti siitä, onko työsi tiiviisti yhdistetty WordPressiin: Jos et voi suorittaa yksikkötestiä luokkaasi vastaan lataamatta WordPressiä, se on tiiviisti kytketty.
Joten mikä on ratkaisu? Valtuuskunta.
Domain Logic WordPressissä
Verkkotunnuksen logiikka ja liiketoimintalogiikka ovat minun mielestäni keskenään vaihdettavissa, joten jos olet lukenut aiempia viestejä tästä ja olen puhunut niistä eri tavoin, tiedät miksi.
Seuraavaksi ajatus logiikan delegoimisesta WordPressistä verkkotunnuksen logiikkaluokkaan WordPressissä toteutetaan välittäjäluokalla, joka vastaa seuraavista:
- koukun tilaaminen,
- Työn delegointi luokalle.
Tiedän, että luokkien pitäisi tehdä "yksi asia hyvin", mutta entä jos se yksi asia on delegointi?
sitoutua (valtuudet, toiminnot jne.) toiselle agenttina
Ja jotta voit sitoa toiminnallisuuden oikein toiselle agentille tai, meidän tapauksessamme, luokalle, sinulla on oltava kyky tietää, mitä delegoit. Joskus yhden asian tekemiseksi sinun on tiedettävä useita tietoja.
Miltä tämä sitten näyttää käytännössä? Kuvittele, että sinulla on [AbstractSubscriber](https://github.com/tommcfarlin/remove-empty-shortcodes/blob/master/src/Subscriber/AbstractSubscriber.php)pakko ottaa koukun nimi sen rakentajaan:
Ja sitten kun se on tehty, loadtoiminto lähettää työn luokkaan, joka on vastuussa käsittelyn suorittamisesta.
Otetaan esimerkiksi tämä koodi kohdasta Poista tyhjät lyhytkoodit :
Luokka tilaa tietyn tapahtuman, kuten [the_content](https://developer.wordpress.org/reference/functions/the_content/), ja delegoi sitten työn sisällönkäsittelyluokalle.
Tämä kirjaimellisesti mahdollistaa liitännäisen bootstrap-tiedoston ilmentämään edustajan. Tämän jälkeen edustaja kytkeytyy WordPressiin ja kun WordPress pääsee oikeaan suorituspisteeseen, delegaatti siirtää vastuun sen käsittelystä vastaavalle luokalle.
Tämä koko arkkitehtuuri ei ole vain täysin uudelleenkäytettävä (katso abstraktin luokan käyttö yllä), vaan sen avulla voimme irrottaa verkkotunnuksen logiikan WordPressistä ja testata sitä erikseen.
Lisää huolenaiheiden erottamisesta
Olen kirjoittanut joitakin muita viestejä huolenaiheiden erottamisesta: