Eelmisel nädalal pidasin WordCamp Atlanta ettekande nimeruumide ja automaatse laadimise teemal. (täispealkiri oli nimeruumid, automaatne laadimine ja pistikprogrammide arhitektuuri täiustamine, kuid see on suutäis, kas pole?)
Vestluse olemuse tõttu olen otsustanud kirjutada postituse juurde postituse, jagada slaide ja jagada vestluse toetamiseks GitHubi näidet.
Nii et kui olite kohal, tänan teid(!) ja siin on postitus, ma lubasin. Ja neile, kes ei osalenud, loodan, et see postitus aitab siiski näidata kontseptsioone ja teemasid , mida WordCampis arutasin.
Nimeruumid ja automaatne laadimine
Enne kui räägime WordPressi nimeruumidest ja automaatsest laadimisest, tahan sellest rääkida, kuna see võib teie koodi kvaliteeti otseselt mõjutada ja seda veel kuude ja aastate jooksul.
Lõppude lõpuks ei esita paljud meist arendajad juba küsimust:
Kuidas saaksime oma koodi paremaks muuta, kui see praegu on?
Ja paljud meist on piisavalt targad, et teada, mida me ei tea. Seega peame töötama meile antud piirangute piires.
Mõnikord on meil aega uurida, kuidas seda teha; muul ajal teeme tööd teadmistega, mis meil on. Ja selles pole midagi halba.
Kuid kuna me teame seda, mida me ei tea, teame, et meil on potentsiaali enamaks.
Esiteks, teie kood
Kui rääkida sellistest teemadest nagu nimeruumid ja automaatne laadimine WordPressi kontekstis, siis arvan, et me saame sageli vastakaid vastuseid.
Lõppude lõpuks võiksime rääkida sellistest asjadest nagu Theme Customizer või REST API või millestki lõbusamast.
Ma mõtlen, et "nimeruumid ja automaatne laadimine" lihtsalt ei kõla põnevalt ega edasiviivalt, kui võrrelda saadaolevate uuemate funktsioonide ja tehnoloogiatega, eks?
Aga ei, nad ei ole tegelikult igavad. Ja selle postituse ning sellega kaasneva esitluse ja lähtekoodi kaudu näitan teile, miks ja kuidas nad ei ole.
Nad ei ole igavad
Ma arvan, et on õiglane öelda, et arendajad – vähemalt osa meist või osa neist olenevalt sellest, kuidas te ennast näete – on programmeerimise aspektide üle vaidlemise poolest kurikuulsad.
"Igatahes igav vestlus."
Tegelikult pole sugugi haruldane kuulda kedagi vaidlemas selle üle, milline on parim viis initsialiseerida ja kirjutada for-silmus, mis on võimalikult tõhus, kui itereerida väikeses andmebaasikomplektis, hoolimata sellest, et meil on neljatuumalised protsessorid ja 16 GB muutmälu. meie lauaarvutites.
Nii et kui me nii väikesest asjast nii palju hoolime, hoolime kindlasti laiemast pildist. Sellised asjad nagu:
- Täiustatud kood
- Parem korraldus
- Suurenenud hooldatavus
- Lihtsam silumine
- Rohkem raha teenimine (noh, võib-olla).
Ja nimeruumid ja automaatne laadimine võivad viia otse kõige eelnevani (noh, ma ei saa rääkida rahast, kuid sellel on potentsiaali).
Kui ma peaksin kõigi ülalnimetatute rollide nimeruumid ja automaatse laadimise kohad kokku võtma, siis ütleksin järgmist:
Nimeruumid ja automaatne laadimine viivad parema korralduse, lahterdamise või modulariseerimise kaudu täiustatud koodini ning nende kontseptsioonide kaudu tihedamate suheteni.
Lisaks suurendab see hooldatavust, kuna kood on jaotatud pakettidena, mis võib toote kasvades hõlbustada silumist.
Kõik see võib kaasa tuua aja säästmise või parema ajakasutamise, mis sõltuvalt teie ärimudelist võib mõjutada teie kasumit.
Kuid see ei kirjelda siiski kumbagi neist asjadest. Kuid kindlasti kõlavad need praegu huvitavamalt kui siis, kui neid esmakordselt tutvustati.
Niisiis, mis nad on?
Enne nende ja nende rollide määratlustega tutvumist vaadakem, kuidas nimeruumide ja automaatse laadimise puudumine WordPressis on negatiivselt mõjutanud teie kogemusi teemade, pistikprogrammide, lisandmoodulite või mis iganes muul kasutamisel.
Nii et pöördume korraks tagasi ja vaatame igaühte eraldi.
Nimeruumid
Kujutage ette, et olete pärinud projekti ja hakkate sellega tegelema. Oletame, et see on WordPressi pistikprogramm.
installite selle; aktiveerite selle ja seejärel antakse teile vähemalt üks järgmistest:
- Võib-olla näete seda vastikut korraldusteadet brauseriakna ülaosas, millel kuvatakse virna jälg.
- Võib-olla näete teadet, mis räägib konfliktist mõne teise olemasoleva paketiga.
- Või kui proovite pistikprogrammi aktiveerida, värskendatakse lehte, kuid pistikprogramm ei aktiveeru.
- Võib-olla olete isegi koodiauditi teinud ja näete klassi_exists-kontrolle kogu koodibaasi ulatuses.
Mis tahes või kõik ülaltoodud tegurid võivad loomulikult kaasa aidata probleemidele WordPressi projektidega. Kuid nimeruumid suudavad enamiku ajast tõesti paljusid asju parandada.
See tähendab, et põhjus, miks teil neid probleeme kogete, on see, et kood, millega töötate, on osa globaalsest nimeruumist (võrreldes selle nimeruumiga) ja PHP-le ei meeldi, kui klassid ja moodulid on sama nimega. .
Aga kui annate millegi nimeruumi, annate sellele tema enda suhtes oma ala, mis mängib kenasti teiste komponentidega, isegi kui neil on sama klassi nimi.
Automaatlaadurid
Mis puudutab automaatlaadureid, siis need on mõnes mõttes veidi vähem keerulised. Esmalt mõelge koodile, mida kirjutate, või koodile, millega töötate – eriti WordPressi pistikprogrammide kontekstis – ja seejärel mõelge sellele, mitu korda kirjutate või näete järgmist.
Ja mõnikord näete neid pistikprogrammi käivitava faili ülaosas ja mõnikord näete neid koodibaasi laiali.
Kui need kõik sisalduvad ühes failis, pole see nii hull, sest vähemalt teate, kus need asuvad. Aga kui need on kõikjal risustatud, siis pole teil aimugi, kust sõltuvus süsteemi tuuakse.
Automaatne laadimine võib selle kõik lahendada, laadides vajaduse korral sõltuvused (ja huvilistele on automaatne laadimine kiirem kui käsitsi kaasamine).
Nimeruumid
Kõike seda arvesse võttes oleme valmis rääkima nii nimeruumidest kui ka automaatsest laadimisest. Kuid nimeruumid on aluskontseptsioon, nii et alustame sellest.
Kuid pärast kõike ülaltoodut näete nende kasutamise eeliseid. Võib-olla on nad isegi lõbusad, eks? Võib olla?
Sellest hoolimata vajame definitsiooni, mille põhjal saame ülejäänud artiklis sellest läbi rääkida.
PHP käsiraamat pakub järgmise määratluse :
Nimeruumid on mõeldud kahe probleemi lahendamiseks, millega raamatukogude ja rakenduste autorid korduvkasutatavate koodielementide, näiteks klasside või funktsioonide loomisel kokku puutuvad…
Ja see pole halb, kuid see on üsna pikk, tehniline ja see võib olla natuke palju neile, kes alles alustavad. Nii et lihtsustame seda selle artikli jaoks veidi:
Natuke parem ehk?
Võimalus rühmitada sarnase eesmärgiga seotud klasse ja liideseid.
Ma ei hakka selles kõnes rääkima liidestest; aga ma tean, et on kesktaseme objektorienteeritud arendajaid, kes neid kasutavad, nii et tahtsin veenduda, et ma neid vähemalt mainiks.
Praktiline näide
Mulle ei meeldi programmeerimisnäited, mis ei anna reaalset ega praktilist rakendust. Sageli tuuakse meile näiteid asjade kohta, mida me kunagi kodifitseerima ei hakkaks.
Mitu korda olete lugenud objektorienteeritud artiklit ja see toob näite loomade või autode klassist? Me ei hakka autot programmeerima.
Suure tõenäosusega töötame failidega. Seega vaatame failide lugemise ja kirjutamise eest vastutavate klasside komplekti. See tähendab, et oleme olnud head objektorienteeritud programmeerijad ja eraldanud oma klassid nende kohustuste alusel.
Ja jah, teil võivad olla liidesed; kuid need ei kuulu selle artikli reguleerimisalasse, seega neid ei kaasata.
Nii et meie FileReaderi jaoks näevad klassi põhitõed välja järgmised:
Failide lugemise klass.
Pange tähele, et funktsioon aktsepteerib faili nime, mille see peaks lugemiseks avama. Veakontroll, kuidas see faili loeb ja mida see tagastab, on kõik jäetud klassi rakendamise otsustada.
Ja FileWriteri jaoks on meil midagi sellist:
Failide kirjutamise klass.
See klass aga aktsepteerib teavet, mida see kettale kirjutab, ja faili nime, kuhu see tuleks kirjutada.
Jällegi, nagu ülaltoodud näite puhul, ei hõlma see vigade kontrollimist, ressursi kaudu kirjutamist, ressursside sulgemist ja nii edasi.
Kuid see ei puuduta failidega töötamist. Selle asemel näidatakse, kuidas oma koodi nimeruumi määrata, ja need kaks näidet on selle jaoks aluseks.
Märkused nimeruumide kohta
Ülaltoodud näidiskoodi piltidel on hoiatus: need klassid ei ole nimeruumiga. See tähendab, et nad elavad globaalses nimeruumis, mis jätab nad küpseks konfliktideks teiste klassidega.
Vaadake seda järgmiselt: kujutage ette, et pakite selle koodi kellegi teise jaoks mõeldud pistikprogrammi ja seejärel laadib ta teise pistikprogrammi, millel on ka FileReader või FileWriter. Kuna see kõik on osa samast globaalsest nimeruumist, seisate silmitsi konfliktiga.
Pidage meeles:
Nimeruumid on viis sarnase eesmärgiga seotud klasside ja liideste rühmitamiseks.
Nii et võtame klassid ja koodi nimeruumi.
Esiteks pakume tipptasemel nimeruumi, mille all need klassid ja kõik muud klassid asuvad; siis pakume alampaketi (või alamnimeruumi või alamruumi, nagu ma olen kuulnud neid kutsumas), milles need failiklassid asuvad.
See tähendab, et meie FileReader näeb nüüd välja selline:
Nimeruumiga klass failide lugemiseks.
Ja meie FileWriter näeb nüüd välja selline:
Nimeruumiga klass failide kirjutamiseks.
Esiteks näete, et nimeruumide kasutamine on lihtne: kasutate lihtsalt nimeruumi märksõna ja seejärel deklareerite nimeruumi (mis võib sama lihtsalt olla WCATL) ülaosas koos järgnevate alampakettidega.
Kuid see viib muude teemadeni – nimelt failide korraldamise, instantsimise ja automaatse laadimise kohta –, mida kõike tasub käsitleda.
Failikorralduse kohta
Siinkohal on oluline rääkida failikorraldusest. Sõltuvalt sellest, kellega räägite, avastate, et mõnel arendajal – üllatus, üllatus – on arvamus selle kohta, kuidas faile tuleks korraldada (ja mina ei erine sellest).
Ühest küljest ei pea te faile üldse korraldama. Tegelikult saate kõik asjad oma projekti juurkataloogi panna, teabe nimeruumi ja olla valmis.
Korraldamata failid
Ülaltoodud failide komplekt on mõeldud väikese projekti jaoks, nii et võite ette kujutada, kui palju faile oleks suure projekti jaoks.
Kuid kui teil on failid nii korraldatud, võib see muuta automaatlaaduri kirjutamise pisut keeruliseks, kuna automaatlaadur peab teadma, kust failid nende nimeruumi põhjal leida.
Siin tulevad mängu mõisted "loogiline organisatsioon" ja "virtuaalne organisatsioon".
- Loogiline korraldus viitab sellele, kuidas failid on kettal korraldatud, nagu ülaltoodud. Need asuvad loogiliselt juurkataloogis.
- Virtuaalne korraldus viitab sellele, kuidas failid on nende nimeruumide järgi korraldatud. See tähendab, et on olemas kataloogid ja alamkataloogid, mis vastavad nimeruumidele, alampakettidele jne.
Nii et kui võtaksite ülaltoodud projekti, selle nimeruumid, alampaketid ja korraldaksite need nii loogiliselt kui ka virtuaalselt, näeks see välja umbes selline:
Nimeruumid ja automaatne laadimine: organiseeritud failid
Ja kuigi saate oma faile korraldada nii, nagu soovite, olen nende kahe võrdsuse tagamise fänn. See tähendab, et mulle meeldib, et minu loogiline ja virtuaalne organisatsioon sobivad kokku, nagu näete ülaloleval pildil.
Kui hakkan automaatse laadimise üle arutama, näete, miks see oluline on.
Märkused nimeruumide kohta
Mis aga juhtub, kui meil on vaja instantseerida klassid, mis on nimeruumiga? Kui klassid ei ole nimeruumis, on lihtne kasutada märksõna "uus".
Esinemine ilma nimeruumita.
Kuid me peame instantseerima nimeruumiga klassi, peame astuma sammu edasi ja kasutama täielikult kvalifitseeritud nime:
Nimeruumid ja automaatne laadimine: nimeruumiga loomine.
Kuid see muutub tülikaks, kas pole? See konkreetne näide pole nii halb, kuid kujutage ette, kui töötaksite millegi kallal, kus on rohkem alampakette. See läheks üsna tülikaks, kas pole?
Sel eesmärgil saame kasutada nn varjunime. See on ka lihtne. Võime defineerida faili ülaosas märksõna "use" kasutamise, et viidata nimeruumile, millele tahame varjunime anda, ja seejärel kasutada viimast alampaketti aliase osana, et oma klassi instantseerida.
Kõlab segaselt, kas pole? Võib-olla aitab selle nägemine tegevuses:
Nimeruumide alias.
Ja see on kõik. Jah, võite pseudonüümi kasutamisega sammu edasi minna, kuid see on nii kaugele, kui ma seda selle artikli kontekstis võtan.
Automaatne laadimine
Siinkohal on meil automaatlaadimiseks alus pandud. Jah, nimeruumide läbi töötamine võib olla palju tööd, kui te pole sellega harjunud; Siiski on oluline mõista, sest automaatne laadimine nõuab natuke tööd, mis võib olla ootamatu, kui te pole seda kunagi varem tutvustanud.
Sellest hoolimata on kõige olulisemad asjad, mida nimeruumidega seoses meeles pidada, on järgmised:
- Nimeruumid on viis sarnase eesmärgiga seotud klasside ja liideste rühmitamiseks.
- Looge oma failide ja nimeruumide kaudu paarsus, tagades, et teie loogiline ja virtuaalne organisatsioon on samad.
Ja nüüd on aeg vaadata automaatset laadimist.
Märkused automaatse laadimise kohta
Kõigepealt vaatame automaatse laadimise määratlust, mis on antud PHP juhendis :
Funktsioon spl_autoload_register() registreerib suvalise arvu automaatlaadureid, võimaldades klasside ja liideste automaatset laadimist, kui need pole hetkel määratletud. Autoloaderite registreerimisel antakse PHP-le viimane võimalus klass või liides laadida enne, kui see vea tõttu ebaõnnestub.
See ei ole paha. See on siiski pikk. Nii nagu tegime nimeruumide puhul, kasutame selle artikli jaoks lühemat määratlust:
Viis liideste ja klasside automaatseks laadimiseks ilma kaasamise ja nõudmise avaldusi kasutamata.
Jällegi, me ei kasuta selles artiklis liideseid, kuigi mõned arendajad seda teevad. Ja see annab töömääratluse selle artikli ülejäänud osas.
Praktiline näide
Kui olete oma failid organiseeritud, nimeruumi paigutanud ja laadimiseks valmis, on aeg seda teha, eks? Ma mõtlen:
- teie failid on korrastatud,
- olete valmis neid laadima
Nii et on aeg seda automaatselt teha, eks? Kuid seal on konks. Kogu failide "automaatne laadimine" nõuab natuke tööd.
Autoloaderi kirjutamine
See tähendab, et see on automaatne, kuid see nõuab meilt siiski veidi rohkem tööd. Enne nende sammudega alustamist on oluline märkida:
- see pole täielikult automatiseeritud,
- me peame selle kirjutama.
Nii tore kui ka koodi automaatne laadimine oleks, peame lugema mõned andmed, need sõeluma ja seejärel proovima õiget faili laadida.
Kuid eeldades, et kirjutate selle õigesti ja oma nimeruumi ning korraldate failid iga projekti jaoks samal viisil, saate oma automaatlaadurit uuesti kasutada. See tähendab, et kirjutate selle ühe korra ja saate seda kasutada teistes projektides.
Automaatlaaduri sammud
Autoloaderi kirjutamisel tuleb järgida vaid mõnda sammu. Autoloader peab suutma vastata järgmistele failidele:
- Kus failid on?
- Kuidas neid nimetatakse?
- Kas fail on olemas?
Kui kõik ülaltoodud on tõesed (või saate neile kõigile vastata "jah"), teeb automaatlaadur seda, mida ta peaks tegema.
Vaatame hetke pärast mõnda koodi, kuid esimene asi, mida tuleb tähele panna, on see, et see kasutab funktsiooni nimega spl_autoload_register.
SPL viitab standardsele PHP teegile ja funktsioon aktsepteerib funktsiooni argumendina ja see funktsioon aktsepteerib selle klassi nime, mida luuakse. See on pigem protseduuriline kui objektorienteeritud ja ma räägin sellest kohe, kuid seda on oluline seda koodi lugedes meeles pidada.
Siin on koodi esimene osa. Selgitan hiljem, mida see teeb:
Automaatne laadimine, 1. osa – klassi leidmine
Selles koodi osas saab funktsioon instantseeritava klassi täiskvalifitseeritud nime (nt “WCATLFileFileReader()").
Järgmisena eraldab see kõik täisnimetuse osad osadeks. Klassi nimi on massiivi viimane indeks ja ma valin oma failidele nime anda "class-filereader.php", nii et funktsioon loob muutuja $class_file, mis viitab faili nimele.
Kuid me pole veel lõpetanud. Peame ikkagi hankima täielikult kvalifitseeritud nime (see tähendab, kus fail kettal asub). See võib välja näha umbes selline:
Automaatne laadimine, 2. osa – täieliku nime saamine
Sel hetkel valmistame ette muutuja $full_qualified_path, mis viitab tipptaseme kataloogile.
Järgmisena itereerib kood läbi massiivi kõigi indeksite ja loob klassifaili tee. Võite seda ette kujutada stringi, näiteks "wcatlfile" loomisena, mille ühendame seejärel failiga $class_file.
See tähendab, et faili täielikuks teeks saab "wcatlfileclass-filereader.php".
Ja lõpuks lisame faili. Pange tähele, et see kood ei kontrolli faili olemasolu. Kuigi ma soovitan seda, on see pikkuse huvides välja jäetud ja kuna meie näites teame, et fail on olemas.
Kui faili pole olemas, on mitu võimalust:
- Tee erand,
- Püüdke erand,
- Kuvage oma veateade,
- Või mõni muu võimalus, mida ma selles artiklis kaalun.
Sellest hoolimata on idee olla oma koodis kaitsev, et saaksite valmistuda juhuks, kui faili pole olemas, ja saaksite tõrkega toime tulla.
Automaatse laadimise korral
Enne lõpetamist tasub tähele panna järgmist.
- Kogu näite jooksul oleme koodi nimevahede määramisel kasutanud objektorienteeritud koodi. Lõppude lõpuks on see objektorienteeritud kontseptsioon.
- Meie automaatlaadur on kirjutatud protseduurikoodis. Mis annab?
Lõppkokkuvõttes on see seotud standardse PHP raamatukoguga. Võite kirjutada objektorienteeritud automaatlaaduri, kuid ma arvan, et see on paljudel juhtudel pisut liialdatud.
Faili laadimise protsess on samm-sammuline protsess, nii et selle protseduuriline kirjutamine sobib loomulikult.
Lõpuks võivad teised valida sõltuvuste toomiseks kasutada selliseid tööriistu nagu Composer. Need on suurepärased tööriistad ja millegi sellisel kasutamisel on palju eeliseid; aga see on väljaspool selle artikli mõisteid ja teemasid ning on parem jätta tulevaseks jutuks.
Ressursid (ja aitäh!)
See on olnud üks pikimaid artikleid, mille olen oma saidile kirjutanud.
See on osaliselt tingitud sellest, et see põhineb WordCampi vestlusel ja ka seetõttu, et tahan olla kindel, et pakun tugeva sissejuhatuse ja aluse, mille abil saate alustada nimeruumide lisamist ja automaatset laadimist oma WordPressi pistikprogrammidesse.
Lisaks sellele artiklile olen pakkunud ka järgmisi ressursse:
- Minu esitluse slaidid on saadaval SpeakerDeckis.
- Mul on selle esitluse kood GitHubis allalaadimiseks saadaval .
Ja sellega seoses loodan, et see annab põhjaliku sissejuhatuse namepsace’i ja automaatse laadimise kohta ning et saate hakata seda üha enam oma töösse kaasama. Sellest on palju kasu teie tööle ja teistele arendajatele, kes võivad samuti teie tööd kasutada.