Andmebaasipäringud andmete kiireks värskendamiseks, 2. osa
See on teine ja viimane osa seeriast, mis käsitleb – nagu pealkiri viitab – otseseid andmebaasipäringuid. Täpsemalt, see puudutab postituste olekute muutmist (kuid see on asjakohane rohkem kui selle jaoks).
Foto Ross Findon Unsplashist
See on järjekordne postitus, mis illustreerib, kuidas kasutada $wpdb-d metaandmetel põhineva teabe kiireks värskendamiseks.
Ja selles postituses olev kood töötab, kuid kui soovite muuta selle objektorienteeritumaks, on veel palju tööd teha.
Enne tegeliku postituse juurde hüppamist on siiski oluline märkida, et kui tegemist on objektorienteeritud programmeerimisega, on klassi kujundamisel ja abstraktsioonitasemete loomisel palju tööd.
Mingil hetkel peate tõmbama vanasõnalise piiri selle vahele, millal kavatsete liideseid kasutada, kui üksikasjalikud on teie klassid nende abstraktsioonide ja muu sarnase vahel.
Ja selle postituse eesmärk on aidata pakkuda paremat objektorienteeritud disaini, kuid see pole harjutus, mis muudab selle võimalikult optimaalseks. Ma arutan selliseid teemasid teises postituste sarjas.
Kuid pidage seda meeles, kui lugesite kogu ülejäänud postituse koodi läbi.
Andmebaasipäringud andmete kiireks värskendamiseks, 2. osa
Arvestades seda, kus me pooleli jäime, on meil üks funktsioon, mis teeb järgmisi toiminguid.
- hankida kõik konkreetse metavõtmega seotud postitused,
- otsustada, kas peame varakult lahkuma,
- värskendage kõigi olemasolevate postituste postituste olekut.
Kõigepealt tuleb märkida, et üks funktsioon on liiga palju, seega tuleb see jagada mitmeks muuks funktsiooniks. Ja kuna see on objektorienteeritud, peame tagama, et kõik, mida funktsioon teeb, ei sõltu tingimata eelmistest sammudest – see on protseduurilise programmeerimise eesmärk.
Selle asemel kasutame seda võimalust funktsioonide seadistamiseks, et need toimiksid neile edastatavate andmete põhjal, olenemata sellest, kuidas nad sinna jõudsid.
Lõpuks on teie kui arendaja otsustada, kas soovite selle tegemiseks kasutada ühte klassi, rohkem kui ühte klassi või seotud klasside komplekti, mis pärivad ülemklassilt.
Jällegi on kõik selles, kui abstraktseks soovite koodi muuta.
Praegu aga liigume asjade lõhkumisega edasi.
1 Haarake seotud metavõtmega postituste ID-d
Täpselt nagu esimeses postituses, tahame olla kindlad, et hangime postituste ID-sid, mis on seotud konkreetse metavõtmega.
Selle funktsiooni võimalikult paindlikuks muutmiseks seadistame selle järgmiselt:
- aktsepteeri metavõtit stringina,
- tagastab massiivi
Funktsioon näeb siis välja umbes selline:
Esimeses postituses jagasime selle kolmeks etapiks (mis on ka ülalpool välja toodud). Siin saame aga ühendada teise ja kolmanda sammu üheks funktsiooniks.
2 Värskendage postituse olekut
Nagu ma mainisin, on objektorienteeritud programmeerimise üks aspekt tagada, et meie kasutatavad funktsioonid oleksid vastuvõetavate andmete genereerimise suhtes agnostlikud.
Selle asemel on neil üks algoritm, mis keskendub funktsioonile edastatud andmetele. Sel juhul tahame võtta tulemuste komplekti (mis on postituse ID-d) ja värskendada nende postituse olekut nii, et see oleks mustand.
See tähendab, et funktsioon aktsepteerib massiivi, kuid ei tagasta midagi. Võimalik, et saate lasta sellel jälgida paljusid värskendatud postitusi (või kui see üldse midagi värskendas), kuid ma keskendun lihtsalt juba olemasoleva koodi ümberkujundamisele.
Nii et seda me teemegi. Ja esimene asi on veenduda, et on olemas tegelikud andmed, millega töötada. Kui jah, siis korrake postituste ID-de loendi massiivi ja muutke nende postituse olekut:
Näete, et see ei erine palju esimeses postituses tehtud tööst, kuid nüüd tekitab see paar küsimust.
3 objektorienteeritud kaalutlused
Kui töötate sellise koodiga:
- Kas see kõik kuulub samasse klassi või eraldi klassidesse?
- Kas baasklass peaks olema ja kui jah, siis miks või miks mitte?
- Kas peaks olema üks avalik funktsioon, mis kutsub neid meetodeid välja (ja laseb need privaatseks märkida)?
- Kas peaksime funktsioonid avalikuks jätma?
Selle postituse jaoks teen ma järgmist.
- Esitage iga funktsioon avaliku meetodina. See on nii, et kui esimesest meetodist tagastatakse andmeid, saate nendega midagi muud teha.
- Hoidke seda ühes klassis. Nii saame luua ühe klassi ja seejärel kasutada seda mis tahes töö tegemiseks, mida vajame. Kui oleks muid meetodeid, kasutaksime samu meetodeid.
- Alustage liidesega. Ma ei hakka vaevuma liidese kirjutamisega lihtsalt liidese näitamise eesmärgil (oletan, et seda on praeguste funktsioonide põhjal piisavalt lihtne järeldada), vaid võtan klassi ette ja näitan, kuidas me saame funktsioonid "väljastpoolt sissepoole".
Nii et ma alustan viimasest punktist ja töötan tagasi. Siin on üks viis koodiga töötamiseks.
Ja siis näeb kogu klass välja järgmine:
Üldiselt teenib see samu eesmärke kui esimene, kuid rohkem objektorienteeritud viisil.
See ei ole Tee
Nagu ma olen püüdnud selle postituse kaudu mitu korda korrata, ei ole see lõplik viis selle töö tegemiseks. Selle asemel on see üks viis, kuidas tööd saab teha.
Saate seda oma äranägemise järgi ümber kujundada, ümber teha või uuesti kasutada. Eesmärk on aga näidata, kuidas lahutada loogika, mida me tavaliselt näeme protseduurilisena, millekski, mis on endast veidi vähem sõltuv ja jätab ruumi täiendavaks tööks.