Eelmine postitus näitab palju tööd, et võtta midagi, mis oli kunagi kiire prototüüp, ja selle prototüübi kodeerimine. Kui te pole jälginud, oleme teinud järgmist.
- rääkis pistikprogrammi prototüübist ja ehitas selle,
- joonistatud üks objektorienteeritud lähenemisviis võib toimida,
- ja muutis meie prototüübi tegelikuks koodiks.
Siinkohal saame oma koodi täiustamiseks teha veel mõned asjad. Nimelt saame tutvustada nimeruumide mõistet. See viib organisatsiooni sammu edasi ja võib maksta dividende suuremate projektide puhul.
Nii et siin on ülevaade sellest, kuidas see meie praeguses projektis välja näeb.
Prototüüp koodiks: nimeruumid
Olen varasemates postitustes nimeruume põhjalikult käsitlenud. Kui te pole lugenud, siis soovitan. Seejärel tulge tagasi ja vaadake ülejäänud postitust.
Kui otsustate artikli vahele jätta, on siin lühike nimeruumi määratlus :
Nimeruumid on mõeldud kahe probleemi lahendamiseks, millega raamatukogude ja rakenduste autorid korduvkasutatavate koodielementide, näiteks klasside või funktsioonide loomisel kokku puutuvad…
Ja üldine idee on see, et me korraldame oma tunde loogilise suhte alusel, mis neil omavahel on.
Lisaks korraldame failid ka kataloogides, mis vastavad nimeruumile. Seda ei pea tegema, kuid leian, et klasside loogiline korraldamine kettal on kasulik nii, nagu need on nimeruumis virtuaalselt korraldatud.
Seda öeldes korraldame failid.
Failide korraldamine
Selle asemel, et alustada peamise pistikprogrammi failiga, korraldagem kõigepealt oma failid.
- Meta Box ja Meta Box Display failid asuvad kataloogis nimega Display. See on täiesti meelevaldne, kuid kuna need failid seda teevad, tundub olevat mõistlik, et need asuvad seal.
- Võime sellesse kataloogi paigutada ka failid message-description.php ja no-post-list.php, kuid asetame need alamkataloogi nimega Views. Võib-olla soovite seda nimetada mallideks või osalisteks või millekski sarnaseks.
- Järgmiseks on meil klassid, kes vastutavad andmebaasi päringute tegemise eest ja klass, kes vastutab sõnumivahetuse koordineerimise eest. Asetame need kõik Utilitysse. Kindlasti on ka teisi kohti, kuhu nad võiksid minna, kuid pidage meeles, et eesmärk on näidata, kuidas nimeruume kasutada. Nii et kui tunnete nii soovi, kohandage faile oma maitse järgi.
Kui olete järginud ülaltoodut, peaks teil olema kataloogistruktuur, mis näeb välja umbes selline:
Üks viis failide korraldamiseks.
Nüüd on aeg määratleda iga klassi jaoks nimeruumid. Kuna oleme need kõik oma kataloogidesse paigutanud, on nimeruumi määramine lihtne; Siiski on oluline mõista, et teistes nimeruumides asuvate klasside kasutamisel peame kasutama märksõna use.
Vaatame läbi kõik oma failid, alustades utiliidi failidest. Esiteks alustame Post Messengeriga :
Märkate, et faili nimeruum kuvatakse päises koos deklaratsiooniga meie loodud klassi Post Query kasutamiseks. Lisasin klassi nime nimeruumi lõppu, nii et ma ei pea seda kogu koodibaasi ulatuses kasutama.
Pange tähele, et konstruktor näeb nüüd välja selline :
Lisasin argumendi $plugin_dir, kuna peame päringu tulemuste õigeks kuvamiseks seda kasutama. Ja kuna need asuvad nüüd rakenduse erinevas piirkonnas, näevad funktsioonid välja järgmised :
Järgmisena vaatame postituspäringu klassi. Selles klassis pole midagi palju muutunud, välja arvatud see, et oleme andnud sellele nimeruumi ja oleme ka päringut värskendanud ainult kolme postituse tagasitõmbamiseks (vastavalt sellele kommentaarile ).
Pange tähele, et olen ka WP_Query eelfikseerinud kaldkriipsuga, kuna see on osa globaalsest nimeruumist.
Liigume kataloogi Display ja heidame pilgu Meta Box klassile. Sellele on antud ka nimeruum ja see kasutab ka Meta Box Display klassi täielikku nime, mida me hetkel vaatame.
Pange tähele, et see konstruktor aktsepteerib ka pistikprogrammide kataloogi argumendina ja edastab selle ka Meta Box Display klassile. See tähendab, et sõnumite kuvamise eest vastutavad funktsioonid leiate nende asukohast kataloogis Vaated.
Lõpuks vaatame üle klassi Meta Box Display . See on lihtne klass, mis sisaldab nimeruumi ja viitab Post Messengerile, mida oleme eespool vaadanud.
Siinkohal oleme pistikprogrammi kaudu täisringi teinud. Ühe erandiga: alglaadimisfail. Lisasime sellele nimeruumi ja peame värskendama selle instantsimise viisi :
Nimelt on meil:
- määratles nimeruumi,
- viidake Meta Box klassi asukohale,
- värskendas teid, et lisada failide leidmine (mida saab lõpuks teha automaatlaaduriga),
- ja värskendas kutset add_action.
Lisatoimingu kutse kohta on see järgmine: kuna WordPress peab leidma selle funktsiooni asukoha ja funktsioon asub nimeruumis, tuleb funktsiooni täielik nimi tuvastada, et WordPress saaks selle välja kutsuda. Sellest tuleneb ka vajadus funktsiooni nimes NAMESPACE .
Nüüd oleme organiseeritud (ühe erandiga)
Nagu näete, lisavad neile vastavad nimeruumid ja kataloogid projektile palju korraldust. Seda on lihtsam jälgida, lihtsam aru saada, kuhu asjad liiguvad (nii olemasolevate kui ka uute failide puhul). Ja see tekitab vähem tunnet, kui kogute palju faile ühte kohta.
Isegi kui klass on natuke monoliitne, saab selle siiski korraldada nii, et hooldus oleks lihtne.
Sellele vaatamata muudaksin selle pistikprogrammi juures veel midagi: selline pistikprogrammi kataloogi ümberpaigutamine ei aita madalat sidusust ja see seob klassid omavahel tihedamalt, kuna alglaadimisfail peab edastama väärtuse üks klass, mis edastab selle teise klassi, mis kasutab seda failide laadimiseks ja nii edasi.
Kas on võimalusi selle parandamiseks? Absoluutselt. Ja võib-olla vaatame seda viimases postituses.
Pidage meeles, et seni on pistikprogrammi uusim versioon saadaval GitHubi põhiharus, mis on märgistatud kui 0.3.0.