WordPressi programmeerimine: murede eraldamine
Kui rääkida WordPressi pistikprogrammide jaoks klasside loomisest, on minult küsitud, miks ma viitsin funktsionaalsust tellijateks ja muudeks klassideks eraldada.
Ma arvan, et see on hea küsimus, sest see aitab mõista kahte asja:
- abonendi roll seoses WordPressi arhitektuuriga,
- teiste klasside roll seoses sellega, mida te ehitate (ja kuidas see võib aidata muudel asjadel, nagu üksuse testimine ja nii edasi).
Seega mõtlesin, et miks mitte vastata lühikese postituse vormis? See dokumenteerib põhjuse mis taga [ja see annab mulle koha värskendamiseks, kui asjad tulevikus muutuvad].
WordPressi programmeerimine: abonendid ja domeeniobjektid
Pean klasse, mis ei ole abonemendi domeeniobjektid, pärinevad domeenipõhise disaini tarkvaraarenduse lähenemisviisist.
See ei kuulu selle postituse ulatusse, kuid tasub mainida, kui mitte muul põhjusel, et see annab konteksti sellele, mida muidu žargooniks peetakse.
1 tellijat
Aga kõigepealt tellijad.
Kuna WordPress põhineb konkssüsteemil – süsteemil, mis põhineb sündmusepõhisel kujundusmustril –, on kasulik omada klassi, mis reageerib iga kord, kui sündmus tõstatatakse.
See võib olla mis tahes eelmääratletud WordPressi konksu või mis tahes kohandatud konksu jaoks. Vahet pole.
Ja ma ei taha tundi muuta keerulisemaks kui vaja, nii et ma kipun neist mõtlema järgmiselt:
Tellija vastab alati, kui konkreetne sündmus juhtub.
Ja see ongi kõik. See sündmus võib olla midagi sellist nagu after_theme_setup või the_content või isegi init. Vahet pole.
See ootab sündmuse toimumist ja reageerib sellele, mida me otsustame, kasutades muud koodi (see on koht, kus domeeniobjektid tulevad mängu).
2 domeeniobjekti
Neid võib nimetada ka äriobjektideks või millekski sarnaseks. Nende idee on järgmine:
Kõik, mida me objektorienteeritud programmeerimises teeme, on mõeldud konkreetse probleemi lahendamiseks ja seda tehakse teatud tüüpi objekti kaudu, mis esindab reaalse maailma objekti või vähemalt konkreetset ideed.
Seega, kui töötate selle nimel, et pakkuda kellelegi lahendust, on klassid, mida kirjutate – objektid, mis nendest saab, kui need luuakse – domeeniobjektid.
Need on ka klassid, mis teevad tegelikku tööd. Nii et võite seda mõelda kolmes komponendis:
- WordPress. Põhirakendus muidugi, mis tõstab sündmuse, millele tellijad reageerivad.
- Tellijad. Klasside kogum, mis vastutab konkreetse sündmuse kuulamise ja seejärel koodi käsitlemiseks sobiva objekti leidmise eest.
- Domeeniobjektid. Kood, mis tegelikult teeb andmekogumi võtmise, sellega opereerimise ja seejärel potentsiaalse väärtuse tagastamise.
Domeeniobjektid on koht, kus elab millegi tegeliku tegemise kood. Tellijad on nagu ühendus WordPressi ja nimetatud funktsioonide vahel.
Tellijad ütlevad: "See sündmus on juhtunud ja see klass on võimeline ja vastutab selle tulemuste käsitlemise eest."
Aga testimine ja nii edasi?
Postituses varem rääkisin, kuidas domeeniobjektid on seotud üksuse testimise ja muude kvaliteedikontrolliga seotud programmeerimistehnikatega.
Kuigi see postitus pole üksikasjade jaoks, tasub mainida, et domeeniobjektide ja tellijate üksteisest (ja omakorda WordPressist) lahtiühendamine võimaldab meil luua, testida ja töötada objekte, mida kutsub esile tellijaid, ilma et oleks vaja WordPressi meie töösse kaasata.
Ja sellest võib suuremate lahenduste ehitamisel tohutult abi olla. Kuid sisu selle kohta, kuidas seda teha, on sisu mõne teise postituse jaoks.