Nopea prototyyppien luominen WordPressillä: konseptianalyysi
Edellisessä viestissä aloin käydä läpi prosessin, jossa otin idean laajennuksesta, joka prototyyppisi sen nopeasti joksikin, joka toimii WordPressissä. Ja vaikka se toimii, se ei välttämättä noudata oliopohjaisia periaatteita, eikä se ole paikassa, jossa voimme helposti jatkaa ominaisuuksien lisäämistä.
Ei, tämä ei ole argumentti sille, miksi oliosuuntaus on parempi. Se sattuu olemaan suosikkini tapa kirjoittaa koodia, joten lähestyn sitä tällä tavalla.
Tiedän, että antamani esimerkkikoodi on yksinkertainen ja tiedän, että voidaan tehdä asia, että jotain tällaista voidaan jättää sellaisenaan. Mutta tämän tarkoitus on näyttää, kuinka konsepti otetaan, prototyyppi ja sitten siirretään se johonkin, joka noudattaa oliolähtöisiä periaatteita.
Ja kokemukseni mukaan se on paljon vaikeampaa tehdä monimutkaisella esimerkillä alusta alkaen. Jos menetät lukijoita alusta alkaen, mitä toivoa heillä on ymmärtää, mitä on tulossa?
Tämän jälkeen katsomme edellisen viestin koodia ja teemme siitä hieman käsiteanalyysiä nähdäksemme, mikä voisi toimia hyvin luokassa ja kuinka voisimme alkaa järjestää sitä luokkien avulla. nimitilat ja niin edelleen.
Käsiteanalyysi
Aina kun on kyse ohjelmoinnista, on niin helppoa haluta hypätä heti koodin kirjoittamiseen ja sitten kiertelemään sen lähettämiseen, kunnes se tekee jotain, mitä haluamme.
Ja kun se toimii, tuntuu, että olemme valmiita ja voimme siirtyä seuraavaan tehtävään. Mutta isommissa projekteissa näin ei aina ole. Itse asiassa on usein parempi tehdä suunnitelmasi olio-analyysin konseptianalyysi ennen kuin siirryt eteenpäin.
Pelkkä koodaamiseen hyppääminen ei aina ole paras tapa.
Analyysitapaus
Esimerkki: Tätä kirjoitettaessa eräs tiimitovereistani ja minä keskustelemme siitä, pitäisikö meidän laajentaa luokkaa vai kirjoittaa uusi luokka käsittelemään Google Mapsin sovellusliittymästä poimittujen tietojen maantieteellisiä sijaintitietoja.
Voinko siivellä ja kirjoittaa jotain toimivaa? Varma. Mutta integroituuko se hyvin sovellukseen? Ei ilman konseptianalyysiä, suunnittelua ja koordinointia muun järjestelmän kanssa.
Ja se on analyysin tarkoitus.
Analysoimme työtämme
Mitä tämä tarkoittaa eilen tarkastelemamme laajennukselle? Tällä hetkellä meillä on seuraavat:
- toiminto, joka vastaa metalaatikon luomisesta ja sen sisällön näyttämisestä,
- toiminto tietokannan kyselyyn ja viimeisimpien viestien hakemiseen,
- toiminto tulosten näyttämiseksi metalaatikossa
- toiminto, joka näyttää viestin, kun metaruudussa ei ole tuloksia
Lisäksi monet näistä toiminnoista liittyvät koukkuihin, jotka ovat osa WordPress API:ta. Nimittäin metalaatikon luomistoiminto on koukussa WordPressiin ja sen täydentävä toiminto näytön renderöimiseksi ovat kaikki osa samaa komponenttia.
Sitten meillä on toiminnot tietokannan kyselyyn ja meillä on toimintoja, jotka liittyvät suoraan näkymiin.
Joten miltä tämä voisi näyttää, jos kaavioitamme tämän eri luokkiin ja tiedostoihin, jotka auttaisivat luomaan tämän oliokeskeisemmällä tavalla?
Ei yhtä ratkaisua
Ei ole olemassa yhtä ainoaa ratkaisua, ja jotkut ratkaisut ovat paljon edistyneempiä kuin toiset. Mutta koska yritän löytää tasapainon tässä, aion lähestyä tätä yksinkertaisemmalla tavalla kuin tehdä liikaa työtä abstraktion, periytymisen, rajapintojen ja kaiken muun kanssa.
Keskitymme siihen, mitä meillä on
Keskitytään nyt yksittäisiin luokkiin ja niihin mahdollisesti kuuluviin vastuisiin. Esimerkiksi:
- Luulen, että tarvitsemme luokan, joka edustaa metalaatikkoa. Tämän pitäisi olla vastuussa metalaatikon luomisesta.
- Tarvitsemme myös luokan, joka vastaa metalaatikon sisällön näyttämisestä. Saatat ajatella, että funktion sisällyttäminen metalaatikon luokkaan toimii hyvin. Se tekee; Jos kuitenkin haluat ajatella, että jokaisella luokalla on yksi vastuu, voimme luoda luokan nimenomaan näyttöä ja erityisesti metalaatikkoa varten, minkä jälkeen ruiskutetaan näyttö metalaatikkoon ilmentymisen aikana. Puhumme tästä lisää myöhemmin.
Tässä vaiheessa kaaviomme saattaa näyttää suunnilleen tältä:
Metalaatikon hajottaminen.
Seuraavaksi meidän on harkittava muita toimintoja. Nimittäin toiminnallisuus tulosten näyttämiseksi metalaatikossa ja toiminto tulosten näyttämiseksi, kun niitä ei ole.
Jotta voimme näyttää mitä tahansa metaruudussa, meillä on oltava tapa tehdä kysely tietokannasta tulosten hakemiseksi. Sieltä meidän on pystyttävä määrittämään, onko tuloksia, jos ei ole, ja sitten ruiskuttaa ne tulokset näkymään.
Näiden tietojen perusteella kuulostaa siltä, että tarvitsemme luokan tietokannan kyselyä varten ja sitten tarvitsemme luokan viestin levittämiseksi metalaatikon näyttöön.
Ehkä yksi tapa järjestää tunnit näyttäisi tältä:
Tiedustelut tietokannasta ja viestien valmistelu.
Kaavion lopullinen versio voi olla hieman ahdas, mutta viime kädessä tarkastelemme jotain tällaista:
Luokkaidemme viimeinen järjestely.
Selityksen vuoksi:
- Viestinnoutaja kysyy tietokannasta kolme viimeisintä viestiä.
- Viestiviestintä päättää, mikä viesti lisätään näyttöön.
- Näyttö näyttää asetetun viestin.
- Meta-ruutu näyttää sen näytön verkkoselaimelle.
Olemme siis pääosin ottaneet muutaman WordPressiin koukussa olevan toiminnon ja jakaneet ne komponentteihin, jotka pystyvät kommunikoimaan toistensa kanssa. Kukin niistä on suhteellisen helppo työskennellä ja jotka eivät tee enempää kuin yhtä työtä.
Sen muuntaminen koodiksi
Nyt kun meillä on idea siitä, kuinka voimme muuntaa edellisen konseptin koodiksi, katsomme, kuinka se tehdään parissa seuraavassa artikkelissa.
Huomaa, että tapa, jolla päätät ottaa käyttöön koodisi tai suunnitella luokkasi, voi olla hieman erilainen kuin edellä, ja sinulla voi olla ehdotuksia yllä olevan sisällön järjestämiseksi paremmin. Jos näin on, jätä kommentti.
Seuraavassa viestissä tarkastelemme tämän muuntamista toiminnalliseksi koodiksi ja sen jälkeen tarkastelemme tämän järjestämistä oikeiksi nimiavaruuksiksi ja tiedostojen oikeaksi järjestämiseksi.