WordPress-ohjelmointi: huolenaiheiden erottaminen
Mitä tulee luokkien luomiseen WordPress-laajennuksille, minulta on kysytty, miksi vaivaudun erottelemaan toimintoja tilaajiin ja muihin luokkiin.
Mielestäni tämä on hyvä kysymys, koska se auttaa ymmärtämään kaksi asiaa:
- tilaajan rooli WordPress-arkkitehtuuriin liittyen,
- muiden luokkien rooli sen suhteen, mitä olet rakentamassa (ja kuinka tämä voi auttaa muissa asioissa, kuten yksikkötestauksessa ja niin edelleen).
Joten ajattelin, miksi en vastaisi lyhyen viestin muodossa? Se dokumentoi miksi-mitä takana [ja se antaa minulle paikan päivittää, jos asiat muuttuvat tulevaisuudessa].
WordPress-ohjelmointi: Tilaajat ja verkkotunnuksen objektit
Pidän luokat, jotka eivät ole tilaajaverkkoalueobjekteja, peräisin toimialuelähtöisen suunnittelun ohjelmistokehityslähestymistavasta.
Se ei kuulu tämän viestin soveltamisalaan, mutta mainitsemisen arvoinen, jos ei mistään muusta syystä antaa kontekstia sille, mitä muuten pidettäisiin ammattikieltä.
1 tilaajaa
Mutta ensin tilaajat.
Koska WordPress perustuu koukkujärjestelmään – tapahtumalähtöiseen suunnittelumalliin perustuvaan järjestelmään – on hyödyllistä, että sinulla on luokka, joka reagoi aina, kun tapahtuma nostetaan esiin.
Tämä voi koskea mitä tahansa ennalta määritettyä WordPress-koukkua tai mukautettuja koukkuja. Ei se mitään.
Enkä halua tehdä luokasta monimutkaisempaa kuin on tarpeen, joten minulla on tapana ajatella niitä näin:
Tilaaja vastaa aina, kun tietty tapahtuma tapahtuu.
Ja siinä se. Tämä tapahtuma voi olla esimerkiksi after_theme_setup tai the_content tai jopa init. Ei sillä ole väliä.
Se odottaa tapahtuman tapahtumista ja vastaa sitten mihin tahansa, mitä päätämme käyttämällä muuta koodia (jolloin verkkotunnuksen objektit tulevat peliin).
2 Domain Objects
Näitä voidaan myös kutsua liiketoimintaobjekteiksi tai vastaaviksi. Idea niiden takana on tämä:
Kaikki, mitä teemme olio-ohjelmoinnissa, on tarkoitettu ratkaisemaan tietty ongelma, ja se on tarkoitus tehdä jonkin tyyppisen objektin kautta, joka edustaa todellisen maailman objektia tai ainakin konkreettista ideaa.
Joten aina kun yrität tarjota ratkaisua jollekulle, kirjoittamasi luokat – objektit, joista niistä tulee, kun ne luodaan – ovat toimialueen objekteja.
Nämä ovat myös luokat, jotka tekevät varsinaista työtä. Joten voit ajatella sitä kolmella osalla:
- WordPress. Ydinsovellus tietysti herättää tapahtuman, johon tilaajat vastaavat.
- Tilaajat. Luokkien joukko, joka vastaa tietyn tapahtuman kuuntelemisesta ja sitten oikean objektin luomisesta koodin käsittelemiseksi.
- Verkkotunnuksen objektit. Koodi, joka todella ottaa joukon dataa, käyttää sitä ja mahdollisesti palauttaa arvon.
Verkkotunnuksen objektit ovat siellä, missä koodi todella tehdä jotain elää. Tilaajat ovat kuin yhteys WordPressin ja mainitun toiminnallisuuden välillä.
Tilaajat sanovat: "Tämä tapahtuma on tapahtunut ja ja tämä luokka kykenee ja vastaa käsittelemään sen tuloksia."
Entä testaus ja niin edelleen?
Aiemmin postauksessa puhuin siitä, kuinka toimialueobjektit liittyvät yksikkötestaukseen ja muihin laadunvalvontaan liittyviin ohjelmointitekniikoihin.
Vaikka tämä ei olekaan yksityiskohtien viesti, on syytä mainita, että verkkotunnuksen objektien ja tilaajien pitäminen irti toisistaan (ja vuorostaan WordPressistä) antaa meille mahdollisuuden luoda, testata ja työskennellä objektien kanssa, joita tilaajia ilman, että sinun tarvitsee ottaa WordPressiä mukaan työhön.
Ja tästä voi olla valtavasti apua, kun rakennetaan suurempia ratkaisuja. Mutta sen tekemisen ydin on sisältöä toiseen viestiin.