WordPress-programmering: Separera bekymmer

När det kommer till att skapa klasser för WordPress-plugins har jag fått frågan om varför jag bryr mig om att dela upp funktionalitet i prenumeranter och i andra klasser.

Jag tycker att det här är en bra fråga eftersom det hjälper att förstå två saker:

1. rollen som en prenumerant när det gäller WordPress-arkitekturen,
2. de andra klassernas roll när det gäller vad det är du bygger (och hur detta kan hjälpa till med andra saker som enhetstestning och så vidare).

Så jag tänkte varför inte svara i form av ett kort inlägg? Det kommer att dokumentera varför bakom vad [och det kommer att ge mig en plats att uppdatera om saker förändras i framtiden].

WordPress-programmering: Prenumeranter och domänobjekt

Jag betraktar klasserna som inte är abonnentdomänobjekt som kommer från mjukvaruutvecklingsmetoden för domändriven design.

Det ligger utanför ramen för detta inlägg men värt att nämna om det inte av någon annan anledning ger ett sammanhang till vad som annars skulle betraktas som jargong.

1 prenumeranter

Men först, prenumeranter.

Eftersom WordPress är baserat kring ett hook-system – ett system som är baserat på det händelsedrivna designmönstret – är det bra att ha en klass som reagerar på när en händelse tas upp.

Detta kan vara för alla fördefinierade WordPress-krokar eller alla anpassade krokar. Det spelar ingen roll.

Och jag vill inte göra klassen mer komplicerad än nödvändigt så jag tenderar att tänka på dem så här:

En abonnent svarar närhelst en specifik händelse inträffar.

Och det är allt. Denna händelse kan vara något som after_theme_setup eller the_content eller till och med init. Det spelar ingen roll.

Den väntar på att en händelse ska inträffa och svarar sedan på vad vi än bestämmer genom att använda annan kod (vilket är där domänobjekt kommer in i bilden).

2 domänobjekt

Dessa kan också kallas affärsobjekt eller något liknande. Tanken bakom dem är denna:

Allt som vi gör i objektorienterad programmering är tänkt att lösa ett visst problem och det är menat att göra det genom någon typ av objekt som representerar ett verkligt objekt eller åtminstone en konkret idé.

Så närhelst du arbetar med att tillhandahålla en lösning för någon, är klasserna som du skriver – objekten de blir när de instansieras – domänobjekten.

Det är också de klasser som gör själva arbetet. Så du kan tänka på det i tre komponenter:

1. WordPress. Kärnapplikationen, naturligtvis, väcker händelsen som prenumeranterna svarar på.
2. Prenumeranter. Uppsättningen klasser som är ansvariga för att lyssna efter en specifik händelse och sedan instansiera rätt objekt för att hantera koden.
3. Domänobjekt. Koden som faktiskt gör jobbet med att ta en uppsättning data, arbeta på den och sedan eventuellt returnera ett värde.

Domänobjekten är där koden för att faktiskt göra något bor. Prenumeranterna är som kopplingen mellan WordPress och nämnda funktionalitet.

Prenumeranter säger "Denna händelse har hänt och och den här klassen är kapabel och ansvarig för att hantera resultaten av den."

Hur är det med tester och så vidare?

Tidigare i inlägget pratade jag om hur domänobjekt är relaterade till enhetstestning och andra kvalitetskontrollrelaterade programmeringstekniker.

Även om det här inte är inlägget för detaljerna är det värt att nämna att genom att hålla domänobjekt och prenumeranter frikopplade från varandra (och i sin tur från WordPress) kan vi instansiera, testa och arbeta med objekt som anropas av prenumeranter utan att behöva ta med WordPress i vårt arbete.

Och detta är något som kan vara oerhört användbart när man bygger större lösningar. Men kärnan i hur man gör det är innehåll för ett annat inlägg.