Üks lihtsamaid asju, mida saame WordPressi pistikprogrammide kallal töötades teha, on loobuda kogu koodist käskkirjadest request_once või include_once .
Ja miks mitte? See on lihtne viis antud klassi jaoks kõigi vajalike failide või sõltuvuste toomiseks, hõlpsasti loetavaks muutmiseks ega pea muretsema tohutute koodifailide loomise pärast. See tähendab, et see aitab meil kirjutatut lihtsustada, et saaksime oma klassidel [enamasti või ideaalis] teha seda, mida nad hästi teevad.
Kui olete seda saiti viimase aasta jooksul lugenud, siis teate, et ma olen automaatse laadimise fänn ja see on midagi, mida minu arvates peaks igaüks, kes töötab PHP-ga – olenemata sellest, kas kasutate WordPressi või muud platvormi –, kasutada.
Kuid see tõstatab kaks küsimust, eriti kui olete alles alustanud:
- Miks vaevleda automaatse laadimisega, kui laadimissõltuvustega toimetulemiseks on ka teisi võimalusi?
- Kuidas automaatne laadimine kompileeritud keeltega võrdub?
Seega mõtlesin, et sellele tasub paaris järgmises postituses vastata.
Miks peaks automaatse laadimisega vaeva nägema?
Lühidalt on see järgmine:
- Nõue_once ja include_once võivad viia koodini, mida on raske siluda,
- koodi on raske jälgida.
Aga kuidas nii?
1 Silumine on raske
Kui koodi kirjutamisel on miski kindel, siis see, et seal on midagi, mis ei tööta nii, nagu ette nähtud. See on meie tegevuse olemus, eks?
Nii et koodi silumise osas on meil kõigil oma strateegiad.
- mõned meist valivad koodi jälgimiseks echo või var_dump ,
- kasutage WordPressi pistikprogrammi,
- teised kasutavad silurit.
Kuigi see postitus ei käsitle silumist, on tõsiasi, et me peame siluma. Nii et kui me teame, et peame seda tegema, kas me ei peaks selle enda jaoks võimalikult lihtsaks tegema?
PHP on dünaamiliselt trükitav keel, nii et üldiselt on palju asju, mille eest me koodi kirjutame alati hoolitseme. See tähendab, et koodi käivitamisel järeldatakse või sunnitakse teatud asju.
Oletagem näiteks, et töötate stringiga ja võrdlete seda arvuga. Tõlk teeb kõik endast oleneva, et arvata, mida te teete (kas soovite sõeluda stringi täisarvuks või vastupidi?) ja seejärel töötada sellega.
Ainuüksi muutujatega töötamine võib olla täpsuse harjutus, sest tahame, et meie kood loeks nii, nagu me kavatseme. Miks jätta tõlgi otsustada, mida me silmas peame? Ja kui tõlk peab lisatööd tegema, teevad seda kindlasti inimesed.
Sel eesmärgil, kui me teame, et vead tuuakse sisse ja teame, et on olemas viise puhtama koodi kirjutamiseks, siis miks me ei võiks seda teha?
2 Jälgimine on raske (või võib-olla raskem?)
Kuid see ei anna ikkagi põhjust, miks peaksime tuginema millelegi automaatlaadurile versus keele sisseehitatud vahenditele, eks?
Mõelge sellele: Oletagem, et otsite viga otsivat faili ja leiate funktsiooni, millel on mingi kood, mis kasutab funktsiooni include_once ja seejärel mõnda muud koodi.
See tähendab, et peate koodi lugema, hoidma seda vaimselt salvestatuna, hüppama teise faili, mõistma seda koodi ja seejärel naasma algse faili juurde. Ja see eeldab, et ka teine fail ei sisalda ega nõua muid faile.
Seda kutsutakse põhjusega spaghetti koodiks.
Seda silmas pidades näete, millist keerulist olukorda see tekitab, kui otsustate selle koodi pesastada kogu ülejäänud programmis. Lühidalt, olete lisanud sõltuvused, mis raskendab tuvastamist, kus midagi võib valesti minna.
See ei tähenda, et automaatne laadimine selle automaatselt parandab, kuid see ei pea nii olema. Selle asemel saate kirjutada koodi, mis loob klassid, kutsub meetodeid ja seejärel käivitab koodi, ilma et oleks vaja midagi käsitsi lisada.
Loetavam, jälgitav kood
Seda tehes leian, et see sunnib meid kirjutama puhtamat koodi, väidetavalt paremini hooldatavat koodi. See muudab ka hõlpsamini jälgitava koodi kirjutamise lihtsamaks ja seda on siluriga lihtsam kasutada.
See tähendab, et saame oma koodi teatud kohtades seada katkestuspunkte, lasta siluril meid automaatselt kutsuda klassi ja astuda tagasi funktsiooni, mis seda kutsus.
See ei tähenda, et seda ei saaks teha muul viisil, kuid kasu kaalub palju üles alternatiividest. Ja loomulikult jääb see endiselt küsimuseks, miks on automaatset laadimist (või mis tahes kolmanda osapoole failide kaasamist) üldse vaja.
Aga sellest tulebki juttu sarja teises osas.
Muu lugemine
Minu postitus WordPressi nimeruumide ja automaatse laadimise kohta ning WordPressi lihtne automaatlaadur on kaks muud ressurssi, mis on ilmselgelt selle konkreetse postitusega seotud. Nii et kui teil on aega, vaadake neid (ja ärge kõhelge avamast probleemi või tõmbetaotlust lihtsa automaatlaaduri projekti kohta).