Selle seeria esimeses postituses rääkisin kõigest sellest, kuidas soovisin käsitleda sissejuhatust objektorienteeritud programmeerimisse WordPressi kontekstis.
Objektorienteeritud programmeerimiseks on mõned suurepärased ressursid, kuid need võivad kasutada väljamõeldud näiteid või liikuda liiga kiiresti nende jaoks, kes alles soovivad alustada.
Püüdes seda vältida, arvan, et OOP-ist rääkimine WordPressis kinnitab meid tugevale alusele ja praktiliste näidete kasutamine on alati parem kui üldiste näidete kasutamine, mida on keeruline domeeni, kus me töötame, tõlkida.
Neile, kes pole veel liitunud või kes pole veel järele jõudnud, on esimene postitus järgmistel teemadel:
- objektorienteeritud analüüs,
- Vajalike asjade ja heade asjade kindlaksmääramine,
- Ja miks see raske on?
Ja siit see postitus pikima hakkabki.
Objektorienteeritud programmeerimine: rohkem analüüsi
Ma tean: koodi kirjutamisel tahame esimese asjana maha istuda ja koodi kirjutama hakata. Mis on parem kui panna midagi ekraanil juhtuma?
Ja kui teete seda enda jaoks, pole see nii suur asi, kuid koodi kirjutamisel on see järgmine:
- mida haldab inimeste meeskond,
- müügiks,
- või kõigi ülalnimetatute jaoks
See teeb vahet. Sest hea analüüs võib viia hea korralduseni, mis võib viia hea hooldatavuseni.
Vastasel juhul teete tarnimiseks midagi kokku ja see ei sobi tulevaste versioonidega hästi. Ja see on asi, millest me kogu seeria jooksul põhjalikult räägime.
Kuid milline on hea viis hea analüüsi tegemise kolme lihtsa sammuga kokkuvõtmiseks? See ei ole tingimata kuulikindel vastus, kuid seda püüame teha alati, kui töötame projektidega:
- Veenduge, et kood teeks seda, mida klient soovib,
- Rakendage häid objektorienteeritud tavasid,
- Eesmärk on hooldatav disain.
Kõik see kõlab teoreetiliselt hästi, kuid kuidas me teame, kas teeme seda õigesti, igasse asjasse süvenemata? Teisisõnu, siit leiame sageli raamatuid, ressursse ja muid utiliite, mis raskendavad paremaks objektorienteeritud programmeerijaks saamist.
Täpselt seda tahan ma vältida, nii et ma kaevun igasse punkti veidi sügavamale.
1 Mida klient soovib
See võib sageli olla kogu projekti üks keerulisemaid aspekte, kuna arendajatena räägime kliendiga erinevat keelt.
Nad mitte ainult ei kasuta sageli terminoloogiat, mida me ei kasutaks, vaid nad arvavad sageli, et see, mida nad ekraanilt tahavad, on parim viis selle saavutamiseks. See muudab nende parandamise proovimise tõesti halvustavaks ja valeks, kas pole?
Kujutage ette, et proovite öelda kellelegi, mida teate, mida soovite, ja ta parandab teid. Selle hoolikas käsitlemine võib saavutada suurt suhtelist võrdsust, kuid kulub teatud aega, et "välja kaevata", mida nad tegelikult tahavad, võrreldes sellega, mida nad ütlevad, et tahavad.
Ja me sukeldume sellesse tulevases postituses lähemalt.
2 objektorienteeritud praktikat
Ilmselgelt tuleneb see teadmisest, millised on head objektorienteeritud tavad ja see on midagi, mida kavatsen käsitleda.
Paljud inimesed ütlevad asju, kasutades selliseid asju nagu:
- SOLID põhimõtted,
- pärand,
- DRY kood,
- sõltuvussüst,
- ja nii edasi
Kas kõik on heade objektorienteeritud tavade järgimiseks olulised.
Ja võib-olla pole see populaarne asi, mida öeldakse, kuid ma olen seisukohal, et püüda kõiki asju pidevalt kasutada ei ole alati hea mõte. See tähendab, et te kindlasti ei soovi, et kood korduks kogu oma koodibaasis, kuid kas teil peab koodibaasis olema pärand?
Ei.
On aegu, mil põhimõtteid tuleks rakendada ja millal võib neid ignoreerida. Kuid nende teadmine, millal neid kõige paremini kasutada ja millal neid kasutada, on nende tavade õigeks kasutamiseks võtmetähtsusega.
3 Hooldatav disain
Lihtsamalt öeldes muudab mustrite ja põhimõtete rakendamine tarkvarale selle kirjutamisel see, mis muudab selle kasutamise ja hooldamise tulevikus palju lihtsamaks.
Aga jällegi, see sõltub sellest:
- mõistab täielikult, mida klient soovib,
- teades, millised tavad on olemas, millal neid rakendada ja millal neid vältida.
Ja kõige ülaltoodu tegemiseks peame vaatama iga punkti selle kontekstis, enne kui astume sammu tagasi, et vaadata suuremat pilti.
Mida klient soovib?
Ilmselgelt on ülaltoodud kolme punkti osas palju maad katta. Kuid kui soovite WordPressi majanduses kirjutada head, hooldatavat tarkvara, on oluline mõista, kuidas see kõik kokku sobib.
Nii et selle asemel, et hakata koodi kirjutama või projekti kallal töötama, uurime järgmisena, kuidas võtta seda, mida klient soovib, ja seejärel dešifreerida see nõuete kogumiks, mis võimaldab meil luua tööavaldus.
Nii on meil lõpuks töödokument selle kohta, mida klient soovib ja mida me ehitame, ning oleme kõik ühel lehel.