De-coupling Domain Logic i WordPress

Kom ihåg att WordPress använder det händelsedrivna designmönstret och även om vi ofta hänvisar till åtgärder och filter, handlar konceptet om krokar. Flödet av kontroll genom programmet går ungefär så här:

1. Kör programmet,
2. Närhelst programmet stöter på en krok (i WordPress ser vi do_actioneller apply_filters), iterera igenom alla registrerade krokar,
3. Återgå kontrollen tillbaka till programmet,
4. Kör till slutet.

Det här skiljer sig inte helt från Publisher/Subscriber-mönstret (eller PubSub, förkortat) men det finns en viktig skillnad: Det händelsedrivna mönstret signalerar helt enkelt att något har hänt och om det finns krokar kommer de att avfyras. PubSub-mönstret kommer att berätta för en registrerad prenumerant att göra något.

Hur som helst, tillbaka till krokar i WordPress. Att behålla de två begreppen krokar som vi har kan göras enklast genom att tänka på dem så här:

• Handlingar är till för att göra något,
• Filter är till för att bearbeta data.

Om du funderar på att närma dig WordPress-utveckling på ett objektorienterat sätt, är det ingen bra idé att koppla din kod till WordPress-kärnan genom att registrera dina klasser via krokar till kärnapplikationen.

Med andra ord, registrera inte din affärslogik med WordPress. Håll dem åtskilda. Här är ett lackmustest för om ditt arbete är tätt kopplat till WordPress: Om du inte kan köra ett enhetstest mot din klass utan att ladda WordPress, är det tätt kopplat.

Så vad är lösningen? Delegation.

Domänlogik i WordPress

Domänlogik och affärslogik är utbytbara vad jag beträffar, så om du har läst tidigare inlägg om detta och jag har pratat om dem på olika sätt så vet du varför.

Kreditera

Därefter görs idén att delegera logik från WordPress till en klass för domänlogik i WordPress av en mellanklass som är ansvarig för följande:

1. Prenumerera på en hook,
2. Delegera arbetet till en klass.

Jag vet att klasser ska göra "en sak bra", men vad händer om den ena saken är delegering?

att begå (befogenheter, funktioner etc.) till en annan som ombud

ordboken

Och för att överlåta funktionalitet till en annan agent eller, i vårt fall, en klass, måste du ha förmågan att veta vad du delegerar. Ibland, för att göra en sak behöver du känna till flera delar av information.

Så hur ser det här ut rent praktiskt? Föreställ dig att du har en [AbstractSubscriber](https://github.com/tommcfarlin/remove-empty-shortcodes/blob/master/src/Subscriber/AbstractSubscriber.php)till kommer att ta namnet på en krok i dess konstruktor:

Och sedan när det är klart kommer loadfunktionen att skicka arbetet till en klass som är ansvarig för att faktiskt utföra bearbetningen.

Ta till exempel den här koden från Ta bort tomma kortkoder :

En klass prenumererar på en viss händelse, till exempel [the_content](https://developer.wordpress.org/reference/functions/the_content/), och delegerar sedan arbetet till klassen för bearbetning av efterinnehåll.

Detta tillåter bokstavligen plugin-bootstrap-filen att instansiera delegaten. Delegaten kopplar sedan in i WordPress och när WordPress kommer till rätt utförande skickar delegaten ansvaret till klassen som ansvarar för att bearbeta det.

Hela den här arkitekturen är inte bara helt återanvändbar (se användningen av en abstrakt klass ovan), men den tillåter oss att koppla bort domänlogik från WordPress och testa den isolerat.

Mer om Separation of concerns

Jag har skrivit några andra inlägg om separation av bekymmer:

• Separering av bekymmer med WordPress-mallar
• Separering av bekymmer med frågor och hjälpfunktioner
• WordPress-programmering: Separera bekymmer