Eelmises postituses hakkasin läbima protsessi, mille käigus viidi läbi pistikprogrammi idee, mis prototüüpib selle kiiresti millekski, mis töötab WordPressis. Ja kuigi see töötab, ei järgi see tingimata objektorienteeritud põhimõtteid ega ole ka kohas, kus saaksime hõlpsalt funktsioone lisada.
Ei, see ei ole argument, miks objektorientatsioon on parem. See on minu eelistatud viis koodi kirjutamiseks, seega lähenen sellele sel viisil.
Ma tean, et näidiskood, mille ma annan, on lihtne ja ma tean, et võib juhtuda, et midagi sellist võib jätta nii, nagu see on. Kuid selle mõte on näidata, kuidas võtta kontseptsioon, selle prototüüp ja seejärel viia see millekski, mis järgib objektorienteeritud põhimõtteid.
Ja minu kogemuse järgi on seda keerulise näitega algusest peale palju raskem teha. kui sa kaotad lugejad algusest peale, siis mis lootust on neil saada aru, mis tuleb?
Seda arvestades vaatame eelmise postituse koodi ja teeme selle kohta veidi kontseptsioonianalüüsi, et näha, mis võiks klassis hästi toimida ja kuidas võiksime hakata seda klasside abil korraldama. nimeruumid ja nii edasi.
Mõiste analüüs
Mis puutub programmeerimisse, siis on nii lihtne hakata kohe koodi kirjutama ja seejärel esitama, kuni see teeb midagi, mida me tahame.
Ja kui see toimib, on tunne, et oleme valmis ja saame edasi liikuda järgmise ülesande juurde. Kuid suuremate projektide puhul pole see alati nii. Tegelikult on sageli parem teha enne edasiliikumist oma disaini objektorienteeritud analüüsi veidi kontseptsioonianalüüsi.
Lihtsalt kodeerimisega tegelemine ei ole alati parim lähenemine.
Juhtum analüüsiks
Näide: selle kirjutamise ajal arutleme ühe minu meeskonnakaaslasega selle üle, kas peaksime kursust laiendama või uue klassi kirjutama, et käsitleda Google Mapsi API-st võetud andmete geolokatsiooniteavet.
Kas ma saan seda tiivustada ja kirjutada midagi, mis töötab? Muidugi. Kuid kas see integreerub rakendusega hästi? Mitte ilma kontseptsiooni analüüsi, planeerimise ja ülejäänud süsteemiga kooskõlastamiseta.
Ja see ongi analüüsi eesmärk.
Meie töö analüüsimine
Mida see siis eile vaadatud pistikprogrammi jaoks tähendab? Praegu on meil järgmised asjad:
- funktsioon, mis vastutab metakasti loomise ja selle sisu kuvamise eest,
- funktsioon andmebaasi päringute tegemiseks ja viimaste viimaste postituste hankimiseks,
- funktsioon tulemuste kuvamiseks metakastis
- funktsioon sõnumi kuvamiseks, kui metakastis pole tulemusi
Lisaks on mitmed neist funktsioonidest seotud konksudega, mis on osa WordPress API-st. Nimelt on metaboksi loomise funktsioon haakitud WordPressiga ja selle kaasfunktsioon kuva renderdamiseks on kõik sama komponendi osad.
Siis on meil olemas andmebaasi päringute tegemise funktsionaalsus ja vaadetega otseselt seotud funktsioonid.
Kuidas see siis välja näeks, kui joonistaksime selle välja erinevateks klassideks ja failideks, mis aitaksid seda objektorienteeritumalt luua?
Ühtset lahendust pole
Ühtset lahendust pole ja mõned lahendused on palju arenenumad kui teised. Aga kuna ma üritan siin tasakaalu leida, siis lähenen sellele lihtsamalt, kui teha liiga palju tööd abstraktsiooni, pärimise, liideste ja kõige muuga.
Keskendumine sellele, mis meil on
Keskendugem praegu üksikutele klassidele ja nendele kuuluvatele kohustustele. Näiteks:
- Ma arvan, et meil on vaja klassi, mis esindab metakasti. See peaks vastutama metakasti loomise eest.
- Vajame ka klassi, mis vastutab metakasti sisu kuvamise eest. Võib arvata, et funktsiooni lisamine metakasti klassi toimib hästi. See teeb; aga kui soovite mõelda, et igal klassil on üksainus vastutus, siis saame luua klassi spetsiaalselt kuvari jaoks ja spetsiaalselt metakasti jaoks, seejärel sisestage kuva metakastisse installimise ajal. Sellest räägime hiljem lähemalt.
Sel hetkel võib meie diagramm välja näha umbes selline:
Meta kasti lõhkumine.
Järgmisena peame kaaluma muid funktsioone. Nimelt funktsionaalsus tulemuste kuvamiseks metakastis ja funktsionaalsus tulemuste kuvamiseks, kui neid pole.
Selleks, et metakastis midagi kuvada, peab meil olema võimalus tulemuste toomiseks andmebaasist päringuid teha. Sealt edasi peame suutma kindlaks teha, kas tulemusi on või mitte, ja seejärel sisestada need tulemused vaatesse.
Arvestades seda teavet, tundub, et vajame andmebaasi päringute tegemiseks klassi ja seejärel on meil vaja klassi sõnumi metakasti kuvale laiali saatmiseks.
Võib-olla näeb üks viis tundide korraldamiseks välja järgmine:
Päringute tegemine andmebaasist ja sõnumite koostamine.
Diagrammi lõplik versioon võib olla veidi kitsas, kuid lõpuks vaatame midagi sellist:
Meie klasside viimane korraldus.
Selgituseks:
- Postituse retriiver küsib andmebaasist kolme viimast viimast postitust.
- Postitussõnum määrab, milline sõnum ekraanile sisestada.
- Ekraanil kuvatakse määratud teade.
- Metabast kuvab selle veebibrauseris.
Seega oleme sisuliselt võtnud mõned WordPressiga ühendatud funktsioonid ja jaganud need komponentideks, mis suudavad üksteisega suhelda, millest igaühega on suhteliselt lihtne töötada ja mis ei tee rohkem kui ühte tööd.
Selle teisendamine koodiks
Nüüd, kui meil on idee, kuidas saaksime eelmise kontseptsiooni koodiks teisendada, vaatame järgmises paaris artiklis, kuidas seda teha.
Pange tähele, et koodi juurutamise või klasside kujundamise valik võib veidi erineda ülaltoodust ja teil võib olla soovitusi, kuidas ülaltoodut paremini korraldada. Kui see nii on, jätke kommentaar.
Järgmises postituses vaatleme selle teisendamist funktsionaalseks koodiks ja pärast seda, kuidas seda õigeteks nimeruumideks ja õigeks failikorralduseks korraldada.